AI-Assisted Building

Building an agent is a loop: author a flow and its scripts, get them running in a space, try a real conversation, see what the agent actually did, and adjust. An AI assistant can drive that whole loop for you — writing the flow, checking it against the platform's rules, deploying it, running a live test, reading the outcome, and fixing what went wrong — so a working agent can be built and refined with very little hands-on work from you.

What makes this practical is that the assistant can observe a real run the same way a person watching the chat would: it sees the answer stream out, and it sees, node by node, what each step received and produced. That feedback is what lets it correct a flow on its own instead of guessing.

The platform's guides, as context

The assistant works from a curated set of the platform's own reference material — how flows and nodes behave, the contracts a script node must satisfy, the data-and-placeholder model, and the SDK a partner app uses. It is handed this as context up front, so it builds to the platform's real rules rather than inventing them. This is the biggest reason the output is correct and not merely plausible-looking.

A toolchain to talk to the platform

Alongside the guides, the assistant is equipped with a small set of tools that let it communicate with the running system: one to check a project against the platform's rules, one to deploy it into a space, and one to run a live test conversation and read the full trace back. These tools are the channel through which it acts on the platform and observes the result — without them it could only write text; with them it closes the loop.

1. Author. The assistant writes or edits the flow and its script nodes — the graph of nodes, the wiring between them, and the code each script runs.
2. Validate. Before deploying, it checks the whole project against the platform's contracts — node shapes, wiring, and the rules a script and an agent reply must follow. This catches the mistakes that would otherwise only show up as a stalled run or a silent "no response", so a deploy and a live run are spent only on code that already passes.
3. Deploy. A flow always runs from its deployed version, not the working copy, so the assistant deploys the project into a space. The platform scans it and either accepts it or returns the exact reasons to fix — a clear, immediate verdict, no polling.
4. Run a real conversation. With the flow now live, the assistant sends a real prompt and runs it, exactly as an end user would.
5. Read the outcome. It reads both views of the run: the live progress as the agent works, and the structural trace of which node ran, what it received, what it returned, and where anything failed.
6. Fix and repeat. Armed with that, it edits and goes around again — until the agent answers the way you asked for.

The live stream

The agent's output as it is produced — the answer forming token by token, and the progress of a multi-step run. This is the same live view a person watching the chat would see, so the assistant can judge whether the answer is right.

The node-by-node trace

A structural record of the run: which nodes ran, what each one received and returned, the model's answer, and where a node failed. This is what turns "the answer looks wrong" into "this node got the wrong input" — a precise place to fix.

The deploy verdict

When a deploy is rejected, the platform names exactly what to change — a bad structure or a failed safety check comes back as a concrete list. The assistant reads it, fixes the flagged items, and deploys again.

None of this requires access to servers or infrastructure. The assistant works entirely at the flow and product level — the same surface you use — which is exactly what keeps the approach safe to hand off.

• A flow runs from its deployed copy, so an edit is not live until it is deployed. That is why the loop always deploys before it tests — the assistant is never reading a run of stale code.
• Testing a cookie-reading flow doesn't need a real browser: the assistant can supply the request values directly when it runs a turn, so a flow that expects a connect token can be exercised end to end without a live consumer session.
• The assistant runs an agent by its slug in a space, the same as any caller — so the flow it tests is the exact one your consumers will reach, with the same authorization rules.
• Hands-off is the goal, not a guarantee of a first-try success. The value is the tight loop — validate, deploy, run, read, fix — running quickly enough that a working flow emerges from iteration rather than from getting it perfect up front.