Engage

An agent is a control loop with a declared reach

The decomposition has two parts. A short sequence of steps that repeats, and an explicit inventory of what the agent is permitted to reach. The second part constitutes the design: the inventory determines capability, determines exposure, and determines how much governance the deployment actually requires.

Part one · the loop

ObserveReasonActVerify↺ until completion, or until escalation

That sequence is the whole of an agent loop. Claude Code and Codex both implement one, and Damco writes narrower loops that perform a single job. The steps are identical across all three, and the inventory below is what distinguishes them.

Part two · what you hand it

A general-purpose host
A dedicated machine with a filesystem and installed programs. Confers everything an operator could perform at that keyboard.
A browser
Interactive access to web applications on the same terms as an operator: authentication, navigation, retrieval, form submission.
A declared tool inventory
An enumerated set of operations — retrieve this policy, look up that claim, calculate this figure. The inventory is authored by the client.
Retained state
Prior executions, and the corrections reviewers applied to them. Without retained state the agent begins each session with no accumulated context.
Everything not enumerated
Absent rather than blocked. An operation outside the inventory has no representation in the agent's execution environment.

An agent is therefore not a capable system requiring containment. An agent is a constrained system whose reach is enumerated, and the defensible answer to a review board asking what the agent can perform is the inventory itself.

The decomposition

Six blocks, and the decision each one forces

Six blocks constitute an agent deployment. Damco constructs four of them, nominates the fifth with the client, and instruments the sixth from first release. Each block forces one architectural decision, and the right-hand column states which.

01

Review surface

The presentation layer through which an operator receives prepared work and issues approval.

A purpose-built console for the role, or an integration into the collaboration platform the team already operates.

Decision required

Whether the surface is constructed or adopted. Reversible at low cost, and independent of the remaining five blocks.

02

Domain ontology

The controlled vocabulary binding business terms to system entities, states and authority thresholds.

The slice the job in scope requires. Not an enterprise-wide model, and not a prerequisite programme.

Decision required

Which entities the job touches, and which system holds the authoritative definition where two disagree.

03

Gateway

The policy enforcement and audit boundary between every agent and every system of record.

One integration layer serving all agents: authorization decision, audit record, and, for read-only jobs, the data itself.

Decision required

Whether an existing integration layer is reused or a governed layer is constructed. Expanded in the section below.

04

Runtime

The execution environment hosting the control loop.

Deployment to the environment nominated during Strategize: a managed service, an ephemeral instance, or the operator's own workstation.

Decision required

Tenancy and data residency. Determined by data classification and by existing platform commitments, not by preference.

05

Correction store

Retained state across executions, including every amendment a reviewer applied to prepared work.

A store bound to the job specification, so reviewer intervention becomes measurable signal rather than unrecorded rework.

Decision required

Retention period, and which fields within retained state constitute personal data under the applicable regime.

06

Instrumentation

Continuous measurement of correction rate, escalation rate, and the business metric the job is accountable to.

Instrumented from first release and reported monthly, with the baseline captured before deployment.

Decision required

The correction-rate threshold at which autonomy is extended, and the duration over which that threshold must hold.

Blocks 01 and 04 are delivery decisions and remain reversible. Blocks 02, 03 and 06 are governance decisions, and altering any of the three after deployment is materially more expensive than settling it during Strategize.

Block 03, expanded

One policy enforcement boundary, not one per agent

The tool inventory describes what the agent may request. The gateway determines what the agent actually receives. Damco constructs one gateway across your software, and every agent action traverses it.

AgentHolds a declared tool inventory, and no alternative route
GatewayAuthorization decision · audit record · read model where applicable
Systems of recordOne integration, irrespective of agent count
Authorization decisionEvaluated per agent, per action, at request time. Policy is administered centrally rather than replicated into each agent.
Audit recordEvery action recorded with the source material read and the execution timestamp. Enforced by construction, so no configuration omission can suppress a record.
Materialised read modelWhere the job requires read access only, the gateway maintains the copy the agent queries and the system of record is never contacted.

A governed layer, constructed

custom MCP

Regulated industries

Every call traverses software Damco authored, so auditability is a structural property rather than an operational commitment. This is the configuration that withstands an examiner reconstructing how a specific decision was reached.

The integration layer already in place

client MCPs

Where the capability exists

Where your software already runs a suitable layer, Damco integrates with it. Damco will not rebuild a functioning integration for architectural symmetry, and will state plainly where the client's component is the stronger one.

A maintained read model

Read-only jobs

Damco maintains a current copy of the material the job requires, and the agent queries that copy. The system of record carries no additional load and presents no additional failure surface.

Introducing a fifth agent changes nothing on the systems-of-record side. That property is the entire justification for a single gateway: the marginal cost of the next agent is the inventory authored for it, rather than a further integration into a system the organisation is reluctant to modify.

The conditions that cannot move

Designing against enterprise constraints

Every enterprise holds a small number of conditions that cannot be altered for a project. Those conditions are the reason a reference architecture fails on contact with software a business actually runs. Damco establishes them at the opening of Strategize rather than pricing around them at the close, and each one resolves to a specific decision in the block table above.

A core system that cannot be replaced
No agent writes inside the system of record. Actions are issued through the gateway, so policy administration receives one integration rather than a new dependency.
Gateway
A regulator entitled to reconstruct a decision
Every case retains the reasoning and every action carries an audit record, instrumented from first release rather than retrofitted under examination.
Gateway · Instrumentation
Data that cannot leave the tenancy
The gateway governs egress. The runtime is deployable inside the client's own cloud, which reduces model selection to a configuration decision rather than a re-platforming exercise.
Runtime
An operator population that will not adopt a further tool
The review surface is delivered into the platform the team already operates, and no additional client software is installed.
Review surface
Committed AI expenditure
Damco inventories held licences and platform commitments before quoting. Where an enterprise agreement already covers the runtime, that component is not billed.
Runtime

None of the five requires an exception to the reference model. Each resolves to a decision the block table already anticipates, which is the property that distinguishes a reference architecture from a diagram.

One drawing, four times

Four patterns account for almost every deployment

Each pattern is the four slots established above — control loop, declared reach, gateway, systems of record — with different components provisioned. Read the first and the remaining three follow, because the slot that varies materially is the second, and the second is the inventory the client authors.

Operational agent

Executes one queue an operator currently owns.

The default where the job resides inside your software and an operator performs it today. Reach is enumerated, and every action produces an audit record.

Claims intake · prior authorisation · RFQ response

Read-model agent

Answers from a maintained copy, and never contacts the original.

This is the lowest-exposure way to begin. Where the job requires read access only, the system of record is absent from the execution path, carries no additional load, and presents no additional failure surface.

Chart preparation · lane quoting · month-end close preparation

External-research agent

Operates outside the perimeter, so nothing inside it is opened.

No gateway is provisioned because no internal resource is in scope. The exposure question largely resolves itself, which is why this pattern is frequently the first agent a conservative enterprise authorises.

Market assessment · due diligence · supplier research

Engineering agent

Modifies software and submits the change for review.

A general-purpose host means an instance Damco provisions for the job and destroys afterwards. Never a client machine, and never one holding a route to production. This is the pattern the software factory operates.

The software factory · migrations · test coverage

provisionedgateway — every action traverses itabsent — not blocked, not present

None of the four is exotic and none constitutes a separate product. Changing pattern means changing the inventory, which is why the marginal cost of an additional agent is the inventory authored for it.

The generating axes

Declared reach and hosting are settled separately

Declared reach and hosting location are independent decisions. Reach determines capability and exposure, and is settled under governance. Hosting is a delivery decision settled under data classification. Every populated cell is a configuration Damco builds; every empty cell is one Damco does not.

Operational agent
reaches declared tool inventory · runs on managed service
Operational agent, local
reaches declared tool inventory · runs on operator workstation
Read-model agent
reaches maintained read model · runs on managed service
External-research agent
reaches browser only · runs on ephemeral instance
Engineering agent
reaches general-purpose host · runs on ephemeral instance
Engineering agent, local
reaches general-purpose host · runs on operator workstation

Provisioning a general-purpose host means provisioning an instance Damco creates for the job and destroys on completion, never a client machine. That is the single point at which the two axes constrain one another.

Invariant across all four

Two properties hold irrespective of pattern

Two properties are invariant across all four patterns and across every hosting decision, which is what qualifies reach and hosting as delivery decisions rather than governance ones.

For the operator

Prepared work arrives on a surface built for the role

Queue and documentBoardChatTerminal
Work arrives prepared
The operator opens a conventional screen, reviews the findings, and issues approval. No prompting, and no new tool to learn.
Delivered where the team already operates
Or onto a surface built for the single role. No operator adopts new software in order to perform an existing job.
The surface remains a separate decision
Begin with whichever surface is cheapest to trial, and construct the purpose-built one once the job has demonstrated value.

For the work

Reach is enumerated and every action is recorded

One policy pointComplete audit recordReviewer approval
Policy is administered in one place
Not per agent and not per workstation. Amending policy at the gateway amends behaviour across every agent you run.
Every action is recorded
With the source material read and the reasoning retained. An examiner receives an audit trail rather than a reconstruction.
A reviewer approves anything material
Until the enterprise determines otherwise, against a threshold the enterprise authored and can revise.

Governance

Reviewed first. Delegated on a recorded threshold.

Damco does not propose removing a reviewer at go-live. The first release prepares work for approval, and autonomy is extended subsequently against a threshold recorded during Strategize.

Reviewed

first release
  • The agent accepts the case, reads the material, and prepares the decision.
  • A reviewer approves every case before any action is committed.
  • Reviewer amendments are captured to the correction store as measurable signal.

Delegated

on threshold
  • The agent holds the task within a boundary the enterprise recorded in writing.
  • A reviewer examines a sample, plus every escalated exception.
  • Cases outside the boundary continue to route to a named individual.

Both states are the same build. Transition between them is a configuration change at the gateway rather than a second engagement, which is why Damco requires the boundary to be agreed during Strategize rather than renegotiated after a year in service.

The promotion rule is recorded at scoping: autonomy is extended when the correction rate remains below an agreed figure across an agreed number of consecutive weeks.

Describe the job, and Damco will identify the pattern, the blocks in scope, and the systems the deployment would need to reach.

The enterprise stack, layer by layer →← AI Agents
Let's build an AI agent

Where the assessment concludes that no agent is warranted, Damco reports that conclusion.