Understanding Agent Playground

An agent is a set of connected nodes

An agent is a set of nodes wired together. Each node takes named inputs and produces named outputs, and every input and output is typed: it carries a display name for the canvas and a JSON Schema that defines the shape of the data passing through it. A connection joins one node’s output to another node’s input, and that’s how a value produced by one step reaches the next.

Take an agent called support-triage. It starts with two nodes: classify and draft-reply. classify takes a message input and produces a response output: it runs a linked prompt, and that’s what turns the input into the output. classify’s response output schema tracks whatever prompt is linked to it: change the linked prompt’s response format, and response’s shape updates to match. A connection carries that classify.response value straight into draft-reply’s own category input.

Both classify and draft-reply are atomic nodes, meaning each does the work itself rather than delegating to another agent; right now that means both are LLM Prompt nodes, since that’s the only kind of atomic node the platform ships with.

A node doesn’t have to do the work itself, either. It can instead be a reference to another agent’s saved version, a version you’ve saved rather than a draft still being edited, letting you reuse a whole agent as a single step, as covered in Composing agents with an Agent Node below.

How connections wire together

Three properties hold for every connection in an agent, and they explain most of what you’ll run into.

• One output can feed several inputs at once. If classify’s response output is useful to more than one downstream node, connect it to as many inputs as you need; each one gets the same value
• Every input accepts exactly one connection. draft-reply’s category input can be fed by classify or by some other node, but never both at the same time. If two outputs could plausibly feed the same input, you pick one
• The wiring can never loop back on itself. Data only flows forward, from a node to the nodes downstream of it, never back to a node it already came from. An agent that tried to connect draft-reply’s output back into classify’s input would be forming a loop, and the platform rejects that connection

What isn’t connected becomes the agent’s own input or output

Not every input ends up fed by a connection, and not every output ends up feeding one, and that’s what makes the model click.

Inputs that nothing feeds are the agent’s own inputs: the values you fill in before a run. classify’s message input has no connection into it, so message is what you provide when you run support-triage.

Outputs that nothing consumes work the same way in reverse: they’re what the run hands back. If draft-reply’s response output isn’t wired into anything, draft-reply’s response is part of support-triage’s result.

Composing agents with an Agent Node

An Agent Node is a node whose job is to run another saved agent as a single step, instead of doing the work itself. You point it at one of that other agent’s saved versions, and because the referenced agent has its own inputs, the Agent Node exposes those same inputs as its own. You map each of them in the node’s Input Mapping section: it’s where you choose which value in the current agent feeds an input that belongs to the nested agent, though you don’t have to map every one. Leave a mapping empty and that input becomes one of the agent’s own inputs, the same rule covered above. See Configure an Agent node for the form.

Say support-triage needs to compress draft-reply’s output before it goes out, using a category-aware summarizer someone already built. Add an Agent Node, summarize-step, pointing at a saved version of a separate agent called summarizer. summarizer takes two inputs, text and category, and produces one output, response. Once summarize-step is in place, text and category become inputs on summarize-step itself: classify’s response output can now fan out to feed both draft-reply and summarize-step, and draft-reply’s response output connects into summarize-step’s text input.

%%{init: {"flowchart": {"curve": "basis", "rankSpacing": 80, "nodeSpacing": 60, "padding": 20}}}%%
flowchart TD
accTitle: How the support-triage agent's nodes, connections, and a nested agent fit together
accDescr: The support-triage agent contains three nodes. Classify takes a message input that nothing feeds, so message becomes the agent's own input. Classify's response output fans out to both draft-reply and summarize-step, showing that one output can feed several inputs. Draft-reply's response output feeds summarize-step's text input. Summarize-step is an Agent Node: it points to a saved version of a separate agent called summarizer, and its own response output isn't consumed by anything else, so response becomes what a run of support-triage hands back.
MSG(("message")) --> CL["classify"]
CL -->|"response"| DR["draft-reply"]
CL -->|"response"| SS["summarize-step"]
DR -->|"response"| SS
SS -.->|"points to"| SUM["summarizer (saved version)"]
SS -->|"response"| RES(("agent output"))

That last connection changes what’s exposed. draft-reply’s response is no longer unconnected, so it drops out of support-triage’s result, and summarize-step’s own response output takes its place as the new exposed output. Nothing else changes: the rest of the wiring, and the rules that govern it, are exactly the ones from the last two sections.

What an Agent Node can’t point at:

• A draft version. Only a saved version of the other agent is a valid target
• This agent itself. An agent can’t be a step inside itself
• An agent that already contains this one as one of its own steps, however indirectly. That would form a loop between agents instead of within one, and it’s rejected the same way a loop inside a single agent is

Keep exploring