--- title: ChatGPT's harness is excellent. That is why it does not work in your business. description: ChatGPT's harness is extensively tested and built for everyone at once. That is exactly why an agent that works in chat gets stuck in your processes. lang: en canonical: https://www.en-twine.ai/en/blog/why-chatgpt-harness-falls-short-in-your-business/ updated: 2026-10-02T17:19:37.000Z --- Most criticism of AI agents in businesses concerns the model. Too expensive, too slow, not reliable enough, or simply the wrong model. Those are important considerations, but the problem often lies not only with the model, but also with the entire setup around it. It lies in the layer around it. That layer is called [the harness](/en/what-is/harness/): the software that gives the model tools, supplies context, and keeps track of what has happened. ChatGPT and Claude provide that layer. It is good work. It is just built for everyone at once. ## What is good about it The harnesses from well-known providers such as Claude and ChatGPT have been tested by millions of people in daily use. They handle long conversations sensibly, recover from errors, have a controlled set of tools, and are more carefully thought out in many respects than a first custom build. For individual knowledge work, research, writing, and analysis, they are often simply the best choice, and rebuilding them yourself is unwise. ## Why that may be insufficient in your business A general-purpose harness is tuned to the average of all users. Your work is not. It does not know your systems. It does not know which of your three price lists is current, where the latest terms of delivery are, or which CRM fields are required before a deal can move. It does not know your rules. Which brand rules apply, which marketing channels are and are not used, which client has a different contract, and what must never go out without someone reviewing it. And it does not know your approval points. In a chat, you are the approval: you read the answer and decide. In a process that runs overnight, that moment is something someone must design, and that is exactly the part a general environment cannot fill in for you. A marketing agent needs different tools from a financial agent. Different sources, different knowledge, different boundaries. That is not in the model. You build it into the harness and provide it as context. ## Three routes The right setup depends on what the agent needs to do: 1. **A standard product for general knowledge work.** Suitable for research, writing, analysis, and other tasks where an employee assesses the result themselves. 2. **A standard product with custom tools for preparatory business processes.** Suitable when the agent needs to consult your systems or prepare a proposal, but an employee performs the final action. 3. **A custom process layer for specific rules, state, approval, and audit.** Necessary when the agent works independently and your own process rules, checks, and records are decisive. ## The middle ground: a standard harness with custom tools Between "all standard" and "all custom" sits an option that is the right starting point for many businesses: keep the provider's harness and connect your own tools to it. The major chat environments and agent SDKs now support this through an open standard, the [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/server/tools). You describe a tool, for example "find a customer in our CRM by their KVK (Dutch Chamber of Commerce) number" or "retrieve the current price list for this customer group". The agent can then use it alongside web search and reading files. The model stays the same and conversation handling remains the provider's, but the agent can now access your systems. That is often enough for preparatory work: looking things up, summarising, preparing a draft. It costs a fraction of a custom build and quickly teaches you which tools you actually need and how they should be described. That last part is less trivial than it sounds. Much of an agent's behaviour lies in its tool descriptions, not the model, and every model will misuse a vaguely described tool. In [Writing effective tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents), Anthropic describes what a good description contains: what the tool is intended for, when not to use it, what each argument means, and how to read the response. The limits of this middle ground are determined by impact, uncertainty, sensitivity, and reversibility. As consequences grow or errors become harder to reverse, you need approval points and execution records that fit your process precisely. A standard harness can support logging, state, and approval, but does not automatically fill in your business rules and checkpoints. At that point, a custom process layer becomes the logical next step. ![Twijn fastens a tool belt holding a wrench, a small key, and a roll of paper around a standard suit of armour](/images/blog/harness-algemeen-versus-eigen-gereedschap.png) ## What you gain by retaining control of the layer When you retain control of that layer, the model and the agent are two separate components. That layer does not have to run entirely on your own infrastructure: a supplier can manage parts, as long as you retain control and portability over tools, rules, state, data, and evaluations. This brings three concrete advantages. **You choose the model per task.** Reasoning work can go to a large model, typing work to a small or open source model. We applied that pattern ourselves when building our [Minimal Coding Harness](/en/blog/minimal-coding-harness-open-source/): the expensive model thinks and specifies, the cheap model executes. **You can switch.** If a provider becomes more expensive, a condition changes, or a model disappears, you do not have to rebuild the entire agent. You do need to retest behaviour, tools, and quality when switching, and adjust them where necessary. **You choose where components run.** That could be a European provider or a model on your own machine. For organisations that must demonstrate where processing and storage take place, logging, configuration, and any subcontractors also count. ## Where the boundary lies A custom build is not always the answer, and it is tempting to leave that out of an article like this. If your work fits the standard form of an existing product, use that product. A custom harness pays off through your own sources, rules, and approval points, not through the idea that building it yourself looks more serious. If the process itself is not yet in order, start there, because an agent does not automatically tidy up poorly defined work. And building it yourself does not mean training a model yourself. You buy the model. What you build is the layer around it: your tools and their boundaries, your knowledge sources, and the records of what has been executed. ## How to assess this Do not just ask a supplier whether you can switch model providers in two years. Ask which components move with you: tools, prompts, knowledge sources, process state, evaluations, and logs. Also ask what needs to be rebuilt, reconnected, or retested. That answer shows how much control and portability you are actually buying. If you want to know which of your processes suits a custom agent, use the [AI Readiness Scan](/en/ai-readiness-scan/). If you want to see the technology first, read the guide to [building your own AI agent](/en/guides/build-ai-agent/) or [contact us](/en/contact/).