RePerspective LabsFramework
The AI Agent Harness: From Business Intent to Dependable Operations
Ten harness components and one order-change case show how model output becomes controlled work.
Executive summary
An approved order amendment is submitted, then the service times out. The organization must establish whether the order changed before it retries or promises completion. An agent harness provides the execution structure around the model: context, tools, state, controls and evidence. This framework explains ten connected components, follows one order-change case through them, and gives leaders a method for deciding what to reuse, establish and prove. The next commitment depends on the operation’s weakest consequential dependency. If the system cannot reconcile an uncertain result, Narrow the trial to recommendations while that dependency is resolved.
What must hold before an agent changes a business record?
A customer asks to change an order after fulfillment has begun. Understanding the request is useful. Completing it also depends on inventory reservations, payment rules, shipping commitments and the person who must explain the result to the customer.
In the hypothetical operation used here, completion means that the authorized amendment is recorded, the revised customer commitment is communicated, and the designated person in the receiving team accepts the handoff. Refunds, credit exceptions and already dispatched shipments stay with designated people. No performance result is claimed.
My perspective
I would fund the smallest complete operation that can deliver that result and handle the cases it cannot finish. The harness belongs in the first useful trial, together with the people, existing systems and support needed to run it.
Understand the model, the agent and the harness
The model interprets information and proposes a response or next action. The agent combines the model with an execution loop that can use tools and adapt to their results. The harness supplies the runtime responsibilities that make this behavior usable within a defined scope. A fixed workflow can also use a model without needing an adaptive agent loop. [1]
A harness can be assembled, purchased or supplied within a business application. The organization still has to establish the mandate, acceptance criteria, applicable knowledge, staffed review and recovery, and evidence for this operation. These responsibilities belong in the first trial alongside the runtime.
Explore the ten-part harness
The anatomy describes responsibilities, not ten products or ten consecutive steps. One platform may provide several parts, and existing workflows or people may supply others. The model, incoming request and resulting handoff are shown separately from the ten numbered components.
Choose a view. In Components, select a stage to highlight the responsibilities involved, then select any part for its explanation.
INSIDE THE HARNESS
Explore the harness, stage by stage
Example: a customer requests an order change. Establish identity, eligible scope and a case owner.
and propose next steps
Involved in this example stage · Select any part · Investigations may loop back
Entry & assignment and Verify & deliver frame the ten harness components. Tracing records the journey; evaluation tests its behavior.
How do the parts work together?
The loop refreshes context as results arrive.
7 GuardrailsAcross the whole design
SELECTED COMPONENT
Entry & assignment
Establish what has been requested, whether it is eligible and who owns its completion.
In this case
The order-change request becomes an authenticated case with an accountable owner.
When weak
A request enters the wrong scope or has no accountable recipient.
SELECTED COMPONENT
Verify & deliver
Check the result in the authoritative system and complete the receiving handoff before declaring success.
In this case
Confirm the recorded amendment and revised customer commitment. An unresolved submission remains held and escalated.
When weak
A success message conceals an incomplete business outcome.
SELECTED COMPONENT
Routing orchestrator
Classifies and assigns work to an appropriate agent, workflow or person. Routing may use fixed rules or model-based classification; the receiving system still enforces admission and permissions.
In this case
The order-change request enters an eligible service path. Unsupported requests go to the existing queue.
When weak
Misclassification sends work to an unsuitable path or leaves it without an owner.
SELECTED COMPONENT
Context builder
Assembles the instructions, applicable sources, current case evidence and relevant interaction history supplied to each model call. It refreshes context as results arrive; shortening context must preserve information needed for the decision.
In this case
The prompt includes the current order, fulfillment status and change policy.
When weak
A plausible recommendation relies on stale, irrelevant or unauthorized information.
SELECTED COMPONENT
Persistent memory
Stores selected information for reuse across sessions or cases. Retention, access, correction and deletion need an explicit purpose and owner. It is distinct from the current case’s execution state. [2]
In this case
This trial leaves memory unused; current business records provide the needed evidence.
When weak
Unnecessary or stale retained information influences later cases.
SELECTED COMPONENT
Agent loop
Controls repeated model calls, proposed tool use, returned observations and stopping conditions. The model proposes a next step; the runtime checks and executes permitted calls, then supplies their results to the next turn. [1]
In this case
The agent investigates a reservation conflict before preparing the amendment.
When weak
Work loops without progress, exhausts its budget or declares completion too early.
SELECTED COMPONENT
Tools
Expose defined capabilities for reading information or changing systems. The harness executes calls through identities and interfaces with appropriate permissions; a model-generated tool request is not authorization.
In this case
Lookup tools read the order and stock position. A separate narrow tool submits the permitted amendment.
When weak
Broad permissions or unclear retry behavior create unintended effects.
SELECTED COMPONENT
State management
Preserves the current case’s execution record, including status, action identifiers, approval conditions and checkpoints. Durable storage supports waiting, restart and recovery; current-case scope does not mean temporary storage. [2]
In this case
The case moves from awaiting approval to submitted, then confirmed or outcome unknown.
When weak
A restart loses the action history or causes work to be repeated.
SELECTED COMPONENT
Guardrails
Apply checks at input, context, model, tool and output boundaries. Screening may use models, while identity, authorization and transaction rules require enforcement in the executing system. Guardrails support specific obligations; they do not establish compliance on their own. [3]
In this case
Only an eligible, currently authorized amendment can reach the write interface.
When weak
A prompt instruction is mistaken for an enforced permission boundary.
SELECTED COMPONENT
Human approval
Presents a specific proposed action and its evidence to an authorized person when the mandate requires review. Approval binds to the target, parameters and relevant conditions. Waiting and rejection need defined handling.
In this case
The reviewer authorizes this amendment to this order; changed conditions require renewed approval.
When weak
A general approval is reused for a materially different action.
SELECTED COMPONENT
Traces
Link observable model calls, tool requests and results, approvals, errors, state changes, timing and usage to the case. Define what is recorded, redacted, retained and accessible. Do not assume every internal reasoning step is available or suitable to store.
In this case
The operating team can reconstruct the approval, submission and reconciliation.
When weak
The team cannot explain what happened or establish the evidence for recovery.
SELECTED COMPONENT
Evals
Test the model and harness together against defined outcomes and constraints. Use representative cases, repeated trials and adverse scenarios before release and after changes; complement tests with evidence from live operation. [5]
In this case
Tests include stale approvals, denied writes, timeouts after submission and duplicate attempts.
When weak
A polished response passes while the underlying order or control behavior is wrong.
All ten component descriptions
COMPONENT 1 OF 10
Routing orchestrator
Classifies and assigns work to an appropriate agent, workflow or person. Routing may use fixed rules or model-based classification; the receiving system still enforces admission and permissions.
In this case
The order-change request enters an eligible service path. Unsupported requests go to the existing queue.
When weak
Misclassification sends work to an unsuitable path or leaves it without an owner.
COMPONENT 2 OF 10
Context builder
Assembles the instructions, applicable sources, current case evidence and relevant interaction history supplied to each model call. It refreshes context as results arrive; shortening context must preserve information needed for the decision.
In this case
The prompt includes the current order, fulfillment status and change policy.
When weak
A plausible recommendation relies on stale, irrelevant or unauthorized information.
COMPONENT 3 OF 10
Persistent memory
Stores selected information for reuse across sessions or cases. Retention, access, correction and deletion need an explicit purpose and owner. It is distinct from the current case’s execution state. [2]
In this case
This trial leaves memory unused; current business records provide the needed evidence.
When weak
Unnecessary or stale retained information influences later cases.
COMPONENT 4 OF 10
Agent loop
Controls repeated model calls, proposed tool use, returned observations and stopping conditions. The model proposes a next step; the runtime checks and executes permitted calls, then supplies their results to the next turn. [1]
In this case
The agent investigates a reservation conflict before preparing the amendment.
When weak
Work loops without progress, exhausts its budget or declares completion too early.
COMPONENT 5 OF 10
Tools
Expose defined capabilities for reading information or changing systems. The harness executes calls through identities and interfaces with appropriate permissions; a model-generated tool request is not authorization.
In this case
Lookup tools read the order and stock position. A separate narrow tool submits the permitted amendment.
When weak
Broad permissions or unclear retry behavior create unintended effects.
COMPONENT 6 OF 10
State management
Preserves the current case’s execution record, including status, action identifiers, approval conditions and checkpoints. Durable storage supports waiting, restart and recovery; current-case scope does not mean temporary storage. [2]
In this case
The case moves from awaiting approval to submitted, then confirmed or outcome unknown.
When weak
A restart loses the action history or causes work to be repeated.
COMPONENT 7 OF 10
Guardrails
Apply checks at input, context, model, tool and output boundaries. Screening may use models, while identity, authorization and transaction rules require enforcement in the executing system. Guardrails support specific obligations; they do not establish compliance on their own. [3]
In this case
Only an eligible, currently authorized amendment can reach the write interface.
When weak
A prompt instruction is mistaken for an enforced permission boundary.
COMPONENT 8 OF 10
Human approval
Presents a specific proposed action and its evidence to an authorized person when the mandate requires review. Approval binds to the target, parameters and relevant conditions. Waiting and rejection need defined handling.
In this case
The reviewer authorizes this amendment to this order; changed conditions require renewed approval.
When weak
A general approval is reused for a materially different action.
COMPONENT 9 OF 10
Traces
Link observable model calls, tool requests and results, approvals, errors, state changes, timing and usage to the case. Define what is recorded, redacted, retained and accessible. Do not assume every internal reasoning step is available or suitable to store.
In this case
The operating team can reconstruct the approval, submission and reconciliation.
When weak
The team cannot explain what happened or establish the evidence for recovery.
COMPONENT 10 OF 10
Evals
Test the model and harness together against defined outcomes and constraints. Use representative cases, repeated trials and adverse scenarios before release and after changes; complement tests with evidence from live operation. [5]
In this case
Tests include stale approvals, denied writes, timeouts after submission and duplicate attempts.
When weak
A polished response passes while the underlying order or control behavior is wrong.
Three distinctions that prevent expensive mistakes
- Context, state and memory. Context supplies the present decision; durable state records where this case stands; persistent memory carries selected information into later cases.
- Approval and capability. Approval permits one exact action under stated conditions. It is not a reusable capability flag for a different target, amount or changed state.
- Recovery and authority. Recovery restores or reconciles work under an existing mandate. It cannot authorize a different business decision or widen the operation’s scope.
Follow one order change through the harness
The same anatomy now handles a hypothetical request. Each event names the components doing the work. The normal path ends in a verified outcome; a timeout creates a distinct case state that needs reconciliation.
- 1. Route the requestRouting orchestratorAdmit an eligible order-change case.
- 2. Build the contextContext builderUse the current order, fulfillment state and policy.
- 3. Investigate and proposeAgent loop · Model · Tools · GuardrailsRead, observe and refresh context within a time and tool budget.
- 4. Obtain exact approvalHuman approval · State management · GuardrailsHold while the authorized reviewer decides. Rejected or stale approval means revise, decline or escalate.
- 5. Recheck and submitGuardrails · Tools · State managementValidate current conditions and record the action identifier.Timeout after submission → Outcome unknownConfirmation received → continue to step 6
State management preserves the action identifier and uncertainty.
Reconcile the authoritative recordNo blind retry. Follow the applicable outcome:
Amendment confirmed
Continue to step 6: verify and communicate.Confirmed not applied
Recheck authority, current conditions and retry rules. Return to step 5 only if permitted; otherwise hold and escalate.Still unresolved
Hold and escalate. Keep the case held; do not retry. - 6. Verify and communicateTools · State management · GuardrailsConfirm the change and communicate the customer commitment.
Authorized amendment verified, customer informed, and the designated person in the receiving team accepts the handoff.
Traces link observed events across the case. Evals test ordinary and adverse cases before release and after changes. Persistent memory is optional and unused here.
Resolve the uncertain result before continuing
The reviewer has approved the amendment. The execution service rechecks permissions, the order version and the approval conditions, then submits the change with an action identifier. The response times out. The case is now “outcome unknown.” The system has insufficient evidence to call it either completed or failed.
State management preserves the action identifier and the conditions under which submission occurred. A permitted lookup tool checks the authoritative order record. If it confirms the amendment, verification can proceed. If the record establishes that the change did not occur, another attempt still depends on the service’s retry contract and a current mandate. An idempotent interface is designed so repeating the same request does not create an additional effect. [4]
If the result remains ambiguous, hold the case and escalate to the designated person. Preserve the evidence and make the uncertainty visible to the receiving team. Recovery may resume authorized work; it cannot grant a wider mandate or turn a changed proposal into an approved one.
The Operating owner needs a staffed route for waiting and unresolved cases, with response expectations and a fallback when a reviewer is unavailable. The Technology owner must demonstrate reconciliation and restart behavior under the actual downstream system’s conditions.
If that dependency cannot be made dependable, the Outcome owner can Narrow the trial to recommendations. The agent may still assemble evidence and prepare a proposed amendment while a person handles execution through the existing process.
Make the authority arrangement explicit
| Arrangement | Meaning in this proposed trial |
|---|---|
| Recommend | The agent prepares the amendment and supporting evidence; an authorized person decides. |
| Act | The execution service performs only the specific approved action, within its current conditions. |
| Escalate | Unsupported, denied or unresolved cases go to a designated person and remain visibly held. |
| Never Delegate | Designated decisions such as credit exceptions remain with the authorized human role. |
These arrangements attach to decisions and actions. They can coexist in one operation and do not form a maturity ladder.
Make control obligations executable
The Control lead coordinates requirements and evidence with the relevant specialists. The mandated authority accepts residual risk; independent assurance retains its separate duties. Map each consequential risk to an enforced boundary, evidence and a response when that boundary fails.
| Risk | Harness responsibility | Evidence | Failure response |
|---|---|---|---|
| Wrong or manipulated context | Context builder · Guardrails Check applicability and information access. | Conflicting-source and injection cases. | Withhold affected output; obtain qualified review. |
| Unauthorized or duplicate effects | Tools · Guardrails · State management Enforce narrow permissions and exact authorization. | Denied-action, stale-approval and timeout-after-effect tests. | Stop affected execution; reconcile before retry. |
| Confidential-data exposure | Context builder · Persistent memory · Traces Control purpose, access and retention. | Data-flow review; access and deletion evidence. | Contain exposure; invoke the incident process. |
| Unavailable human intervention | Human approval · Routing orchestrator · State management Provide reviewers and visible waits. | Queue age, coverage and absence rehearsals. | Reduce intake or authority; use the staffed fallback. |
| Unreliable outcomes | Evals · Tools Test outcomes and verify recorded effects. | Failure cases, reviewed samples and follow-up. | Hold affected cases; correct consequences. |
| Supplier or release change | Tools · Guardrails · State management · Traces Check versions, regression and recovery. | Change records, service conditions and recovery tests. | Roll back where effective; isolate or switch under the approved plan. |
OWASP’s excessive-agency guidance supports narrow tool capabilities and permissions enforced in downstream systems. [6] Approval also consumes operating capacity: specify who receives the request, what evidence they see, how long it can wait and what happens if nobody responds. An emergency stop needs a named owner and rehearsed handling for work already submitted.
Apply the framework to one bounded operation
Bring ordinary cases, difficult exceptions, current costs and the existing authorization model. The Outcome owner and Operating owner work with the Knowledge owner, Technology owner and Control lead to identify what already provides each responsibility and what must be proved.
| Commitment | What to establish | Evidence for the next decision |
|---|---|---|
| Define the outcome Outcome owner | Eligible cases, acceptance criteria, baseline and constraints. Compare process changes, conventional automation, AI assistance and agents. | One bounded outcome with a named acceptor and a reason to test the chosen approach. |
| Map existing provision Operating and Technology owners | Map the ten responsibilities to workflow, knowledge, identity, application and monitoring services. Record justified exclusions. | Actual provision, responsible owners, uncovered dependencies and conditions for revisiting exclusions. |
| Set authority and intervention Mandated authority and Operating owner | Permitted reads and writes, required approvals, retained decisions, waiting states, staffed escalation and support. | A defined mandate with tested denial, changed-condition and unavailable-reviewer cases. |
| Prove execution and recovery Technology and Knowledge owners | Test applicable evidence, tool results, context changes, restart behavior, timeouts and accepted outcomes. | Traces and Evals showing what happened under representative and adverse conditions. |
| Review the commitment Outcome owner | Consider value, evidence, service capacity and unresolved risks. The Control lead coordinates specialist requirements and evidence. | A recorded decision, affected scope, conditions, responsible owners and next review. |
Keep one decision record in the operation’s normal review process. Include scope, authority, coverage, owners, evidence, measurement and the next decision. The mandated authority accepts residual risk; independent assurance retains its separate duties.
Use only the components the scope needs
A fixed drafting workflow that makes one model call may need no adaptive Agent loop, separate Routing orchestrator or Persistent memory. It still needs applicable context, access controls, an accountable recipient and tests for unsupported output. An information-only operation that waits across sessions may still need durable State management. Record an exclusion’s reason, owner and revisit condition.
Existing workflow, identity, knowledge and monitoring services can support several journeys. Expand shared provision when repeated demand and operating evidence justify a common service, with funding, support and change ownership. Journey teams retain responsibility for their own outcome and acceptance criteria.
Measure the outcome and the operating conditions
Agree the case mix, observation period and acceptance follow-up before the trial. Compare against the current operation or a suitable concurrent comparison. Use five distinct lenses; none substitutes for the others.
| Lens | What the owner needs to know |
|---|---|
| Expected value | Is the problem worth addressing, and does the proposed approach compare favorably with simpler alternatives? |
| Readiness for this scope | Are permissions, knowledge, people, execution and recovery supported by evidence for the next increment? |
| Capability maturity | Does the operation remain dependable through changes, incidents and continuing maintenance? |
| Realized value | Do accepted outcomes improve quality, elapsed time, human effort and recurring cost on a matched cohort? |
| Control performance | Do denial, approval, escalation and recovery work? Track unauthorized effects, duplicate actions and unresolved cases. |
Assess recurring economics with Cost per accepted outcome, using the scope, acceptance conditions and cost treatment defined on Measurement.
Describe coverage as Unknown, Unestablished, Designed, Implemented, Demonstrated or Maintained. Use Not required for this scope with a reason, owner and revisit condition. These evidence descriptions do not form a scored maturity ladder, and a product name establishes neither readiness nor demonstrated performance.
Where this framework stops
This framework connects the runtime responsibilities of one operation. Bounded Autonomy defines the mandate; Governing AI-Enabled Operations addresses permission to run and change the service; Assuring AI Services addresses continuing evidence; and Enterprise AI Enablement addresses provision across teams. The order-change case is an illustration, not a universal reference architecture.
Leadership takeaway
Ask the team to walk one real request through its proposed operation. They should be able to show what the model proposes, what the harness permits, who approves, what the system records and how uncertainty is resolved. Fund the smallest complete scope that can produce an accepted result and sustain its support. At review, choose Expand, Continue, Narrow, Redesign or Stop using the evidence and the capacity to operate. A strong model cannot compensate for an unresolved authorization or recovery dependency.
Where to go deeper
- Enterprise AI Enablement — What the enterprise provides and what individual journey teams continue to own.
- Bounded Autonomy — The mandate and conditions behind Recommend, Act, Escalate and Never Delegate.
- Governing AI-Enabled Operations — Who may authorize the operation and changes to its scope, controls and dependencies.
- Assuring AI Services from Release to Retirement — How evidence is maintained as services and dependencies change.
Sources and further reading
The ten-part anatomy and application method are RePerspective Labs editorial synthesis. Sources support specific technical premises; they do not validate the complete framework. The order-change scenario is hypothetical. Source links and relevant documentation checked November 5, 2026.
Anthropic — Building effective agents
December 19, 2024
Workflow and agent distinctions, composable patterns and the case for starting with the simplest useful design. Historical tooling examples are not a current product comparison.Google Agent Development Kit — Conversational context
Living documentation checked November 5, 2026
Session, state and cross-session memory distinctions. Product-specific terminology illustrates the responsibilities; it does not prescribe this framework.Google Agent Development Kit — Safety and security for AI agents
Living documentation checked November 5, 2026
Identity, tool authorization, callbacks, model-based screening and layered controls. These mechanisms do not constitute a compliance determination.AWS Builders’ Library — Making retries safe with idempotent APIs — Official PDF
Living engineering reference checked November 5, 2026
Ambiguous outcomes, request identifiers and retry semantics. The actual downstream service contract determines what is safe.Anthropic — Demystifying evals for AI agents
January 9, 2026
Evaluating model and harness together, repeated trials and the distinction between a completion claim and an observed environmental outcome.OWASP Gen AI Security Project — LLM06:2025 Excessive Agency
2025 edition; checked November 5, 2026
Functionality, permission and autonomy risks, with mitigations at tool and downstream permission boundaries. Practical guidance, not a complete assurance standard.