What an AI Agent Harness Contains, and Why the Model Layer Stays Swappable

TL;DR

• An agent harness is the loop around the model: it assembles context, calls the model, runs tools, keeps the session and enforces what the agent may touch.
• OpenAI's own documentation splits the stack three ways, and the split is the useful part: harness, environment, application server. The harness can run without an environment; the Bash tools, workspace files and executor MCPs cannot.
• Own the harness and the model becomes a component you can replace. Let a provider own both and the model becomes the product, with its retirement dates attached.
• Provider timelines explain the urgency better than any argument: OpenAI gives at least six months' notice for generally available models, three months for specialised variants, and as little as two weeks for preview models.
• The work is unglamorous and small: one internal interface for model calls, the model id in configuration, evaluations in the repository, and a swap drill on twenty real tasks.

What a harness is made of

OpenAI's architecture page names the pieces plainly. The harness is the loop: it runs the model and the tools and maintains the session. The environment is where commands run, and it can be an OpenAI-hosted sandbox, a self-hosted executor, or nothing at all. The application server is your code, which submits tasks, receives events and handles function tools.

That separation is worth reading twice, because most teams collapse it into one word: agent. An agent that answers questions from a knowledge base needs a session and tools and little else. An agent that edits files needs an environment, and once it has one, someone owns provisioning, reconnection, shutdown and the files that survive between runs. OpenAI states the boundary directly: with no environment, the built-in Bash and apply-patch tools, the workspace files and the executor MCPs are simply unavailable.

The loop is the asset, and the model is a component

Here is the distinction that decides how much a team controls. The model produces tokens; the harness decides what those tokens can do. Permissions, tool allow-lists, human approval gates, retries, context compaction, logging, cost accounting and the record of what the agent actually did all live in the loop. None of them live inside the model.

Take a concrete case. Imagine a ten-person logistics company in Casablanca whose back-office agent reconciles supplier invoices against purchase orders and flags the mismatches for a human. The valuable engineering is not the model call. It is the retrieval of the right PO, the rule that the agent may read the accounting system and may write only a draft note, the retry when the ERP times out, and the log that proves which invoice, which document and which model produced each flag. That work survives a model change. A prompt does not, and neither does an unrecorded session.

Two ways to own the harness

OpenAI's own guide lays out three runtimes and the trade is explicit. With the Agents API, OpenAI runs the managed Codex harness, session state is saved by the provider, and integration effort is low. With the Agents SDK, the runner executes the loop inside your application, state lives in your storage or in the provider's conversation objects, and effort is medium. With the Responses API, you call models directly and manage history yourself, at the highest integration cost and the most control.

The managed path buys real things: automatic context compaction, multi-agent orchestration, programmatic tool calling and support for MCP servers arrive without you building them. Compaction alone is a project most teams underestimate. The trade is symmetric, though, and it is the one clients ask about: the provider sees and stores the session, the loop's behaviour changes when the provider changes it, and swapping the managed runtime for your own later means rebuilding the parts you outsourced.

Netics' position, after wiring agents into client systems, is that the choice is less important than making it deliberately. A managed harness for a support assistant on a twelve-month horizon is a good trade. A managed harness under a workflow that touches payroll or invoicing is a conversation about data residency, audit and exit, and it should be written down before the first tool is connected rather than after the pilot succeeds.

The model layer ages on a published schedule

Model churn is the argument for a seam, and both major providers publish the calendar. OpenAI's deprecation page sets notice periods: at least six months for generally available models, at least three months for specialised variants such as the Codex line, and, in its own words, preview models "may be retired with much shorter notice, such as 2 weeks." The same page states that preview models are not recommended for business-critical production workloads unless you can migrate on short notice. On 2026-10-01 OpenAI announced deprecations including GPT-5.3-Codex, GPT-5.1 and GPT-5.4-Nano, scheduled for removal from the API on 2027-04-01 with six months' notice, and text-to-speech models removed on 2027-01-06.

Anthropic runs a four-state lifecycle — active, legacy, deprecated, retired — and is blunt about the last one: requests to retired models fail. Its table carries dates such as claude-opus-4-1-20250805, deprecated on 2026-06-05 with retirement on 2026-08-05, and on 2026-09-30 it notified developers using Claude Sonnet 4.5 that the model is being retired on the Claude API. The same page contains the detail that matters most for architecture: partner-operated platforms such as Amazon Bedrock and Google Cloud set their own retirement schedules, so the same model can be alive on one route and gone on another.

Read that alongside the two-week window for preview models and the picture is clear. The application can be a five-year asset; the model id inside it is a dependency with an expiry date that somebody else sets. A team that treats that as an architectural fact, rather than as bad news to handle when the email arrives, spends its maintenance budget in planned swaps instead of emergency migrations.

Tools and the MCP seam

Tool calling is where portability is usually lost. Bind an agent to a vendor's proprietary tool format and the model swap stops being a routing change and becomes a rewrite of every integration.

The Model Context Protocol exists to remove that particular coupling. It is an open standard for connecting AI applications to external systems — data sources, tools and workflows — and its documentation uses the analogy of a USB-C port for AI applications. Its specification version on the page we read is 2026-07-28, and the client list includes Claude, ChatGPT, Visual Studio Code and Cursor, which is the practical argument: a tool server you publish once is reachable from several runtimes. OpenAI's harness, for its part, "can call remote MCP tools directly," while function tools route back through your code, which is exactly where your business rules belong.

What a six-person team can do this quarter

The seam costs less to build than the migration costs to avoid. Put every model call behind one internal interface, so the provider is chosen in one module. Keep the model id in configuration and log it next to every output, so a quality regression is traceable to a swap rather than debated. Keep twenty to thirty real tasks with known answers in the repository, and run them against the current model and the candidate before anything changes in production. Then run one swap on purpose, in staging, and write down what broke.

That is the shape of the platform Netics builds when a client wants agents on infrastructure they control: the loop, the tool servers, the evaluation set and the permissions live in the client's estate, and the model is a component with a configuration value. The page on the self-hosted AI agent platform describes that offer, and our earlier analysis of the OpenAI Agents API covers what changes when a provider takes the loop over.

The uncomfortable part is worth stating. Owning the harness means owning compaction, retries, session storage and the migration calendar, and none of that is where the demo excitement lives. It is, however, the difference between an agent that runs for a year and an agent that has to be rebuilt when the model behind it is retired.

Sources

Source: Agents API Architecture — developers.openai.com, retrieved 2026-10-04 (harness, environment and application server as separate pieces; harness runs the model and tool loop and maintains the session; environment types including OpenAI-hosted, self-hosted and none; remote MCP tools called by the harness; Bash and apply-patch tools, workspace files and executor MCPs unavailable without an environment). Source: Agents — developers.openai.com, retrieved 2026-10-04 (three runtimes compared by owner of the loop, state between tasks, tool execution and execution environment; managed harness features including automatic context compaction, multi-agent orchestration, programmatic tool calling and MCP server support). Source: API deprecations — developers.openai.com, retrieved 2026-10-04 (six-month minimum notice for generally available models, three months for specialised variants, preview models retired with notice as short as two weeks; 2026-10-01 deprecation of GPT-5.3-Codex, GPT-5.1 and GPT-5.4-Nano with removal on 2027-04-01). Source: Model deprecations — docs.claude.com, retrieved 2026-10-04 (active, legacy, deprecated and retired states; requests to retired models fail; claude-opus-4-1-20250805 deprecated 2026-06-05 and retired 2026-08-05; Claude Sonnet 4.5 retirement notified 2026-09-30; partner platforms such as Amazon Bedrock and Google Cloud keeping separate retirement schedules). Source: What is the Model Context Protocol — modelcontextprotocol.io, specification version 2026-07-28, retrieved 2026-10-04 (open standard for connecting AI applications to external systems, the USB-C analogy, client support across Claude, ChatGPT, Visual Studio Code and Cursor). Internal linkage: The OpenAI Agents API Makes the Harness a Managed Product. More on Netics' work at neticslabs.com.

Source: OpenAI developer documentation — developers.openai.com, retrieved 2026-10-04; Model Context Protocol documentation — modelcontextprotocol.io, specification version 2026-07-28; Claude model deprecations — docs.claude.com, retrieved 2026-10-04. Figures: official OpenAI and MCP documentation diagrams, retrieved 2026-10-04.