AI Engineering · 01

Agents are loops with boundaries, not chatbots with ambition.

An agent is a control loop in which a model proposes the next action, a runtime executes it against a constrained tool surface, and the result re-enters context until a stop condition is met. Everything that makes an agent safe to deploy lives in the boundaries around that loop rather than in the model itself.

01

The anatomy of a run

A production run is five components working together. The plan decomposes a goal into ordered steps with declared dependencies. The tool surface defines the only actions the agent can take, each with a typed schema and its own authorization. State carries what has been observed so far, scoped and summarised rather than appended without limit. Policy decides which steps may proceed unattended. And stop conditions — budget, step count, wall clock, repeated failure, and goal satisfaction — bound the loop so it terminates predictably.

Planning loop
Propose, act, observe, revise. The plan is an artifact, produced before execution and updated as evidence arrives, not an implicit trail left behind.
Tool boundary
Agents do not have credentials; tools do. Each tool validates its own inputs, enforces its own scope, and is independently testable without the model.
Context discipline
Long runs fail on context, not intelligence. State is compacted, salient facts pinned, and retrieval scoped to the current step rather than the whole goal.
Stop conditions
Every run declares its terminal states up front. An agent without a budget and a step ceiling is an incident waiting to be scheduled.
02

Why step count is the dominant design variable

Agent reliability compounds multiplicatively. A step that succeeds 95% of the time is excellent in isolation and unusable across twelve sequential steps, where end-to-end success falls to roughly 54%. This single relationship governs most architectural decisions: shorten the chain, raise per-step reliability with deterministic code, or insert checkpoints that let a run recover instead of restarting.

Figure 1

End-to-end success against chain length

Independent per-step reliability compounded over sequential steps. The practical consequence is that reducing a twelve-step plan to six does more for reliability than any prompt revision.

Illustrative reference data — engagement figures vary by environment.

03

Where runs actually lose completion

Instrumented runs rarely fail at a single dramatic point. Attrition accumulates: retrieval returns the wrong document, extraction drops a field, reconciliation cannot match a record, and a fraction of runs land in the human queue by design. A completion funnel makes those losses visible per stage, which is what turns an agent from a demonstration into something an operations team can improve week over week.

Figure 2

Stage completion across an invoice reconciliation run

Percentage of runs reaching each stage unattended. The approval gate is intentional attrition; the extraction and reconciliation drops are the engineering backlog.

Illustrative reference data — engagement figures vary by environment.

04

Use cases

Financial operations

Invoice-to-ERP reconciliation

An agent retrieves the purchase order, extracts invoice fields, matches line items within tolerance, and posts approved matches. Exceptions route to a reviewer with the evidence attached rather than the raw document.

Healthcare administration

Prior authorization assembly

The run gathers chart evidence against payer criteria, assembles the submission packet, and flags missing documentation. Clinical judgement stays with the clinician; the agent removes the assembly labour.

Logistics

Exception management across carriers

Delay and damage events from several carrier APIs are consolidated, scored, and actioned — rebooking within policy, escalating outside it, with the full decision trace retained.