Agent harnesses: making AI work inside a controlled workflow

When does this job need tools or an agent rather than a fixed workflow? Start with the required work, then choose the least complex approach you can evaluate. A protocol, interface or convincing demonstration does not establish portability or reliable operation. Those properties are untested and unverified here.

What sits between a model’s answer and useful, authorised work? More than a good prompt. A firm needs to specify which information the system may use, which actions it may take, who reviews the result and what happens when something goes wrong.

A convincing project summary does not establish that the current plan was read, a milestone was approved or anyone authorised a client message. Those are evidence, system-design and business-authority questions.

An agent harness manages work around model calls: supplying context, exposing tools, recording progress and controlling continuation or stopping. Start with one bounded task whose inputs, actions and outcome someone can inspect—not a goal of maximum autonomy.

Start here

• Map the responsibilities. Identify what the model, interface, runtime, router and harness each supply.
• Specify one job. Complete the workflow contract before choosing tools or adding an agent loop.
• Set the test boundary. Use the fictional project update to define evidence, stopping and recovery.

Five responsibilities, not five separate products

This is a practical framework, not an industry standard. One product may combine several responsibilities; a custom system may separate them.

Layer	Responsibility	Question to settle
Model	Generate or transform outputs from supplied inputs	Can it perform this task acceptably?
Interface	Let people or software submit work and inspect results	Can the reviewer inspect sources, output and unresolved issues?
Inference runtime	Execute the model	Where does processing happen, and who operates it?
Router	Select a model or provider destination	Which destinations and fallback routes are permitted?
Harness	Manage context, task state, tool calls and stopping	What controls the next action and records what happened?

A familiar chat window tells you little about processing location or available tools. Interface selection is a separate decision, covered in Web, CLI, IDE, API or messaging?.

Use the simplest workflow that can do the job

Not every useful AI task needs dynamic tool choice.

If a person supplies two approved documents and wants a private summary, one model call followed by review may suffice. A recurring task could use a fixed workflow: retrieve the specified documents, check both are present, request a draft and save it for review.

An agent that chooses its next tool or step may help when the path genuinely varies. That flexibility creates more possible actions and failure paths to evaluate. Add it only when a simpler approach leaves a demonstrated need unmet.

Anthropic’s Building effective agents distinguishes predefined workflows from agents whose models dynamically direct tool use. It recommends simple, composable approaches and discusses feedback, stopping conditions and human checkpoints. Its introduction acknowledges subsequent tooling changes: use it for architectural reasoning, not a current product inventory.

A fixed workflow still needs controls. Source access, private writes and failure handling cannot be left unspecified simply because the sequence is predefined.

Keep context, state and authority distinct

Context is what the model receives for a particular call: instructions, relevant source passages and necessary task information. Include enough to support the job, not every document the firm holds. Preserve dates and versions, and keep client matters separate.

Retrieved material is evidence, not operational authority. A sentence inside a document telling an assistant to send files must not become permission to do so.

Task state records progress beyond the model’s account of events: which sources were read, which draft exists, what failed and what remains unresolved. Distinguish proposed, attempted, confirmed and uncertain actions. “I saved the draft” is not a substitute for an inspectable artifact and a confirmed save.

Authority determines what may happen. A drafting task may read selected sources and write to a private review area without permission to alter project records or send messages. Calling the whole task “read-only” would conceal that private write.

Instructions guide behaviour; they do not remove account permissions. Identify the enforcement boundary and its evidence. Use What may an AI agent read or change? for the detailed identity, permission and refusal checks.

Copy a workflow contract

Complete this before selecting a harness. Replace “relevant documents” with exact resource and version references in a restricted implementation record. Keep credentials out.

Field	What to record
Purpose and owner	One job, its private output and the accountable person.
Information	Required fields or passages; excluded information.
Sources	Approved resources, versions or dates, and how currency is established.
Permitted actions	Exact reads, bounded operations and private output destination.
Denied actions	Excluded reads, source changes, sending and other external effects.
Enforcement	Reference to the identities, controls and permission-test evidence supporting those boundaries.
Human decision	Named reviewer, what they inspect and what their decision permits.
Limits and stops	Retry, time and cost limits; missing evidence, conflicts, denied access and uncertain effects.
Task state	Task ID, source versions, progress, output version and unresolved issues.
Recovery	How to inspect existing results, reconcile uncertain actions and resume or hold.
Evidence	Source references, relevant tool results, artifact and review record; access and retention limits.
Acceptance	Required output quality, required stops and evidence needed to pass.

This is a design record, not proof that controls exist. Mark requirements as unverified until configuration evidence and appropriate tests support them.

Define the finish as carefully as the start. For a private drafting task, ready for human review can be a complete outcome. It does not imply approval, client delivery or a changed business record.

Walk through a private project update

This example is fictional and untested. It uses synthetic documents in an isolated evaluation environment, not a Digital Sanctum implementation.

A consulting team wants a private update covering completed work, upcoming milestones and unresolved decisions. It must not make new commitments.

1. Establish the boundary

The fictional project lead commissions and reviews one draft. Inputs are exactly two nominated, versioned documents: meeting notes and the approved project plan. Other folders are excluded.

Permitted operations are reading those inputs, preparing the draft and saving it in one private review area. Source edits, client-portal updates and sending are denied. Production messaging connections are absent.

Before testing, the owner and implementer must set explicit operating limits and identify the controls supporting this boundary. Writing the rules into a prompt is insufficient.

2. Read the sources and stop on gaps

The workflow checks that both documents are accessible and records their versions. If either is missing, it enters hold and identifies the missing source. It does not substitute an older document or search other client matters.

Suppose the notes describe a revised delivery date while the approved plan retains the earlier date. The workflow stops drafting and records the conflict. It must not silently choose a date or describe the project as “on track”.

The project lead resolves which evidence governs and provides an approved correction or clarification. The task may then resume against the recorded input set.

3. Prepare the private draft

Once required evidence is available and conflicts are resolved, a single drafting call may suffice. The model receives the selected material and a short output structure.

Material milestone statements need source references. The draft must not turn “proposed” into “approved”, infer completion from a scheduled date or present unsupported assurance as fact.

The workflow saves a versioned private artifact with its source list. That permitted write does not authorise changes to the plan.

4. Inspect the artifact

The reviewer opens the saved draft—not just a completion message—and checks accuracy, omitted qualifications and wording against the sources.

The disposition might be “revise”, “hold for evidence” or “accepted as a private draft”. Record the reviewed version. If a source changes afterwards, reassess the affected draft before presenting it as current.

Client sending remains outside this task. An accepted draft still needs a separately authorised communication process with its own content, destination and action controls.

Recover without repeating uncertain actions

A timeout does not necessarily mean nothing happened. A draft may have been saved even if confirmation was lost.

Before repeating a write, use the task and operation references to inspect the destination. If the expected artifact exists, check its version and content. If the outcome cannot be established, record uncertainty and hold rather than blindly creating another draft.

Idempotency means repeating the same operation has the same intended effect as performing it once. A destination may support an idempotency key; otherwise, the workflow needs another explicit reconciliation method. Do not assume either capability exists.

Bound retries and retain the last verified state. A restarted session should establish which inputs were used, whether a draft exists and which decision remains outstanding.

Keep records proportionate. Evidence should explain the result without indiscriminately copying client material or secrets into logs. Apply access and retention limits to operational records as well as sources.

Evaluate the contract, not just the prose

Separate readiness to test from evidence of passing.

Before evaluation, the accountable owner must authorise the isolated scope. Specify synthetic inputs, test identities, output destinations, operating limits and a safe test method. Inspect the proposed access controls and define recovery. Hold if the environment cannot safely contain the tests.

During evaluation, record expected and observed results. Include normal and difficult cases:

Case	Required behaviour
Complete, consistent sources	Produce a traceable private draft without unsupported material claims.
Missing source or conflicting dates	Hold and identify the gap or conflict.
Unavailable processing or exhausted limit	Stop within the contract’s limits and retain useful state.
Interrupted save	Reconcile the destination before repeating the write.
Excluded action	Demonstrate the required boundary using the isolated permission checks.

The reviewer must be able to find the artifact, reconstruct its material sources and record a decision. Measure review effort, rework, time and cost where relevant; this article supplies no results.

Pass within scope only when all required checks have inspectable supporting evidence. Hold when a required result remains unknown or untested. If a requirement fails, record the failure and correct it before claiming a pass.

Passing supports only the tested task, configuration and fixtures. It is not deployment clearance or authority to introduce live client data, broader access or external actions.

Take the next focused question

Use the contract to identify the next decision:

• Web, CLI, IDE, API or messaging?: choose an interface that supports the required context and review.
• What may an AI agent read or change?: map authority and test permitted and refused actions.
• Does MCP make an integration portable?: test replacement without losing required behaviour and controls.
• Is a tool-using agent ready for a bounded pilot?: test task, authority, results and interrupted-write recovery with synthetic fixtures.

The detailed authority record remains in the existing live C2 guide; this guide links to it rather than replacing its body. For rights, operating arrangements and output reuse, use Weights. Coding checks belong to repository preflight and coding-agent evaluation. Product details belong to Hermes; organisational rollout belongs to workforce orchestration.

The first useful question is not “Which agent should we buy?” It is: Can we describe one job’s information, authority, stopping point and evidence clearly enough to evaluate it?

Sources and limits

Primary guidance checked 7 October 2026: Anthropic, Building effective agents, dated 19 December 2024, sections “What are agents?” and “When (and when not) to use agents”. It supports the predefined-workflow/dynamic-tool-use distinction and simple architectural reasoning. Its tooling-change note makes it unsuitable as a current product inventory.

The five responsibilities, workflow contract, example and acceptance criteria are original design recommendations. No agent workflow was executed. Portability, reliability and performance are untested and unverified. None of the controls, recovery steps or review-effort expectations above is an observed implementation result. Current product settings, account access and tool permissions require their own evidence.