1. The shell sends the query
The shell POSTs to/chat with a JSON body containing your message.
2. Memory context is fetched
Before doing anything else, the agent pulls relevant long-term memory. Facts extracted from past conversations are injected into the LLM prompt so responses stay personalized. See Memory.3. Fast-path command handling
Some queries never touch the LLM. The handler short-circuits common commands into prebuilt components:4. Intent routing
Next, the handler checks for computer-control intent (phrases like “use cursor to build…”, “claude code…”, or “open VS Code and…”. These route into an agentic control loop (via thecomputer_control plugin) before the generic “create” keyword catch, so
they aren’t mistaken for UI-composition requests.
Other intents (research, comparison, timeline, quiz, etc.) are detected by
_analyze_query_intent, which returns a widget hint passed into compose_ui.
5. UI composition (the LLM call)
For general queries,compose_ui(user_query, session_id) makes a single LLM call. The
LLM is given the A2UI schema and returns JSON describing the interface.
If a widget needs custom computation, the LLM embeds a __jit__ key holding scripting code,
which the agent executes in a sandbox. See JIT Rendering.
6. The response
The endpoint returns:task_tracker component
summarizing each step’s status. See Workflows.
7. The shell renders it
The renderer walks the JSON tree and instantiates widgets. A layout validator runs first to clamp depth, child counts, and total component count so a malformed tree can’t crash the renderer.Real-time updates
Stateful and streaming widgets keep updating after the initial render. The agent pushes events over the Unix socket/tmp/megha_events.sock; the shell’s event client applies them
for example, JIT stream ticks patch the live UI without another /chat round trip.