Designing enterprise AI systems: models, workflows, agents and harnesses

An invoice arrives with a price above the purchase order. Procurement wants an explanation before the payment deadline. The useful system must find the relevant agreement, identify whether the difference is permitted, show evidence and route the exception to the right person. “Build an agent” describes neither the required business outcome nor the authority the software should receive.

The model is one component of the system#

A language model can propose an explanation, extract candidate fields or request a tool call. The surrounding application authenticates the user, selects authorized evidence, validates requests and decides whether an action is allowed. A tool service executes an allowed operation and returns a receipt. A fluent sentence saying “the invoice is approved” proves none of those steps happened.

Choose where each fact comes from#

Use the purchase-order database for exact quantities and prices. Use a document search service for agreement clauses. Use a policy record for the approval threshold. A model’s general training can help interpret terms, but it should not invent today’s supplier status. For every output field, write down its authoritative source, permitted age and expected behavior when the source is absent.

This mapping is also a cost control. Retrieving a contract is useful when a clause matters; it is unnecessary for multiplying quantity by unit price. Keep public definitions separate from private customer evidence. Attach source IDs and versions to extracted claims so that the reviewer can open the original material instead of trusting a generated summary.

Put business rules in testable code#

Suppose an invoice line is 12 units at 80 currency units, with tax handled separately. The line subtotal is 960. That arithmetic belongs in deterministic code. Whether a change requires two approvers also belongs in an explicit policy. A model can explain a mismatch or identify a possible exception clause, but should not rewrite the approval threshold because a supplier email asks it to.

Validate both shape and meaning. A schema can require a numeric amount and a purchase-order ID; it cannot prove that the order belongs to this supplier or that the remaining balance is sufficient. Check record ownership, currency, version, allowed state transitions and invariants after schema validation. Return a clear review-needed outcome when required facts conflict.

Make the answer inspectable#

A useful exception report contains the discrepancy, the rule applied, the exact supporting clause, unresolved questions and the proposed next step. Separate observed facts from inferred explanations. If a contract has two conflicting amendments, expose the conflict; a confident summary that silently selects one is harder to correct. The reviewer should be able to reject an inference without losing the underlying evidence.

Choose the smallest process that can do the job#

Anthropic’s 2024 Building effective agents article distinguishes code-defined workflows from agents that dynamically choose steps. That architectural distinction remains useful; its page warns that tooling has changed, so it is not a current SDK shopping list. Start with the fixed workflow and add dynamic decisions only where a measured failure requires them. More autonomy increases the space of behavior you must evaluate.

Define the harness by its responsibilities#

In this guide, a harness is the runtime around the model: context construction, available tools, identity, durable state, budgets, approvals, validation, telemetry and recovery. The term is not a universal interface standard. A prompt telling a model to be careful is one instruction inside that runtime; it cannot enforce a database permission or cancel a running external operation.

Long-running tasks also need continuity. Anthropic’s 2025 harness account uses progress artifacts, incremental work and end-to-end checks to address coding-agent failures across sessions. For procurement, the analogous artifact is a structured case record: completed checks, unresolved evidence, proposed action and the last verified external state. It should survive context compaction without turning an unverified model note into business truth.

Give tools narrow contracts and runs hard limits#

Prefer get_purchase_order(order_id) to an unrestricted SQL tool. Return the fields the investigation needs, with source IDs, units, currency and freshness. Reject unknown fields and oversized outputs. Anthropic’s tool-design article motivates task-oriented contracts and useful context; the precise contract here is an application design choice. A narrower tool reduces ambiguity but still needs authorization.

Set maximum steps, elapsed time, tool concurrency and spend before a run starts. Reserve headroom for final reporting and cleanup. Count retries and delegated workers against the same overall budget. Stop when the evidence is insufficient, the same failure repeats or a policy decision denies the next operation. The stopping result should explain what remains unresolved rather than fabricate completion.

Approve an exact action, not a conversation#

Show the reviewer the recipient, amount, currency, record IDs, source evidence and proposed change. Bind approval to a digest of that payload, the approver identity, relevant record versions and an expiry. If the agent later changes the amount or the purchase order changes underneath it, the old approval no longer authorizes execution. Recheck permissions and business state immediately before committing.

OWASP’s Excessive Agency guidance emphasizes minimizing functionality, permissions and autonomy. Apply that principle downstream: even an approved model proposal cannot invoke a service operation the user is not entitled to perform. Human review is meaningful only when the reviewer has enough evidence and the system executes precisely what was reviewed.

Enforce policy at the action boundary#

The execution path should be proposal → schema validation → current authorization → business validation → required approval → commit → verified receipt. Retrieved documents and tool outputs enter as evidence, never as permission grants. Keep the policy decision outside the model. Denials should be auditable and final for that attempted action; the agent must not bypass them by choosing a different tool with broader credentials.

Limit credentials and isolate work#

Use short-lived scoped credentials or a credential-mediating service where practical. Do not place database passwords in prompts or tool descriptions. Separate read-only investigation from write-capable execution. If a task needs code execution, isolate its filesystem, network destinations, resource consumption and secrets. A sandbox reduces available damage; it does not establish that every permitted action is appropriate.

Make stopping an operational feature#

Cancellation needs a state transition, not just a closed browser tab. Stop scheduling new work, signal active workers, expire pending proposals and record external operations whose result is still unknown. A payment request already accepted by a service may require reconciliation rather than cancellation. Surface that distinction to the operator, and do not retry an ambiguous write until its outcome is checked.

Keep useful audit evidence and a real stop control#

Record the run ID, initiating identity, tool and schema versions, policy outcome, evidence references, approvals, receipts and timing. Redact secrets and unnecessary personal data before logging. A dashboard is observability; it is not enforcement. A kill switch should prevent new execution at a shared policy boundary, including background workers, and its behavior should be tested during an in-flight run.

Establish a single-investigator baseline#

Before adding a team of agents, evaluate one bounded investigator using the same tools and evidence. Measure supported conclusions, appropriate abstention, unauthorized attempts, duplicate effects, reviewer effort, total latency and total cost. Keep the held-out cases fixed. A more elaborate system should earn its complexity by improving an important outcome at an acceptable operational cost.

Delegate genuinely independent work#

Finance-policy interpretation and supplier-risk evidence can be separate read-only branches if their objectives are clear. Give each worker an evidence scope, allowed tools, output schema, deadline, budget and handoff recipient. Ask for source-backed findings and unresolved questions. Avoid letting two workers concurrently edit the same business record or duplicate a consequential action.

Anthropic’s multi-agent research account describes parallel branches and coordination costs in its own research product. It is evidence that the pattern can be useful, not a universal performance promise. For a task where every step depends on the previous result, parallel workers may add only handoff latency and contradictory summaries.

Merge evidence, not votes#

Three agents repeating the same obsolete policy are not three independent confirmations. The coordinator should preserve source lineage and compare claims against effective dates and authoritative records. When branches disagree, identify whether they used different versions, interpreted an exception differently or lacked evidence. Route unresolved business ambiguity to the owner of that decision rather than selecting the most confident answer.

Release only as much autonomy as the evidence supports#

Begin with read-only shadow reports, then supervised drafts, then a narrowly scoped write path if the business requires it and evaluation supports it. Define release gates for evidence support, unauthorized-action blocks, duplicate prevention and recovery. Use realistic failures: an unavailable ERP, revoked permissions, conflicting amendments and a late approval. Keep rollback and reconciliation ownership explicit.