Infrastructure · Execution
Agent runs and runtime
The foundation an agent needs before it can be trusted with more than one step, and the control plane that moves a run forward. Both exist in the engine behind authenticated API routes; neither has an interface in Varra.
Run-state foundation Bounded foundation API only Not in Varra
Development status
Most of this is foundation, not product. The authoritative, dated record is build status.
Agents and durable runs
Maturity Run-state foundation Product agents building
Availability API only Not in Varra
There is no general autonomous or background agent: nothing starts a run on its own, and nothing runs while nobody is asking.
Runtime
Maturity Bounded foundation Environments building / future
Availability API only Not in Varra
What exists is deliberately narrow, and it performs no external action.
Agent runs
An Agent Run is bound to one exact Work Item revision, with its own steps, attempts, a bounded lease, a budget, a deadline, cancellation, and records that survive a restart. It exists in the engine behind authenticated API routes and has no interface in the product. Nothing moves without an explicit request from the signed-in owner.
The runtime
The control plane that moves a run forward. What exists is deliberately narrow: one record-only progression that requires a current, passing Assurance verdict, records a single internal step, and then pauses the run. It performs no external action, and a paused run does not mean the work, or the objective behind it, is complete.
Where it sits, and what it is not
Execution is kept separate from the parts that decide and check, because they answer different questions:
Collapsing those into “the agent does it” is how a system ends up acting when it should have stopped. Being able to execute is not the same as being authorized to.
An owner can approve or reject one immutable proposed action — its target, its content and its expiry fixed before anyone decides — bound to the run and the Assurance verdict it came from. An approval covers that one action and nothing else. Team roles, delegated authority and organization-wide policy are not built. Permissions and approvals →
How execution is staged
Even as execution widens, the intent is not to hand over a task and look away:
- Read — take in the documents, systems and context the task involves.
- Recommend — say what should happen and why.
- Prepare — assemble the actual thing: the draft, the entry, the package.
- Execute within approved permissions — and only those.
- Escalate exceptions — anything outside what was granted stops and goes to a person.
Varra in the product does the first three for what you hand it. The fourth exists in one narrow form, for eligible accounts: sending an approved email through Gmail, one per approval, through Relay. Otherwise the last two are the foundations above, not yet a product.
Direction
From the development direction. The order is a dependency order, not a schedule.
- Agents Foundation built — Move from durable run records to agents a person can start, watch, pause and approve inside Varra. No autonomous background operation is planned ahead of that.
- Execution Building / future — Widen where approved work can be carried out: connectors first, then a sandbox, then browser, then desktop. Always behind checks and an approval.
Recent
Infrastructure · — Execution foundations in the engine. Between 20 and 26 September the engine gained durable agent runs, deterministic Assurance verdicts, a record-only runtime step, exact-action approvals and Relay. They were recorded as internal foundations, not product features. News →