Why six parts and not five or seven?

Six is what survives in production. We have shipped operators with fewer parts; they fail in predictable ways. We have shipped operators with more parts; the additional complexity adds maintenance cost without reducing the failure rate.

Does an operator need its own infrastructure or can it run on shared compute?

It needs its own contained environment per workflow. Shared compute is fine, but shared state is not. The container boundary is what makes the blast radius predictable.

How does the audit log scale?

In practice it is one write per tool call plus one write per model decision. For typical workflows that is a few hundred records per day per operator. MongoDB handles it easily; the bottleneck is query patterns for retrospective review, not write volume.

Can we use an open-source model instead of Anthropic or OpenAI?

Yes for some workflows. The trade-off is regression discipline: open-source models change faster and have less stable behavior across versions. We deploy them when latency or data-residency requirements demand it; otherwise commercial closed models reduce the operating burden.

What does AIMOCS do after the four-to-six-week deployment?

We run the operator. We maintain the model version discipline, we triage the escalation queue, we run the monthly log review with the workflow owner, and we ship workflow tier updates as the team learns where to widen the authority bar. The operator is software the customer owns; the operations are AIMOCS work.

AIMOCS · White papers

White paper

The autonomous operator: anatomy, deployment, governance

What an autonomous operator actually is, how the pieces fit together in production, and the governance model that keeps it trustworthy at scale.

Updated · 2026-05-21

14 min read

from kickoff to first money on the workflow

4–6weeks

in the production-grade operator anatomy

6parts

of actions logged with the reasoning that produced them

100%

01Abstract

02Definition

What an operator is — and what it isn't

An autonomous operator is a software system that owns a specific business workflow end-to-end: it monitors the trigger, gathers the context, decides what to do, takes the action, handles the exception, and escalates only when the workflow truly requires human judgment. It is not a chatbot. It is not a workflow automation tool with a language-model bolted on. It is not a feature inside a larger SaaS. It is a contained, accountable software system whose unit of work is the workflow, not the prompt.

We have spent two years deploying these systems against real money and real customers. The pattern that survives contact with production is consistent enough that we describe it here as the anatomy — six parts, each with a job, each with the failure modes its job exists to prevent.

03Architecture

The six-part anatomy

Computer

Each operator runs in its own contained environment — typically a container with the minimum toolchain the workflow requires. The container is the agent's blast radius. A misfired command can break the container; it cannot reach the host filesystem, another operator's memory, or a production cluster. The boundary is enforced at the runtime, not at the prompt.

Memory

A persistent store that holds the operator's knowledge of accounts, conversation history, and learned preferences. Memory is what makes the operator behave like an employee across runs rather than a stateless function. We use Supabase or MongoDB depending on the access pattern, fronted by a small typed API the operator calls through its tool gateway.

Tools

The set of actions the operator is allowed to take in the world. Tools are explicitly enumerated: opening a Stripe payment intent, updating a Linear ticket, sending an outbound SMS through Hermes, querying a Datadog dashboard. Each tool is registered with its minimum scope. The operator cannot synthesise new tools at runtime; it can only compose the ones it already has.

Guardrails

The signed authority bar. A written specification of what the operator is allowed to do without human approval for this workflow at this tier. The authority bar lives in code, not in the prompt — the model can be jailbroken, asked to forget its instructions, or simply hallucinate. The authority bar is enforced by the tool gateway, which refuses calls outside the bar and routes them to escalation.

Escalation

The path the operator takes when it cannot or should not act on its own. Escalation is a feature, not a failure. A trustworthy operator escalates often early in deployment and progressively less as the workflow scope tightens. Escalations carry the full conversation context, the operator's stated reasoning, and a recommended next step, so the human picks up where the operator left off.

Audit log

An immutable, append-only record of every action the operator took and the reasoning that produced it. The audit log is the only artifact that justifies trust over time. It must be queryable by finance, legal, security, and the workflow owner; it must be retained per the customer's jurisdiction; it must be impossible for the operator itself to edit. The log is the difference between an opaque automation and an accountable employee.

04How we ship

Deployment sequence

AIMOCS ships an operator on a single workflow in four to six weeks. The sequence is not flexible — every step exists because we have seen what happens when it is skipped.

01Week one — workflow mapping. We sit with the team that owns the workflow today and document exactly how it runs: the triggers, the inputs, the decision points, the exceptions, the handoffs. This becomes the operator's specification. It is also the document that catches the bad workflows: any workflow that cannot be mapped this way is not yet ready to be operatorised.
02Weeks two-three — integration. We wire the tools the operator will use through the gateway (Glama is our default), connect the memory store, define the authority bar in code, and stand up the audit-log pipeline. The container image is built and tested against a synthetic input set.
03Week four — shadow operation. The operator runs against real customer data but its outbound actions are caught and queued for a human to review before they execute. The human approves or rejects each action; both decisions are logged. This is where the model behaviour, the authority bar, and the workflow specification are tuned together.
04Weeks five-six — graduated handover. The operator's authority bar widens one workflow tier at a time: low-stakes actions go autonomous first; high-stakes actions remain in shadow. By the end of week six the operator owns the routine work; the human owns the exceptions; both work from the same audit log.

Workflows that take longer than six weeks usually fail not at the technology but at the workflow specification. A workflow no one can describe in writing is a workflow no operator can run reliably.

05How we keep it trustworthy

The governance model

Three disciplines distinguish an operator that survives a year in production from one that gets quietly turned off after a quarter: frozen model versions, signed authority bars, and the immutable log.

Frozen model versions

The model the operator uses is pinned by version. New versions of Claude, GPT, or whatever model we are using do not automatically reach the operator. They go through a regression suite that replays the last 30 days of operator runs against the new version and reports any divergence. Drift in model behaviour is the single biggest invisible failure mode for production agents; this discipline catches it before it touches a customer.

Signed authority bars

The list of actions the operator can take without human approval is a signed, versioned artifact. Changing it requires a deliberate review with the workflow owner. The bar lives in the same Git repository as the operator and is part of every deploy. Auditors can see exactly what the operator was allowed to do on any given date.

The immutable log

Every action — and the model's stated reasoning for it — lands in MongoDB as an append-only record. The operator never touches the log directly; the tool gateway writes it as a side effect of every tool call. Finance reads the log when reconciling. Legal reads the log on a dispute. Security reads the log on a suspected incident. The log is the single source of truth that lets the operator be trusted by people who would never otherwise trust software with their workflow.

06What goes wrong

Failure modes we have seen

Model drift. New model version, slightly different behaviour, no one notices until a week later when a regulated message has been sent with the wrong wording. The frozen-version + regression-suite discipline exists for this.
Authority creep. A workflow owner asks the operator to handle "just one more thing" without updating the signed authority bar. Eventually the operator is doing things it was never reviewed to do. The discipline of treating the bar as a versioned artifact catches this.
Tool sprawl. Someone gives the operator a new tool — say, write access to a CRM field — without thinking about the blast radius. Months later that tool is misused. The Glama gateway with scoped tokens per workflow keeps the blast radius small even when this happens.
Silent escalation backlog. The operator escalates correctly but no one is reading the escalation queue. The work piles up and the team loses faith. We instrument the escalation queue with the same observability as a customer support queue.
Audit-log rot. The log accumulates and no one queries it until they have to. We require the workflow owner to run a monthly five-minute log review — not for security, but to keep the log usable when it is needed.

07Boundaries

When not to deploy an operator

The most useful test of whether a workflow is ready to be operatorised is the writing test: if no one can write the workflow down in 500 words without contradictions, the workflow is not ready. Operators codify and execute; they do not invent.

We have turned down deployments where the workflow was the wrong fit. Workflows that involve high-context human judgment — customer escalation calls, security postmortems, original strategic decisions — do not belong to operators. They belong to humans. The operator can do the boring scaffolding around them; it should not be the thing making the call.

The right deployment of an operator removes the routine work that is currently being done badly by humans who are bored or interrupted, and frees those humans for the work where their judgment is the value. That is the deployment that survives a year in production and keeps surviving.

Questions

Why six parts and not five or seven?
Six is what survives in production. We have shipped operators with fewer parts; they fail in predictable ways. We have shipped operators with more parts; the additional complexity adds maintenance cost without reducing the failure rate.
Does an operator need its own infrastructure or can it run on shared compute?
It needs its own contained environment per workflow. Shared compute is fine, but shared state is not. The container boundary is what makes the blast radius predictable.
How does the audit log scale?
In practice it is one write per tool call plus one write per model decision. For typical workflows that is a few hundred records per day per operator. MongoDB handles it easily; the bottleneck is query patterns for retrospective review, not write volume.
Can we use an open-source model instead of Anthropic or OpenAI?
Yes for some workflows. The trade-off is regression discipline: open-source models change faster and have less stable behavior across versions. We deploy them when latency or data-residency requirements demand it; otherwise commercial closed models reduce the operating burden.
What does AIMOCS do after the four-to-six-week deployment?
We run the operator. We maintain the model version discipline, we triage the escalation queue, we run the monthly log review with the workflow owner, and we ship workflow tier updates as the team learns where to widen the authority bar. The operator is software the customer owns; the operations are AIMOCS work.

Citations

[1]Anatomy diagram and AIMOCS Operator product page — aimocs.com/operator.
[2]Best tool stack for Hermes agents — aimocs.com/stack/hermes.
[3]Operator security and audit — aimocs.com/papers/operator-security-audit.