How we approach autonomous-agent engineering.

A language model can propose the next step. A dependable agent system decides which proposals to accept, runs them under limits, and checks what happened.

We use “agent” in an operational sense: a system that pursues an objective through repeated cycles of planning, acting with tools and checking results. Seven concerns recur in every such system: interpreting the objective, planning, managing context, choosing and executing tools, verifying results, and enforcing safety and approval. The reference model below gives each a name, a responsibility and an interface so they can be designed, tested and replaced separately.

A run is a loop, not a line. After a step executes, the system observes what actually happened and compares it with what it expected. An unexpected result can send the agent back to revise its plan; a check that fails against the acceptance criteria sends it back to retry the step. The loop ends in one of three ways: the criteria are met, a person has to decide, or the run stops safely.

Six components and one control layer. The Planning Engine and the Verification Engine are joined by a feedback loop; the Tool Execution Layer sits inside a permission boundary; Context and Memory is a shared bus every component reads and writes under retention rules. The Safety and Control Layer is deliberately drawn apart: it is not a feature of one component but a constraint on the whole.

Most agent failures begin before the first action, with a request that was ambiguous, under-specified or quietly out of scope. Objective interpretation converts a request into a structured objective, and it insists on one thing before planning starts: a definition of done that can be checked.

A plan is the agent’s commitment about what to do and in what order. Making it explicit, as a stored graph of steps with dependencies rather than a sequence implied by a chain of calls, is what lets anyone review it and lets the system revise it deliberately.

Each step carries the capability it needs and its own checkable criterion. Steps that do not depend on one another can run in parallel. The plan is recorded, can be shown to a person for review before execution, and has limits on size and depth so that decomposition cannot run away.

A tool is a capability with a contract: what it takes, what it returns, what it can change and what it costs. Selecting a tool means matching a plan step to a contract the agent is permitted to use, then preparing the parameters. Only after a policy check does the call reach the execution runtime.

The execution runtime treats every step as a state with allowed transitions: pending, running, awaiting approval, succeeded, failed and retryable, failed and terminal, cancelled. Because transitions are defined, a failure leads somewhere specific. The runtime also checkpoints progress, enforces timeouts and budgets, and offers a stop control that does not depend on the agent’s cooperation.

Context is a budget, and memory is a liability: each fact kept should earn its place and have a reason to expire. The reference model keeps three layers apart so that each can have its own scope and rules.

Done is a checked state. A system reports completion only after the evidence meets the criteria set at the start, and it stores that evidence with the run. The strongest check available for the task is used first.

Where feasible the verifier is kept separate from the actor, because a system tends to miss its own mistakes. Evaluating the system as a whole is a different problem: task-level success against acceptance criteria, step correctness, recovery from failure, cost and time, and how often a person had to intervene. Any one of these numbers can mislead on its own, which is why we treat evaluation method as a research topic. There are no results to report today.

Autonomy is granted in proportion to what a task can break and what can be checked, never by default. The control layer enforces that proportion through permissions, approvals, logging and stop controls. It reduces and exposes risk; it does not remove it.