Agent harnesses and inference: how AI turns a brief into a working product

When I work with AI on a product, I want to know how a brief becomes something a person can use. That means understanding what the model generates, what the surrounding software can execute, and how we will check the result.

Two useful terms are inference and agent harness. They describe different parts of that process. Understanding the distinction helps you write a better brief, choose a suitable working environment, and spot the point where progress has stalled.

What inference and an agent harness mean

Inference means running a trained model on the information available to it to produce an output. For a language model, that output can be text, code, a plan, or a structured request to use a tool. It uses the model's existing training; an ordinary inference call does not retrain its weights. Cloudflare explains the distinction between inference and training.

An agent harness is the software that manages a model's working session: assembling context, making model calls, routing tool requests, applying configured permissions, returning results, and maintaining progress. Microsoft's harness documentation describes this division of responsibility.

A model can propose the next action. The harness and connected tools determine whether and how that action runs. One product-building task can involve many inference calls.

Part	Its job in a product build	What to inspect
Model inference	Interpret the brief and propose copy, code, or a next action.	Does the proposal fit the audience and requirements?
Harness	Manage context, tools, state, permissions, and the work loop.	Can the session reach the right files and preserve progress?
Tools	Read files, apply changes, run checks, and display a preview.	Did the requested operation actually succeed?
Review	Compare the delivered experience with the intended outcome.	Can the intended person complete the important action?

Follow a workshop page from brief to preview

Imagine a workshop organizer needs a simple page that explains a session and collects an expression of interest. This is an illustrative build, not a claim that a particular tool or Waymaker account has every connection enabled.

The brief provides approved dates, the audience, what attendees will practice, and the destination for enquiries. It also states that the page must work on a phone and that submitting interest does not confirm a booking.

1. Understand the existing project. The agent requests the relevant pages and files. The tools return what exists. The model can then propose changes with the current site in view.
2. Resolve the missing information. If the date or enquiry destination is absent, the output should identify the gap. A plausible invented date would make the page less useful.
3. Build a bounded first version. The agent proposes copy and code, then uses permitted editing tools. The harness records the resulting tool responses and carries them into the next model call.
4. Run a preview. A build or preview tool produces evidence of what renders. A failed import or broken route becomes information for the next step.
5. Check the important interaction. Using an authorized test environment, inspect labels, keyboard navigation, error messages, and what happens after submission. Check the actual destination separately from the success message.
6. Return a clear handoff. Provide the preview, changed files, completed checks, unresolved issues, and the decision needed to release it.

This is where I find the vocabulary useful. A strong draft shows that a model generated something promising. A working, reviewed preview shows how much of the broader job has been completed.

Write the definition of finished before the first draft

For the workshop example, I would start with five acceptance criteria: the approved facts are correct; the page has a clear next step; the form explains the commitment; an authorized test reaches the intended destination; and the page remains usable at a narrow screen width.

Add one incomplete-input case. For example, omit the venue from the supplied brief and check whether the agent identifies the missing fact. Add one failed-operation case, such as an unavailable test endpoint, and check whether the handoff accurately reports the failure.

These exercises reveal more than asking the model whether it did a good job. Anthropic's guidance on agent evaluation separates the record of what an agent said and did from the resulting state of the environment. Use that distinction when reviewing your own build.

A build brief you can copy

Help me produce [specific deliverable] for [audience], so they can [important action]. First inspect [approved files and sources]. Use these confirmed facts: [facts]. Preserve [existing decisions and constraints]. You may use [tools and permitted operations]. Stop and explain when [missing inputs or exceptions]. Return [preview, files, checks, and unresolved items]. Treat these as acceptance criteria: [observable criteria]. Prepare the result for review before [release action].

A prompt expresses the intended boundary. Configure permissions and approval controls in the actual working environment where they are needed. A sentence in a brief alone does not establish an access control.

Make the next run easier to manage

Keep a small project record: the current brief, decisions, files changed, checks performed, and the next unfinished step. This is especially helpful when work crosses sessions. Anthropic's long-running agent research illustrates the value of clear progress artifacts and incremental work.

Track your preparation, review, and correction time alongside model and tool usage. A longer chain of calls can add delay and cost without improving the result. Start with one manageable workflow and add another agent only when a separate task and a clear handoff make the coordination worthwhile.

Also distinguish using an agent to build a product from building a product that runs an agent for customers. The second adds an ongoing operating responsibility: customer permissions, execution limits, failure handling, and monitoring in the product itself.

Describe. Create. Deliver. Repeat.

Describe the result someone needs. Create with the right context and tools. Deliver evidence a person can inspect. Repeat after learning what worked and what required correction.

For the broader approach, read how I build a useful product with AI agents. For a small personal trial, use the Wealth Experiment workflow run log. Begin with a result small enough to review in one sitting.

Published November 5, 2026. The workshop scenario and review brief are original teaching examples. Linked primary sources support the technical concepts; actual capabilities depend on the tools and configuration you use.