Loading…
An agent that runs to completion and produces a result is a black box. When it fails — and it will — you have no trace, no branch point, no way to resume. We build a plan automation layer into your system that decomposes every goal into a named, observable graph of steps — where every branch is logged, and any step can be paused, inspected, or redirected without starting over.
Every plan is a first-class record in the system — not a runtime variable in an agent's memory. It can be queried, paused, revised, and audited at any point in its lifecycle.
Read the plan API docs ↗The plan automation layer analyzes the goal and produces a directed acyclic graph of named steps. Parallelism is declared implicitly by the dependency graph — steps without a dependency on each other run concurrently. Every step is named, scoped, and logged before execution starts.
Assignment is part of the plan record. You can inspect which agent owns which step before execution begins — and the agent runs with only the permissions declared for that step, not the ambient permissions of the requesting agent.
The executor processes steps as their dependencies resolve. Each step completion is written to the plan log with inputs, outputs, duration, and the agent that ran it. The plan's state at any point in time is a queryable record, not a runtime variable.
Gate steps are declared like any other step in the plan. When execution reaches a gate, it halts and routes to the configured reviewer. There is no timeout bypass and no way for an agent to reason past a gate — the decision must be explicit. Reviewers can approve, reject, or redirect the plan from that point.
If a step fails or a human redirects, the plan is revised from that branch point. Completed upstream steps are preserved — their outputs remain available and their work is not replayed. The revision itself is a logged plan event, so the full history of what happened and why is always recoverable.
When a plan step fails, you resume from the failure point. Completed upstream steps are preserved — their work and outputs are not replayed. You never lose hours of agent work because a single downstream step encountered an error.
Every plan step — its assigned agent, its inputs, its outputs, its duration, and its branch dependencies — is in the plan log. When something goes wrong, or when an auditor asks why a decision was made, the answer is already recorded. You never reconstruct it from memory.
Human-in-the-loop gates are declared in the plan and enforced by the system, not by the agent. An agent cannot proceed past a gate by reasoning around it, retrying with a different prompt, or escalating on its own authority. The gate is a hard stop. Human approval is not optional unless the plan says so.
An agent workflow is typically a code-level orchestration of tool calls — fast to write, hard to inspect externally. A plan is a first-class record in the systems we build: it has an ID, a log, a state machine, and human gates. Anyone with access can inspect a running plan without reading the code that created it. That queryability and auditability is the core difference.
Yes. Parallelism in a plan is declared through the dependency graph. Steps that share no dependencies run concurrently up to a configurable concurrency limit. Steps with dependencies wait until their upstream steps complete. The DAG structure handles fan-out, fan-in, and mixed topologies — you don't need to manage concurrency explicitly in your code.
A gate step declares a reviewer: an email address, a role, or a team. When execution reaches the gate, the system notifies the reviewer with the plan context — what ran upstream, what the outputs were, and what the next step would do. The reviewer approves, rejects, or redirects from that context. Approvals and rejections are logged as plan events. SLA timers escalate unanswered gates automatically.
The plan step transitions to FAILED status, and the plan pauses at that branch point. Upstream completed steps are unaffected — their outputs are preserved. The plan can be retried from the failed step (with the same or a substitute agent), the step can be skipped if it is declared optional, or the plan can be cancelled. The failure and the recovery action are both logged.
Yes. Plans are queryable and steerable in real time through the Observability & Control surface. You can inspect the full DAG state, see what each step produced, pause or resume individual steps, and inject a revised plan that takes effect from the current execution point forward — without interrupting completed upstream work.
Tell us what you're building. A real engineer replies.