How builds work

Most AI workflow builders run a long tool loop: the model searches the catalog, reads schemas, searches again — dozens of inference passes, each re-sending the whole conversation, each a fresh chance for a mid-tier model to derail. GoRunner's builds take a different shape.

The compile path

The plan pass asks you at most one question when something materially ambiguous would change the build's shape; the resolve step answers every planned step from the capability index — ranked candidates, the top candidate's real schema, a skeleton config, sample output, and honest "no piece for that here → use HTTP" verdicts.

The invariant: the number of model passes per build is a constant (2–4), independent of catalog size and flow size. A 10,000-piece catalog costs the same to build against as a 50-piece one, because resolving intent → catalog facts is the server's job, not the model's. That's also why builds stay accurate on mid-tier models: the model is never asked to remember a catalog, only to copy facts it was just handed.

Conversations attached to an existing workflow use the interactive loop instead — edits and diagnosis genuinely benefit from reading the live flow and its runs — and any structural failure of the compile path falls back to that loop automatically.

The flight simulator

Validation answers "is this definition legal?". The simulator answers a different question: "when this runs, will its wires carry anything?"

It walks the proposed definition with the trigger's declared sample payload and each action's declared sample output through the same expression resolver a live run uses, and flags:

• an expression that resolves to nothing against the output it will actually receive ({{steps.fetch.result.rows}} when the step emits records),
• a loop over a value that isn't a list,
• a branch condition whose deciding expression is a dead wire,
• a {{$vars.X}} no variable declares.

All of those are legal — they'd run green and do the wrong thing. The simulator only speaks when it knows: steps with dynamic outputs (Code, mappers), caller payloads and JavaScript expressions are left alone rather than guessed at. Findings arrive on the proposal card as pre-flight notes, so the fix happens before the first run instead of after the third confusing one.