# You’ve just understood Agents. Now meet the Harness. > Source: > Published: 2026-08-30 12:31:01+00:00 The world of AI churns out a new concept almost every day. You may have just wrapped your head around **“Agent,”** and now suddenly **“Harness”** has become the cool kid in town. What is a “Harness” anyway? How is it different from an “Agent”? And why is everyone talking about it? Let’s take a look at it. Many agree that an **Agent** is an AI system that can independently plan, reason, and use external tools to accomplish multi-step goals on behalf of a user. The most common implementation is a loop between an LLM, a set of tools (in a broad sense), and user input. It works like this: To understand what a harness is, it helps to look at this agent loop through two distinct lenses: Seen through the logical lens, the loop is simply: input, reasoning, plan, action, result, over and over until the task is done. This is the Agent we have just met: the decision-making logic that plans and acts on behalf of the user. Nothing new here, so let’s quickly put on the other pair of glasses. If we look at the loop through the classic digital infrastructure triad of Compute, Storage, and Network, the reality is quite different: The LLM only ever receives and produces tokens, most often in text. It is the surrounding system that does all the heavy lifting: managing state, parsing instructions, executing tools, enforcing boundaries, and keeping the loop alive. **In short:** An **Agent** is the reasoning, decision-making entity. A **Harness** is the programmatic and infrastructural scaffolding around the LLM that enables an agent to operate effectively, reliably, and securely. If a harness is simply the engineering layer, why has it suddenly become the new darling of AI engineering? A few months ago, standard practice was to delegate only well-scoped tasks to specialized agents. Developers handcrafted bespoke agents for specific tasks. The rationale was simple: LLMs struggled with complex, open-ended workflows, so decomposing work into specialized, single-purpose agents was the only way to get reliable success rates. However, LLM reasoning and tool-calling capabilities have progressed dramatically. At the same time, users increasingly expect agentic systems to handle diverse, open-ended workflows, from automating enterprise operations to full-stack code generation. As the demand grows, building a brand-new, hardcoded agent for every single task does not scale. Instead, modern systems rely on a robust **Harness** to solve three foundational engineering challenges: **Quality**, **Security**, and **Generalizability**. Most of us have experienced a chatbot becoming “forgetful” as a conversation grows long. When an LLM is fed with too much text, its reasoning quality decays, a phenomenon known as **context degradation**. An agent’s context must contain everything the LLM needs to make decisions: Packed together, a single context can easily exceed 100,000 tokens, roughly the length of an entire issue of *The New Yorker*. Worse, context grows with every turn of the loop. Even though modern LLMs advertise massive context windows as long as *War and Peace*, research shows that real-world reasoning degrades long before the context length reaches those technical ceilings [see references]. So, too little context, and the LLM lacks the facts to make the right decision; too much, and it gets lost in irrelevant noise. It is the harness’s job to keep the context just right, and it does so with three primary techniques: Anyone who has played with a terminal knows how powerful and dangerous command line tools can be: one casual mistake is enough to wipe out an entire hard drive. Yet nowadays we routinely equip agents with exactly those tools, because they are essential for complex tasks such as code generation. So how do we make sure our data survives a clumsy mistake (or a hijacked decision) of the agent? The answer is sandboxing, and it is the second responsibility of the harness. A sandbox draws a safe zone around the agent, typically with three kinds of boundaries: Finally, my favorite one. I believe the biggest value of the harness is that it decouples the business logic from the engineering effort. Building an agent with LangGraph or Google’s Agent Development Kit (ADK) is ultimately a developer’s task. Yet if you have ever done it, you know that a good 80% of the work is not coding at all. It is understanding the business logic, and translating it into a suitable agent structure with the right prompts. And every new variation of the task calls for another round of this hand-crafting. The harness changes that division of labor. The engineering effort (the loop, the context management, the sandboxing, the delegation machinery) is crystallized once and for all inside the harness. The business logic, meanwhile, stays with the people who actually own it: the domain specialists, who simply write down their knowledge and instructions in plain markdown files. At run time, the main agent reads those files and designs the agentic flow on the fly: breaking the task into sub-tasks, delegating them to sub-agents, and calling the right tools, all tailored to whatever variation of the task it is handed. No developer needs to code those flows by hand anymore. You have probably already met those markdown files under their product names: “skills” and “plugins”. They are precisely the way for business people to customize a generic harness for their specific tasks, no Python required. Is the choice really *“Agent vs. Harness”*? Not strictly, since they are not competing alternatives. But if we frame the question as: **“When should we build a custom, hardcoded specialized agent graph vs. using a general harness?”**, the trade-off becomes clear. It comes down to **frequency, variability, and governance**: **High Variability → Harness:** Consider a personal AI assistant. In a single day, tasks might range from parsing expense receipts to drafting slide outlines or researching distributed systems. Building a dedicated bespoke agent for every life scenario is impossible. A generic harness provides an all-in-one environment where the agent can run bash, query APIs, and load custom skills on demand. Because the user directly benefits and oversees the agent, they accept the flexibility. **Low Variability & Strict Governance → Specialized Agent:** Consider a corporate compliance audit or HR onboarding pipeline. Every employee must undergo the exact same multi-step verification process, requiring strict legal checks and explicit sign-offs. Here, variability is low and compliance risk is high. Hardcoding a specialized agent graph (e.g., using LangGraph or ADK) ensures a fixed, auditable control flow and centralized governance that cannot be bypassed. So, what is a harness? It is the engineering scaffolding around the LLM: it keeps the context just right so the agent stays sharp, sandboxes the powerful tools so the agent stays harmless, and loads the business logic on the fly so the agent can turn its hand to almost anything. The next time someone asks you “agent or harness?”, you can smile: it is a fake question with a real answer. You don’t choose between the two; you choose where on the spectrum your task lives, and how much of the engineering you would rather inherit than rebuild. One thing does not change with that choice, though. Whether you hand-craft an agent graph in a framework or write a skill for a generic harness, the hardest part of the work stays the same: understanding the business logic deeply enough to translate it faithfully into something an agent can follow. The harness does not make that translation effort disappear; it changes who can do it, and in what language: markdown instead of Python. What that translation looks like in practice, and how to write a good skill, is a story for the next article. Bye for now. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12. [https://arxiv.org/abs/2307.03172](https://arxiv.org/abs/2307.03172) (Finding: models retrieve information far worse when relevant facts sit in the middle of a prompt rather than at the edges.) Levy, M., Jacoby, A., & Goldberg, Y. (2024). Same task, more tokens: The impact of input length on the reasoning performance of large language models. Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (ACL 2024). [https://arxiv.org/abs/2402.14848](https://arxiv.org/abs/2402.14848) (Finding: reasoning capability decays at input lengths far shorter than advertised maximums.) Hsieh, C.-P., Sun, S., Kriman, S., Acharya, S., Rekesh, D., Jia, F., Zhang, Y., & Ginsburg, B. (2024). RULER: What’s the real context size of your long-context language models? First Conference on Language Modeling (COLM 2024). [https://arxiv.org/abs/2404.06654](https://arxiv.org/abs/2404.06654) (Finding: only half of the models claiming 32K context windows performed acceptably at 32K.) Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S., & Schütze, H. (2025). NoLiMa: Long-context evaluation beyond literal matching. Proceedings of the 42nd International Conference on Machine Learning (ICML 2025). [https://arxiv.org/abs/2502.05167](https://arxiv.org/abs/2502.05167) (Finding: 11 of 13 models claiming 128K+ contexts fell below half their short-context baseline by 32K tokens; even GPT-4o dropped from 99.3% to 69.7%.) [You’ve just understood Agents. Now meet the Harness.](https://pub.towardsai.net/youve-just-understood-agents-now-meet-the-harness-289b2d706c4c) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.