Building an Enterprise Agent Harness from Scratch9/10: What Does a Complete Enterprise Agent Look Like?

In Chapter 1, the refund agent had a small loop: the model chose the next step, called a tool, and read the result. It was fast, but it did not know when the task was truly complete or whether money had already been refunded after a timeout.

We have since added a task contract, state, tool boundaries, recovery, permissions, evaluation, and collaboration. Now bring back the order with the duplicate charge and see how those components work together in one system.

The user says, “This order was charged twice. Please refund the extra $42.” The entry point verifies the user and their organization, or tenant, then turns that request into a task with acceptance criteria. The model proposes a refund. Actual execution passes through policy, approval, short-lived credentials, the payment system, and final verification. Each step leaves evidence that the next can use.

Each earlier chapter solved a local problem. This chapter connects those pieces: when a real request arrives, which component takes it first, and what does it pass to the next one?

Divide the Responsibilities into Three Parts

The diagram groups the harness into control, execution, and evidence. These are responsibilities, not ranks in a hierarchy, and they do not require three separate deployments. One service can perform several of them. Their vertical positions organize the diagram; they do not mean that a refund request must pass through control, then execution, and only then evidence.

Control, labeled Control Plane, asks, “Which version is allowed, and under which rules?” It holds the versions of agents, models, prompts, tools, and skills; manages identity and approval rules; and records which versions have passed release checks. Execution reads those configurations and rules to determine which version and tools this $42 refund may use and when it must wait for a person to approve it.

Execution, labeled Execution Plane, asks, “Where has this refund reached, and what happens next?” The entry point establishes completion criteria, and the harness prepares the model's current materials. While the task waits for a manager, the durable runtime saves its progress. Once approval arrives, the tool gateway sends the request to the payment system on the right. The loops, waits, recovery, and tool calls from earlier chapters connect here.

Evidence, labeled Evidence Plane, asks, “What shows that this was done correctly?” It collects events from the start: which action the model proposed, who approved it, and what request the tool sent. Result verification queries the payment system to confirm that the $42 was refunded. Failed verification prevents premature completion or triggers further checks. Incidents and evaluations that reveal systemic problems feed back to control, where release and incident-response code or people can disable a version or change release rules.

Evidence is not a database for all business data. Orders, balances, and refund facts remain the responsibility of the order and payment systems. This part retains linking identifiers, authorization and call records, and verification results from the authoritative systems, so we can match a task to its real business outcome.

Three identifiers at the bottom connect the records. A task ID identifies the refund request, a run ID distinguishes executions, and a stable action ID identifies the business refund itself. A task can run again and receive a different run ID, but the original refund keeps its action ID so the payment service can recognize recovery of the same action. These identifiers let us follow “Where is my money?” back to the approval, call, and payment result.

Control Plane: Manages agent versions, identity, policy, deployment configuration, and release requirements, and provides the active configuration to execution.

Execution Plane: Receives tasks, builds context, calls models and tools, and saves execution progress.

Evidence Plane: Collects execution events, connects task evidence, authorization, and external effects, and supports verification, evaluation, and incident investigation.

Follow One Refund Through the Components

I will now walk through the same refund. At each step, start with the immediate problem, then see what control, execution, and evidence contribute.

The eight numbers show the business sequence: accept the request, prepare context, propose an action, check permissions, execute through the tool gateway with credentials, authorize and deduplicate in the payment backend, query the payment result, and complete with evidence. Control rules, execution state, and evidence records work together throughout. Evidence collection starts well before execution ends.

Step 1: Turn the Request into a Task We Can Verify

“Refund the extra $42” is not enough information. The system must establish which order is involved and what will prove that the request has been handled. Execution verifies the user and organization, then identifies the order, amount, risk, and completion criteria. “Help me investigate” and “Issue a refund” must become different tasks.

Control has already published the permitted agent versions and task rules, but it does not relay every request. The request enters execution directly and receives a task ID and run ID. Evidence collection starts by recording the original request and versions used.

Step 2: Prepare Only the Materials This Refund Needs

Following the control rules, execution retrieves the verified facts for this order, the current progress, and a few recent events. Long-term memory and earlier conversations pass permission and relevance checks before entering the model. This keeps other customers' orders out and prevents unrelated history from burying the current question.

Evidence records which facts and rule versions were used. If the result is wrong later, we can distinguish a problem with the materials, the rules, or a later action.

Step 3: Let the Model Propose the Refund

After reading the materials, the model can propose “Refund $42 to this order,” but it cannot call the payment interface directly. Execution assigns a stable action ID to the proposal. Even after a restart, the same refund retains that ID instead of becoming a new action.

The proposed order, amount, and reason are recorded as evidence. The policy check, human approval, and payment result must all match this proposal.

Step 4: Check Permissions and Wait for Approval When Required

Control holds rules such as which amounts require approval, who may approve them, and which tools are allowed. Execution checks this specific refund against those rules. If manager approval is required, it saves progress and pauses without keeping a process occupied while waiting.

When approval arrives, the system records the approver, time, and action digest. The digest is a content fingerprint calculated from the order, amount, and action in a consistent format. It checks that the approved content matches what is about to execute. Approval for another order or amount cannot pass the tool gateway. The division is concrete: control configures the rules, execution performs the checks and waiting, and the approval record becomes evidence.

Step 5: Execute Safely with a Short-Lived Credential

After authorization, the credential service issues a short-lived credential using the scope and expiry defined by control. It permits only this refund on this order and cannot be used after expiry. The long-lived master key never enters the model context or remains in the isolated execution environment.

The tool gateway checks policy and the credential, then sends the request with its stable action ID and idempotency key to the payment service. Execution saves the existing intent, approval result, and waiting conditions. Credential issuance, gateway checks, and tool calls enter the evidence record along the way.

Step 6: Authorize and Deduplicate Again in the Payment Backend

Permission from the tool gateway is not the final decision. The payment service checks the order ownership it knows and uses the idempotency key to recognize the same refund. That key remains tied to the original action. The payment service saves it with the result, so a repeat request can receive the existing result rather than refunding the money again. Even if the agent or gateway made a mistake, the payment backend can reject an order that does not belong to the current user and avoid executing the same request twice.

Step 7: After a Timeout, Query the Result First

A payment timeout means that the call did not receive a response in time. It does not establish that the refund failed. Execution records the outcome as unknown. When the task resumes, it queries the payment system using the original request ID instead of creating another refund.

Step 8: Verify the Result and Complete with Evidence

The verifier must match three things: the user asked for $42 back; approval, credentials, and the tool call refer to the same action; and the payment system contains one refund ID for the correct order and amount, with a status that meets the task contract rather than merely “processing.” Only when all of these match can the task finish. Missing evidence prevents premature completion and sends execution back to investigate. A systemic problem such as duplicate refunds also feeds into control through incident and evaluation results, triggering version suspension or changes to release rules.

Give Every Responsibility an Owner

With the architecture in place, I assign ownership by responsibility.

The product team defines a completed refund. The payment team maintains authoritative results and idempotency rules. Security maintains tool policies and approval thresholds. Identity issues and revokes credentials. The platform team runs the harness, durable state, and cancellation channels. Quality maintains evaluations and release gates. During an incident, the tool-gateway owner blocks calls, the runtime owner cancels in-flight tasks, and the version owner disables or rolls back the agent.

This allocation exposes gaps. A workflow engine may save progress while nobody queries the payment system, leaving unknown results unresolved. A gateway may enforce policy while nobody checks whether the current user may act on this specific order in the payment backend. Execution records may be complete while nobody defines completion, leaving the agent free to declare success too early.

A minimal deployment does not require a dozen products. It requires clear ownership of the task contract, durable state, tool authorization, external-action deduplication, result verification, evidence retention, and incident response.

Progress in 2026: Products Take on Clearer Runtime Responsibilities

The components we just followed increasingly have concrete counterparts in 2026 products. When reading a release announcement, I place the product back in this diagram: which progress does it save, which rule does it enforce, and which job does it take over?

Anthropic's Managed Agents architecture, published on April 8, 2026, separates runtime history, the execution loop, and the isolated code environment. A session holds that run history, appending a record as each event occurs. The harness runs the loop, and code runs in the isolated environment. If an execution process restarts, it can continue using the retained history. Replacing the code environment does not have to discard the task's records.

Google's Gemini Enterprise Agent Platform, launched on April 22, 2026, connects agent execution, memory, identity, tool permission checks, observability, and evaluation in one platform. For the refund, the value is that these foundations can be connected together: calls link to observable records, and tool entrances link to identity policies. The company then connects order authorization, refund deduplication, and payment-result verification to its own payment system.

Microsoft Agent Framework 1.0 became generally available on April 2, 2026, letting .NET and Python applications organize agent steps in code. The Agent Framework Harness followed on July 22, 2026, providing a customizable loop that connects history, context compaction, approval waits, and call records. If I want to adjust how each round of the refund agent works, this route gives me program components I can change.

Amazon Bedrock AgentCore Harness became generally available on June 17, 2026. Teams configure the runtime, memory, tool gateway, identity, and observability while retaining a path to export Strands code. They can start by configuring the required capabilities and move into code for finer changes later.

The OpenAI Agents API entered public beta on September 10, 2026, offering the execution loop and cloud task records as a managed service. The application submits a task and connects enterprise tools; the platform runs the loop and maintains the session. The company keeps the refund entry point and result verifier on its side of the system.

These products take over different responsibilities. I map a choice against all three parts: who manages versions and rules, runs the loop and saves state, isolates code, issues credentials, controls tools, verifies payment results, and retains evidence across the parts?

Return to the Feedback Loop Between the Three Parts

The $42 refund now makes the relationship clear. Control publishes the permitted versions, tools, and policies. Execution receives the request, prepares materials, waits for approval, calls tools, and saves progress. Evidence connects the proposal, approval, calls, and payment result from the task's entrance onward. They cooperate; they are not three gates that every request must cross in sequence.

During execution, evidence verification can prevent an early declaration of completion or request further investigation. When a systemic problem such as duplicate refunds appears, incident and evaluation results feed back to control, prompting version suspension or changes to release rules. Control supplies the rules, execution performs the work, and evidence checks the result and feeds problems back.

The small, fragile loop from Chapter 1 has not disappeared. It still chooses the next step. It is now surrounded by a system that can preserve, constrain, verify, and explain its work.

One practical question remains: which parts should we build, and which can existing frameworks and product APIs provide? The next chapter uses the same refund to compare four routes.