Most agents improvise. This one compiles.

A goal-driven agent is told what not to do in its system prompt, and can drift past it. Here the compiler controls the graph: the wrong tool is not in the step's toolset and the wrong step is not reachable.

An agent step reasons openly toward a goal. A guided step must call a named tool to advance. A conditional step branches on a value from an earlier step. A map step fans out over a list. A transform step runs SQL with no model call at all. A wait-for-input step pauses for a person, an action step changes something in the world, and a subworkflow step calls another workflow you already published. Any step can carry gate checks, assertions, and retry with the validator's complaint as context.

A map step takes a list produced earlier in the run, starts one scoped agent per item, and folds every result back into a single output through a reduce before the graph moves on. You set how many item agents run at once, from 1 to 256, and each one can carry its own pinned model. Triggers fan out the same way at the workflow level, firing as many as 10 workflows from one event.

Each step sees only its own tools and instruction, so context stays small and prompt caching applies per step. Steps whose work is fully determined compile down to code and call no model at all. On the supplier-risk workflow we benchmarked, that is 380 model tokens a run against 8,289 on the best-tuned AWS build (provisional until the final receipt is attached).

Every step that calls a model can name the one it runs on, picked from the model registry your admin curates. Heavy reasoning sits on a frontier model while bulk extraction runs on a cheaper one, and a step that touches sensitive data can be pinned to a self-hosted model. A pin naming a model nobody registered fails the build rather than quietly running on something else.

One persisted trigger holds the cron expression or webhook URL, fan-out to as many as 10 workflows, per-workflow input mapping, retry policy, and its own last-fired audit. Authored once, reused everywhere.

For steps that change something in the world, the lifecycle is fixed: plan, freeze the plan with a fingerprint of its inputs, route for approval with timeouts and escalation, execute only on approval, then write an append-only audit record.

A skill is a packaged playbook for a class of problem. A subagent handles a delegated sub-task with its own reasoning loop. A custom tool is your Python function, registered once and callable from any step in any workflow. An MCP server you already run plugs in as a connection, and you can pare a chatty server down to the few tools you want. Its token travels in the outbound request to your server and never enters the model's context.

Run state is checkpointed so a run survives a restart or waits days for a human. Project memory holds facts across runs, catalog memory holds descriptions and embeddings of your data, and every run emits a structured event stream with per-step token usage.

No, and the builder badges each step so you can see. A step whose work is fully determined, such as a query you already have, arithmetic, or a delivery, is compiled to code and calls no model. What is left are the steps that need judgment.

Point the project at your semantic layer and the raw-SQL and catalog-browsing tools leave the toolset. The agent can ask only for the measures and dimensions the layer defines, and the layer resolves the joins and writes the SQL.

Yes. A map step turns a list into one small agent per item, runs them at once, and folds the results into a single output before the next step starts. You cap how many run at a time, from 1 to 256, and each can carry its own model. One trigger can also start as many as 10 workflows from a single event.

That is the normal way to build here. A model is pinned per step, because steps are not equally hard. Heavy reasoning can sit on a frontier model while extraction and formatting run on something much smaller, including an open-weights model you host. A pin that names a model nobody registered fails the build.

Yes. Register a Python function once and any step can call it. Connect an MCP server over HTTP or SSE, with a token or OAuth, and expose only the tools you want. If a server is slow or down, that turn runs without its tools; the run does not fail.

Because long ones are not followed. Give a model a hundred-line instruction and, over a thousand runs, it will quietly drop two or three of those lines. In our own tests a three-to-five line instruction is followed almost perfectly. Breaking a process into steps is what makes short instructions possible.

At the lowest level we use primitives from LangGraph for ordinary agent mechanics. The compiler, the state graph, the determinism and the context handling are ours, built on top. That layer is the product.