Building the systems that help AI finish real work
An AI assistant prepares a customer onboarding plan, creates the project workspace, and starts assigning tasks. Then a connection fails. When the assistant resumes, it creates the workspace again, repeats several assignments, and reports that onboarding is complete. The original plan was sensible. The work still went wrong.
This hypothetical example captures a problem that is easy to miss in an impressive demonstration. Producing a good answer and carrying a task through interruptions, checks, and external actions are different challenges. To judge an agent, we need to examine the process surrounding its responses.
Harness engineering addresses that surrounding process. In this article, an AI harness means the software and operating environment that runs an agent: it calls the model, makes tools available, manages task state, processes results, and determines when work may continue or must stop. The term is used with varying scope. Anthropic describes a harness as the loop that calls the model and routes its tool calls; OpenAI’s engineering account also emphasizes the broader environment and feedback systems supporting agent work. [1, 2]
For a business leader, the central question is whether the system can turn an intention into a verifiable outcome. For a builder, it is how to make that possible without constructing an unnecessarily complicated machine. Both questions require looking beyond the wording of the request.
What happens after the first good response
A customer onboarding workflow has several kinds of work. Some require interpretation, such as extracting unusual requirements from an agreement. Others require predictable operations, such as creating a project with a unique customer identifier. Still others require a person’s decision, such as approving an exception to the standard delivery process.
I would design those activities differently rather than give the model unrestricted discretion over the entire sequence. The harness should connect them, preserve their results, and make the current status understandable. It should also distinguish a proposed action from one that actually happened.
The sections that follow use a hypothetical onboarding assistant to explore that design. They cover the relationship to context engineering, execution, verification, recovery, and evaluation. The suggested practices are a practical framework for discussion, not a universal architecture or a claim that adding infrastructure guarantees reliable AI.
A useful test of the design is simple: if the agent stops halfway through, can the team establish what happened and continue without guessing? The answer reveals a great deal about whether the workflow is ready for real use.
How Harness and Context Engineering Fit Together
Context engineering asks what information the model needs at a particular step. Harness engineering asks how the surrounding system makes progress through the task. In practice, the two overlap: the harness often assembles context, and context includes information about tools, previous actions, and the remaining work.
For the onboarding assistant, context might include the customer’s approved scope, the implementation checklist, and the account owner’s contact details. The harness would retrieve those records, run the next permitted operation, capture its result, and decide whef5gt3 ther the workflow can move forward. This is a useful working distinction, rather than a rigid industry taxonomy.
Different changes solve different problems
If the assistant uses an outdated onboarding checklist, the information-selection process needs attention. If it creates the same workspace twice after a timeout, the action and recovery design needs attention. A stronger prompt may influence behavior in either case, but it does not replace source-version checks or duplicate-action protection.
Consider a third failure: the assistant accurately describes every required onboarding task but never creates them. The knowledge was available and the language was correct. The workflow lacked a dependable connection between producing the plan and completing the authorized operations. Evaluation must check that connection.
Choose where the model should exercise judgment
A useful starting point is to classify the work by how much judgment it requires. An ambiguous customer requirement may need model interpretation followed by review. Checking whether a required field is present can often be handled by ordinary software. Creating an approved project should use a defined operation with a result the system can inspect.
I would let the model propose a task breakdown where the request leaves room for interpretation. I would keep required fields, access checks, and permitted status transitions in application logic. This gives the model flexibility where it is useful while making important operational conditions explicit.
Treat the environment as part of the design
OpenAI’s account of harness engineering describes making repository knowledge accessible to agents and enforcing architectural constraints through automated checks. The relevant lesson for other workflows is that written guidance becomes more useful when the environment supports its application and exposes violations. The reported experience comes from a particular software project, so it should not be treated as a universal productivity benchmark. [2]
For onboarding, the equivalent might be a maintained process guide, clear tool descriptions, and an application that rejects incomplete project records. The team should be able to explain which requirements are instructions, which are enforced conditions, and which remain matters for human judgment. That distinction makes failures easier to diagnose and responsibilities easier to assign.
Designing an Onboarding Workflow That Can Finish
Suppose the authorized task is to prepare an internal onboarding workspace for a new customer. It includes creating a project, assigning approved implementation tasks, and drafting a welcome message for review. Sending the message is outside this initial scope. The first design decision is to define completion at this level of specificity.
Establish the starting conditions
Before taking action, I would require a confirmed customer identifier, an approved scope, and a named internal owner. If two accounts have similar names, the workflow should resolve that ambiguity before creating records. A well-formed plan for the wrong customer would still be a failed outcome.
The assistant could then propose a sequence based on the approved checklist. The surrounding application would validate the proposal against required steps and available permissions. An unusual requirement would remain visible as an exception instead of disappearing into a confident but unsupported assumption.
Execute and inspect one meaningful unit of work
For project creation, the harness would submit the approved fields to the project system and store the returned project identifier. It would then verify that the project exists under the intended customer account. Only after that check would it create dependent tasks against that identifier.
The task record should distinguish work that is planned, in progress, verified, or waiting for a decision. These statuses do not need elaborate terminology. They need clear meanings. “Verified” should indicate that the required evidence was obtained, while “waiting” should identify the missing information or authorization.
When task assignment succeeds, the harness would record the created task identifiers and the responsible owners. The welcome message could use those verified details. This prevents the draft from referring to a proposed schedule or assignment as though it had already been confirmed.
Make the completion report traceable
The final report should point to the created workspace, summarize the verified tasks, and identify the message awaiting review. If one assignment failed, the report should say so and explain what remains. It should not convert a partially successful sequence into an unqualified completion claim.
Anthropic’s earlier work on long-running coding agents offers a related lesson. Its harness used an initial setup phase, a structured feature list, incremental work, and progress artifacts that subsequent sessions could inspect. The authors also described the need to test actual behavior before marking features complete. Those findings concern coding agents, but they suggest useful questions for other domains. [3]
For this onboarding design, the equivalent question is whether each completed status has evidence behind it. A plan can describe the intended destination. The execution record must show which parts of the journey actually occurred.
Verification Gives the Workflow a Basis for Trust
An agent saying “done” is a report that needs an appropriate basis. In the onboarding example, a dependable completion check would inspect the external project and its tasks. Reviewing only the assistant’s final message would tell us how it described the work, not whether the work exists.
Match the check to the claim
Different claims need different evidence. To verify project creation, inspect the project identifier and customer association. To verify task assignment, inspect the task and assignee records. To assess the welcome message, compare its content with the approved scope and the verified project details. One generic quality score would hide these distinctions.
A successful tool response is useful evidence, but the application should define what that response guarantees. Some operations confirm that a request was accepted for later processing. In that case, the harness should represent the task as pending until the resulting state can be checked. Accepted, completed, and verified should not become interchangeable labels.
Use independent evaluation where it adds value
Anthropic’s later harness experiment separated planning, generation, and evaluation. Its evaluator interacted with running applications and checked explicit criteria, then returned feedback for another iteration. The article also reported substantial time and cost for the more elaborate approach. This supports testing evaluator loops for suitable tasks, not assuming that multiple agents are always the best design. [4]
For the onboarding assistant, I would start with direct application checks for the records it creates. A separate model-based review might help assess whether a customer-specific message is clear and consistent with the agreement. That review should supplement checks against authoritative records, because two model responses agreeing does not prove that the underlying facts are correct.
Protect the meaning of success
A workflow should not quietly make its acceptance criteria easier when it encounters difficulty. If the approved checklist requires a named owner for every implementation task, a missing owner is an unresolved requirement. It should not become an optional field merely because assigning the task failed.
I would keep the acceptance criteria versioned separately from the agent’s work products. Changes to those criteria would follow the organization’s normal ownership process. The agent could propose a correction to a flawed requirement, but the proposal would remain distinct from authorization to change what counts as complete.
Verification also needs proportion. Rechecking a stable draft repeatedly may add cost without improving the result. A useful harness performs checks at meaningful boundaries, repeats them when relevant state changes, and preserves enough evidence for a person to understand the outcome. The aim is a defensible completion decision, not an endless review cycle.
Recovery and Permissions Are Part of the Work
Return to the opening interruption. The project system creates the onboarding workspace, but the connection fails before the assistant receives confirmation. If the harness treats that timeout as proof that nothing happened, a retry may create a duplicate. The correct state is that the outcome is uncertain.
Resolve uncertainty before repeating an action
For this workflow, I would attach a stable operation identifier to project creation where the external service supports it. Repeating the same operation can then refer to the original request. This is commonly called idempotency: repeating an operation has the same intended effect as performing it once. The exact guarantee depends on the service and implementation.
If the service does not offer that mechanism, the harness may need to search for a matching project and reconcile the result before retrying. A name match alone may be insufficient, especially if similar projects are valid. Where the result remains ambiguous, the workflow should stop that action and request a targeted review.
Resume from durable evidence
I would store the operation identifier, customer identifier, confirmed results, and remaining steps outside the model’s temporary conversation. On resumption, the harness would load this record and check the current external state where needed. A summary saying “project creation attempted” would not provide enough information to determine whether it is safe to try again.
Recovery also has to account for human activity. Someone might reassign an onboarding task while the assistant is paused. The resumed workflow should recognize that change instead of overwriting it with an old plan. This calls for explicit rules about which state is authoritative and when a fresh read is required.
Give approvals a precise scope
An approval should identify the action and the relevant content. Approval to prepare a welcome message does not authorize sending it. Approval to send one version does not automatically apply after the customer, recipient, or substantive content changes. The application should enforce those distinctions at the moment the action is attempted.
The same principle applies to access. The assistant should receive only the tools and records appropriate to its assigned work. The harness must enforce restrictions in software rather than depend exclusively on the model remembering an instruction. Retrieved text can inform the task without gaining authority to expand its permissions.
Finally, define limits on retries, elapsed time, and resource use. When a limit is reached, preserve useful progress and identify the blocker. Persistent execution is valuable when it produces new evidence or completes work. Repeating the same failed action without a changed condition is a signal that the recovery policy needs attention.
Measure the Harness as a Working System
A harness should earn its complexity through observable results. Before expanding the onboarding assistant, I would compare it with a simpler baseline on the same tasks. The comparison should hold the model and task scope stable where practical, so differences are easier to attribute to the surrounding workflow.
Evaluate normal work and difficult transitions
The test set should include successful onboarding, missing owners, similar account names, unavailable services, and a connection failure after an action has already succeeded. Include a case where a person changes a record during an interruption. Those cases examine whether the workflow understands its operational state, not just whether it can produce a good plan.
Run important cases more than once because model behavior and external conditions can vary. Keep a separate set of cases that were not used to tune the workflow. When a production issue reveals a new failure pattern, add an appropriate test so later changes do not silently reintroduce it.
Count verified outcomes and the effort behind them
The main measure should be completion against the agreed criteria. Then examine duplicate records, incorrect account associations, unapproved actions, unresolved items hidden by the final report, and successful recovery after interruption. A workflow can be fast while performing badly on the measures that matter most.
Also record human review time and the total cost of reaching an acceptable outcome. That includes model calls, tool operations, retries, and correction work. A cheap first attempt may lead to expensive repair. Conversely, an elaborate evaluation loop may add cost to a straightforward task without providing a measurable benefit.
Use execution records to locate the cause
Useful logs should show the task, the action requested, the permission decision, the tool response, the state transition, and the verification result. They should provide enough information to reconstruct important events while avoiding unnecessary retention of sensitive customer material. Access and retention rules belong in this design as well.
When a run fails, classify the cause before changing the prompt. The model may have chosen the wrong action, the tool may have failed, the persisted state may have been incomplete, or the verification rule may have accepted the wrong evidence. Each explanation points toward a different repair.
Revisit the design when the model changes. Anthropic’s managed-agent engineering account notes that harnesses encode assumptions about model limitations and that those assumptions can become outdated. A workaround that once helped can later be unnecessary. [1] Retest after meaningful upgrades, retain controls that protect genuine business requirements, and remove complexity only when the evidence supports doing so.
Start with One Workflow and Expand on Evidence
The most useful first harness is one a team can understand. Choose a bounded workflow with observable outcomes, such as preparing the internal onboarding workspace described here. Identify the business owner, the allowed actions, the required checks, and the point where a person must make a decision.
Build the smallest version that preserves state and verifies its work. Start with one agent if that is sufficient. Add specialized evaluators or parallel workers only when a specific limitation justifies them. Every additional role creates another handoff to inspect and another possible source of inconsistency.
Introduce interruptions deliberately during testing. Pause after a successful action but before confirmation is recorded. Resume after an external record changes. Present a missing approval. These tests can reveal weaknesses that a smooth demonstration will never expose, and they provide concrete evidence for deciding what to improve next.
Roll out gradually, with people able to inspect and intervene. Define the conditions for increasing autonomy before expanding it. Track whether the system reduces total effort while maintaining the required quality, and review failures with the people who understand the business process.
Harness engineering gives teams a practical responsibility: make an AI agent’s work observable, recoverable, and checkable. A capable model supplies judgment and language, while the surrounding system determines how that capability connects to tools, permissions, persistent records, and completion criteria.
The question to ask of an impressive agent demonstration is therefore concrete: what happens when the task is interrupted, a tool returns an ambiguous result, or the first attempt is wrong? The quality of those answers should influence how much work the organization is prepared to delegate.
Where does your AI workflow most need a stronger harness: execution, verification, or recovery?
Sources and further reading
[1] Anthropic. Scaling Managed Agents Decoupling the brain from the hands. April 8, 2026.
[2] OpenAI. Harness engineering leveraging Codex in an agent first world. February 11, 2026.
[3] Anthropic. Effective harnesses for long running agents. November 26, 2025.
[4] Anthropic. Harness design for long running application development. March 24, 2026.
Explore more: Start Here · Topics · Archive · About