A model supplies reasoning and language capabilities. A harness connects those capabilities to business context, tools, permissions and feedback. Success depends on how the complete system performs a real job.
A customer asks, “Can you change my delivery address before the order ships?” A model can understand the request and write a helpful reply. Completing the job also requires identifying the customer, checking shipment status, applying the change policy, updating the order and confirming the result. Each step depends on systems and rules outside the model.
That is the practical meaning of Agent = Model + Harness. It is a useful design shorthand, rather than a mathematical law or a guarantee of autonomy. The business value comes from connecting intelligence to an accountable process.
What the model does—and what the harness adds
The model interprets a request, reasons about the available information and proposes a response or next action. The harness is the surrounding software that supplies instructions and context, exposes tools, runs the interaction loop and manages execution. An agent can use the result of one action to decide what to do next. A fixed workflow instead follows a predefined sequence; many useful business systems combine both approaches. Anthropic’s guide to effective agents explains this distinction and recommends starting with the simplest suitable approach.
Receive a goal → gather context → propose an action → check permissions → execute → inspect the result → continue, finish or escalate.
The model does not become the order database, payment ledger or source of company policy. Those remain external systems. A well-designed harness lets the agent consult them and limits the actions it can perform.
Six parts of a dependable harness
For a business implementation, we recommend making these six responsibilities explicit:
- Instructions and context: define the task, the current policy and what counts as completion. Retrieve relevant records with their sources and freshness.
- Tools: provide specific operations such as finding an order or preparing a quote. Validate inputs and outputs; avoid granting unrestricted access to an entire business system.
- State: record what has happened, what is pending and who approved it. Durable task state is different from asking a model to remember an earlier conversation.
- Permissions: enforce user identity, access limits and approval requirements in application code. A sentence in a prompt is not an authorization control.
- Recovery: set timeouts, retry limits and a route to a person. Give write operations unique request identifiers so a retry cannot silently create a second order or charge.
- Evaluation: capture actions, corrections and outcomes. Test the whole workflow, including failures, rather than judging only the final reply.
Continuity matters for longer tasks. Anthropic’s engineering work on long-running harnesses describes progress records and structured handoffs between sessions. Our business takeaway is to make progress inspectable and recoverable instead of relying on one uninterrupted conversation.
Real-world applications: where the equation becomes useful
A documented example is customer service. In its Intercom case study, Anthropic describes Fin combining Claude with company knowledge and business-specific behavior to answer support requests. This is a vendor-reported deployment, not a promise of the same results for every organization.
The following are illustrative business designs, not claims about Leadows customers. Each pairs a model capability with the operational support needed to make it useful.
Retail and distribution: order changes
The model interprets a customer’s request. The harness verifies identity, retrieves the order and checks whether fulfilment has started. It permits eligible address changes and routes exceptions to staff. Measure correctly completed requests, repeat contacts and unauthorized changes—not just response speed.
Sales: enquiry to quotation
The model extracts requirements from an email and identifies missing details. The harness retrieves approved products, prices and stock, prepares a draft quote and asks a salesperson to approve discounts or delivery commitments. Measure enquiry-to-approved-quote time and correction rate.
Finance operations: invoice exceptions
The model compares invoice details and explains discrepancies. The harness retrieves purchase orders and receipt records, applies deterministic matching rules and opens an exception case with evidence. Payment authorization stays with the designated approver. Measure review time, false matches and duplicate-processing incidents.
Field service: preparing the technician
The model summarizes a fault report and suggests questions to ask. The harness retrieves service history, approved manuals and parts availability, then prepares a work order. A dispatcher confirms assignments and a qualified technician decides what repair is appropriate. Measure preparation time and completeness of job information.
Software teams: implementing a bounded change
The model proposes and edits code. The harness supplies repository context, an isolated execution environment, tests and a review process. A passing test suite is evidence for review, not blanket permission to deploy. Measure accepted changes, review effort and defects after release.
A complete example: changing a delivery address
- 1. Establish the facts
Authenticate the requester. Retrieve the current order and shipment state. If the account or order cannot be verified, stop the change and request assistance.
- 2. Apply the business rule
The model can interpret the address, but application logic checks eligibility. If shipment has begun or the destination changes delivery charges, route the request for review.
- 3. Commit and confirm
Recheck shipment status immediately before writing. Submit the update with a unique request identifier. Confirm success only after the order system acknowledges the change.
- 4. Handle uncertainty
If a timeout leaves the outcome unclear, look up the existing request before retrying. Give the customer a pending status instead of claiming completion.
The harness handles the difficult boundary between a convincing answer and a completed business transaction.
How a business can get started
A small company can apply this approach using its existing help desk, shared documents and order system. It does not need to build a foundation model. An enterprise can begin with one department and reuse identity, integration and monitoring services. In both cases, start where the process is understood and the outcome is measurable.
- Choose one recurring job. Prefer meaningful volume, available data and manageable consequences of errors. If a form and a few rules solve it well, use that simpler solution.
- Record the baseline. Measure completion time, staff effort, error rate and customer outcome before adding the agent.
- Write the operating contract. Specify allowed data, tools, approval boundaries, completion criteria and an owner for failures.
- Test in shadow mode. Run on representative cases without making live changes. Include missing records, conflicting requests, tool outages and malicious instructions embedded in incoming text.
- Launch with limited authority. Begin with drafts or reviewed actions. Expand permissions only after measured performance supports the change.
- Review and improve. Track recurring failures, update the harness, and rerun the evaluation set whenever the model, tools or policies change.
Define success in business terms
Use a balanced scorecard: correct completion rate, time to completion, cost per completed task, escalation rate and incidents. An escalation can be the correct outcome; suppressing it to improve an automation metric can make the service worse.
At 1,000 tasks per month, four net minutes saved per task equals about 67 hours. At an assumed loaded labor cost of $20 per hour, that represents roughly $1,333 of capacity. Subtract model usage, platform costs, maintenance and amortized implementation cost. If review and rework were excluded from the four-minute estimate, subtract those too. Capacity becomes cash savings only when staffing costs actually fall; otherwise measure how the freed time is used.
No architecture guarantees success for every business. A well-chosen task, reliable integrations, clear accountability and sustained measurement give the model a useful job and the organization a way to judge whether it is doing that job well.
Start with one process you can explain, one outcome you can measure and one owner who can act on the results.
