Three related problems in the block builder sub-agent, all of which end with a canvas that cannot run the way the user asked for.
1. The agent builds fan-out workflows, which the runtime does not support
The block builder connects one block's output handle to several downstream blocks, so a single block's output fans out into multiple branches running in parallel. The execution model is a single linear flow — one outgoing connection per source handle — so a fanned-out canvas either drops branches or behaves unpredictably at request time.
Expected: each source handle has at most one outgoing connection. Branching is expressed with a branching block (e.g. if, whose separate handles are the branches), not by hanging several edges off one socket.
2. The block builder's verifier does not catch it
apps/ai-gateway/src/harness/agents/sub-agents/blockBuilder/validator.ts never inspects handles at all — there is no check that a handle is used once, so the fan-out above passes verification and is written to the artifact as valid. The verifier needs a handle-level rule (one edge per source handle, and the handle must actually exist on that block type) alongside the block-type checks it already does.
3. The JS code API is not documented properly
The blocks that run user JavaScript (jsrunner, and every JS expression field) expose an API to that code — what is in scope, what the input value is, how to read and write variables, what shape the return value must have. That contract is not written down anywhere the agent can read, so the model guesses at it and writes code that does not work against the real runtime. It needs a documented reference, and the block builder's prompt/doc search has to be able to reach it.
Impact
Together these mean a run can report success while producing a canvas that silently drops branches and contains JS that fails on the first request.
Related: #237 — the supported, explicit form of fan-out (declared branch count, user-ordered branches, one join point). The fix for problem 1 here is "do not fan out"; #237 is where fan-out becomes a thing an agent is allowed to build.
Three related problems in the block builder sub-agent, all of which end with a canvas that cannot run the way the user asked for.
1. The agent builds fan-out workflows, which the runtime does not support
The block builder connects one block's output handle to several downstream blocks, so a single block's output fans out into multiple branches running in parallel. The execution model is a single linear flow — one outgoing connection per source handle — so a fanned-out canvas either drops branches or behaves unpredictably at request time.
Expected: each source handle has at most one outgoing connection. Branching is expressed with a branching block (e.g.
if, whose separate handles are the branches), not by hanging several edges off one socket.2. The block builder's verifier does not catch it
apps/ai-gateway/src/harness/agents/sub-agents/blockBuilder/validator.tsnever inspects handles at all — there is no check that a handle is used once, so the fan-out above passes verification and is written to the artifact as valid. The verifier needs a handle-level rule (one edge per source handle, and the handle must actually exist on that block type) alongside the block-type checks it already does.3. The JS code API is not documented properly
The blocks that run user JavaScript (
jsrunner, and every JS expression field) expose an API to that code — what is in scope, what the input value is, how to read and write variables, what shape the return value must have. That contract is not written down anywhere the agent can read, so the model guesses at it and writes code that does not work against the real runtime. It needs a documented reference, and the block builder's prompt/doc search has to be able to reach it.Impact
Together these mean a run can report success while producing a canvas that silently drops branches and contains JS that fails on the first request.
Related: #237 — the supported, explicit form of fan-out (declared branch count, user-ordered branches, one join point). The fix for problem 1 here is "do not fan out"; #237 is where fan-out becomes a thing an agent is allowed to build.