AI-Assisted Building

A building assistant does two things. As a provisioner it operates your organization through the Keen MCP Server — it creates the space, the agent, the API access chain a partner site needs, and its own end-user identity — and hands that identity to its runner. As a builder it writes the flow project's files and iterates with three tools: check the project, deploy it, run a real conversation and read the trace.

It never chats with your agents through the MCP server — that is what the live chat is for — and it never touches servers or infrastructure: everything it does is a tool call, a command, or a guide it has read. 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, the SDK a partner app uses, plus a plain-words guide to every admin console screen and to operating the platform through the MCP server. 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, one to run a live test conversation and read the full trace back — and a fourth, the Keen MCP Server, through which it operates your organization, creating the space, the agent and the API access chain the test needs, with the same rules as the console. 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 — signed in as an MCP consumer, a headless end-user identity it provisioned for itself through the MCP server.
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.
• The assistant acts under an MCP account your admin created, so everything it provisions is checked against that account's role and recorded in the audit trail — and there are things it can never do, whatever its role: manage accounts, roles, other MCP accounts, or your consumers' records.
• 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.