Agents in Circuitry
Agents are the AI workers at the heart of every workflow. They take input, reason over it with a large language model, and produce output — whether that's an answer, a structured payload, a tool call, or the next message in a conversation. Most useful workflows wire one or more agents together with other primitives: chat as a user-input surface, vector stores as knowledge, code for transformations, fork/join for parallel paths.
What an Agent node does
Drop an Agent node from the side panel. By default it accepts a prompt template, a model (any cloud or local model you've configured), and a temperature. When the workflow executes it:
- Receives input from upstream nodes.
- Resolves template variables in the prompt (e.g.
{{input}},{{previousNode.output}},{{store:Product FAQ|q=…}}). - Calls the configured AI model with the resolved prompt and any tools available from upstream wiring.
- Returns the model's response as its output, ready for downstream nodes.
Agents are first-class workflow nodes, so they compose with everything else: you can fork to multiple agents, feed an agent's output into another agent, branch on conditions, run agents in loops, and so on.
Authoring an agent's behaviour
You have two surfaces for telling an agent what to do.
Hand-written prompt
Click into the agent and type the prompt directly. Template variables like {{input}} get resolved at run time. This is the most direct way and great for one-off agents.
The Prompt Wizard
Click the ✨ button on the agent's header to open the Prompt Wizard. Describe what you want in plain English — "answer the user's question about products, but only using the Product FAQ" — and the wizard reads your workflow context (every upstream node, every vector store you have) and generates a structured prompt with the right template variables already in place. You can edit the result like any other prompt.
The wizard understands:
- Knowledge bases: mentioning a store by name (or "the connected store") produces
{{store:Name|q=…|k=5}}references. - Strictness: phrases like "only use the store", "closed-book", "strict", or "fall back to general knowledge" control whether the agent is constrained to retrieved content or allowed to fill gaps from training data.
- Upstream data: it suggests
{{input.value}},{{input.value.field}}, etc. based on the actual data shape coming in.
The wizard's output is regular text — version-controllable, editable, inspectable. Nothing is hidden.
Connecting agents to other nodes
Chat node → Agent (driver mode)
When you wire a Chat node into an Agent's input, the chat becomes a thin UI for that agent. Send a message from the chat and:
- The chat passes your message to the agent as
{{input}}. - The agent's prompt (whatever you authored or the wizard generated) executes against the message.
- Any
{{store:…}}template variables in the prompt resolve before the LLM call — retrieval fires automatically. - If a tool-capable model is selected, the LLM can also call
search_<store>tools for any vector stores wired upstream. - The reply streams back into the chat UI.
No "Run" button needed — sending a message triggers the agent. This is the easiest way to build a conversational interface backed by your own logic + data.
Store node → Agent (knowledge wiring)
Wire a Vector Store node into an agent's input handle. The agent learns three things:
- The store exists — its name and description appear in a small "available knowledge" block on the agent's system prompt.
- How to query it — a
search_<store_name>tool is automatically registered. Tool-capable models can call it on demand. - What's already retrieved — if the store node has already executed, its top-K chunks flow through as input data too, so any LLM (tool-capable or not) gets the context.
Wire multiple stores to one agent. Each gets its own tool. The model picks the right one per question based on each store's description. See the Knowledge Base section for how to fill stores with content.
Code node → Agent (transform first)
Insert a Code node between two pieces of the flow to rewrite, filter, or join data before the agent sees it. A common pattern is Chat → Code (extract intent) → Vector Store → Agent — the code node lifts a clean query out of the user's free-form message, the store retrieves on that, the agent synthesises a reply.
Agent → Agent (multi-step reasoning)
Chain agents to break a hard problem into sequential stages: Agent A (extract entities) → Agent B (classify) → Agent C (write reply). Each stage has its own focused prompt and gets the upstream stage's output as input.
Fork → Agent × N → Join
Split a single input into parallel agent calls (different roles, different stores, different models) and merge their outputs at the join. Useful for cross-checking, multi-perspective reasoning, or fan-out tasks.
Models, tools, and routing
The agent's model dropdown lists every model your workflow can reach — cloud (OpenAI / Anthropic / etc.), local (LM Studio, Ollama), or on-device (Apple Intelligence on iOS). Switching models is just changing the dropdown; the agent's prompt and wiring carry across.
When MCP is enabled, the agent has access to the workflow's tool set (procedures, introspection, custom plugins). Tools synthesised from upstream vector stores piggyback on this same channel — they just appear in the LLM's tool list automatically.
What "instructions" means for an agent
Every agent has an effective system prompt assembled from three sources at run time:
- The agent's prompt config (what you wrote / what the wizard generated).
- Awareness blocks automatically added by the runtime — e.g. "you have access to these knowledge stores: …".
- Resolved template variables — chunks from
{{store:…}}, upstream node output via{{input.…}}, etc.
You can hover an agent during / after execution to see its assembled prompt and the tool list it was given — useful for debugging "why did the AI say that?" moments.
Common patterns
- Single domain expert:
Chat → Agent (with one Store wired in). The chat is the user surface; the agent is the expert grounded in your docs. - Multi-store expert:
Chat → Agent (with three Stores wired in). The model picks which knowledge base to query per question based on each store's description. - Always-on retrieval: in the agent's prompt, write
{{store:my-store|q={{input}}|k=5}}. The store fires every turn regardless of what the model would decide. - Conditional retrieval:
Chat → Condition (is this a product question?) → Agent (with Product FAQ) / Agent (no store). - Two-pass synthesis:
Chat → Agent A (decide what's needed) → Agent B (compose final reply with stores wired in).
Where to go next
- Knowledge Base — Build the vector stores your agents reason over. Includes how to ask your own docs directly, before wiring them into an agent.
- Agent Node Reference — Field-by-field config reference.
- Vector Store Node Reference — The node-level details on store nodes.
- Inline AI in the Code Editor — Agents at the cursor for code authoring.
- Workflows Overview — How agents fit alongside the rest of the graph.