A working definition
We use the term for an application architecture, not a replacement for your computer’s operating system or a single industry standard. The model reasons about a task. The surrounding software decides which actions exist, whether they are allowed, what state survives, and how someone can intervene.
A short, one-step task may need only a prompt. A repeated procedure can live in a skill. Work that waits for events, crosses tools, or resumes after failure needs explicit orchestration. Adding multiple agents is a separate design choice, useful only when roles and handoffs justify the added coordination.
The five parts to design
Task and authority
A task records the requested outcome, owner, permitted tools, and actions that need review. A document retrieved during the task can supply evidence; it cannot grant the agent new authority.
State and evidence
Persist the task status, input revision, completed steps, and evidence references outside the model’s conversation. On resume, recheck facts that can change, such as an approval or a deployment revision.
Tools and permissions
Expose narrow operations with validated inputs. Separate reading from writing. Enforce access in the service that owns the data; a prompt saying “only read permitted files” cannot replace an authorization check.
Scheduling and recovery
Record why a task should wake: an event, a deadline, or a meaningful state change. Give retries a limit and an owner. Before retrying an uncertain write, reconcile the existing result using a stable operation ID.
Evaluation and observation
Record decisions and tool outcomes without collecting unnecessary private data. Test ordinary inputs, hostile source instructions, duplicate events, revoked access, and interruptions. Define what an operator should see when the task cannot finish.
Example: turn an approved request into a draft
This illustrative intake workflow shows where durable state and review belong. It is a design example, not a claim about a deployed client system.
- 1. Receive. Store the event ID and source revision. If that event is already processed, return the existing result.
- 2. Validate. Check the request has an owner and required fields. Missing information moves it to “needs input” with a visible reason.
- 3. Draft. The agent prepares a proposed tracker row with references to the source. It has no permission to approve the request.
- 4. Review. An operator approves the exact draft revision. If the draft changes, the old approval no longer covers it.
- 5. Write and reconcile. A narrow tool writes the approved row using a stable operation ID. If the response times out, check whether the row exists before retrying.
- 6. Close. Record the resulting row ID and outcome. A failed final write stays visible to the owner with the next recovery action.
Choose the smallest useful layer
| Layer | Owns | Example |
|---|---|---|
| Prompt | Instructions and context for a task | Extract requirements from an RFP |
| Skill | A repeatable, inspectable procedure | Prepare an evidence-based handoff |
| Agent OS | State, permissions, scheduling, and recovery | Resume an approved workflow after a tool timeout |
What to verify before expanding autonomy
- Deliver the same event twice and confirm one intended outcome.
- Revoke access between planning and execution and confirm the write is denied.
- Place conflicting instructions in a retrieved document and confirm they cannot change task authority.
- Interrupt the task after a write and confirm resuming reconciles existing state.
- Change a draft after approval and confirm a new review is required.
- Exhaust retries and confirm the owner sees the failure and recovery path.
Keep local tests, integration checks, and production evidence distinct. A readable trace helps investigate failures; it does not by itself establish that the system is correct.
Build from a real workflow
Start with one repeated task, its ordinary input, its hardest exception, and the person accountable for the result. Measure the existing process before estimating savings. Add a second agent or broader tool access when the observed workflow needs it.
Our Cortex project overview describes our internal agent orchestration work. For a team starting with a specific operating problem, AI workflow automation explains the engagement path.
Primary references and scope
The architecture and example above are Vertical Labs guidance. These primary references describe related building blocks; none defines the whole operating model for you.
- Agent Skills specification: the file format for reusable agent procedures.
- Model Context Protocol introduction: connecting AI applications to external tools and data.
- LangGraph: an implementation option for stateful orchestration.