AI Agent = LLM + Harness: The Equation Behind Every AI Product We Build

"AI agent" has stopped meaning anything specific. It gets used for a chatbot with a slightly longer system prompt, for a workflow with one conditional branch, and for something genuinely capable of taking real, multi-step action on your behalf, often in the same sentence, often by the same vendor. Before you can evaluate whether an AI agent is actually good, or actually safe, or actually worth paying for, you need a sharper definition than "it talks to you and does stuff." The one we use, and the one we build to, is short enough to fit in a sentence: AI Agent = LLM + Harness.

What the model actually is, and isn't

The LLM, the large language model, is the reasoning engine. Given some context and a request, it can draft a reply, weigh a few options, decide a tool would help answer a question it can't answer from what it already knows. That's genuinely valuable and genuinely hard to build, which is exactly why it's the part every vendor leads with in a pitch.

It's also, on its own, close to useless for real operational work, and it's worth being specific about why. A model has no memory beyond whatever's stuffed into its current context window; ask it something tomorrow and it has no idea the conversation from today ever happened, unless something outside the model itself wrote that down and fed it back in. A model has no sense of what it's allowed to do; left unchecked it will just as happily draft an email as send one, and it has no internal concept of "ask first." And a model has no way to tell you when it's behaving strangely, repeating a failed action, drifting off task, quietly making something up, unless something is watching from outside and checking.

What "harness" means, plainly

Everything in the previous paragraph, memory, permissions, self-monitoring, is the harness's job, not the model's. We're not the ones who coined the term. It comes up directly in a LangChain engineering talk we've written about before, on why most AI agents break the moment a business actually tries to rely on them:

If you're not the model, you're the harness.

LangChain, "Building Deep Agents and Deploying in Production"

That talk cites something worth sitting with: the tooling behind a well-known AI coding tool runs to roughly 500,000 lines of code, and almost none of it is the model itself. It's retry logic, rate limiting, output validation, permission boundaries, and logging detailed enough to reconstruct exactly what the agent did after the fact. None of that is glamorous. All of it is the actual difference between a demo and something you'd trust with real work.

That ratio, a comparatively small model wrapped in a large amount of scaffolding, is roughly what to expect from any AI agent built seriously. If a vendor's whole pitch is "we connected model X to your CRM," with nothing said about what happens when a step fails, what the model is and isn't allowed to touch, or how you'd find out if it went wrong, that's usually a sign the harness hasn't been built yet, and you're being sold the small, easy-to-demo part of the equation.

The right-hand-man test

Here's a way to make the distinction concrete without touching a line of code. Picture hiring a genuinely brilliant right hand man, sharp, fast, capable of handling real responsibility. Would you hand them a company credit card, a customer list, and your email login on day one, with no onboarding, no defined limits, and nobody checking in? Almost nobody would, no matter how talented the hire. You'd want them working from a playbook, with a clear sense of which decisions are theirs to make alone and which ones need a nod from you first, and someone noticing if something started going sideways.

That surrounding structure, not the raw talent, is what makes a right hand man someone you can actually depend on. An AI agent is no different. The model is the talent. The harness is the onboarding, the authority limits, and the manager checking in, all built into software instead of into a person. Skip the harness and you haven't built an agent, you've handed raw talent a set of keys and hoped for the best.

Why we built our own instead of bolting one together

We could have kept doing what we used to do: build a new, slightly-better-than-last-time integration for every new AI feature. Instead we built one reusable harness, a backend that owns the reasoning loop, the tool and skill registry, conversation history, memory, and a self-monitoring pass, that every AI product we ship runs on top of. We've written the full build up separately, including the specific reliability problems it had to solve, like making sure an approved action never accidentally runs twice, or that memory doesn't grow without bound. If you want the engineering detail, that's the piece to read. This one is about the idea underneath it.

The point of building it once, properly, is that the hard, easy-to-get-wrong parts stop being a per-project risk. A new AI product for a client becomes a new Skill, a job description and a scoped set of tools, sitting on infrastructure that's already proven to handle approval, memory, and monitoring correctly. That's a meaningfully different starting point than rebuilding the scaffolding from scratch every time and hoping this version doesn't have the same bugs the last one quietly shipped with.

What actually lives inside a harness

In our build, specifically, that's a handful of distinct systems working together, each solving one part of the reliability problem the model alone can't:

• An approval gate that decides, tool by tool, what the agent can do unsupervised versus what needs a human to say yes first, and makes sure an approved action can never accidentally execute twice
• A memory system the agent writes to and searches across sessions on its own, that compresses itself under a token budget instead of growing without bound
• A private, sandboxed database the agent can use for a task's working state, kept completely separate from anything resembling production data
• A self-monitoring pass that reads the agent's own audit trail on demand and flags patterns, like a tool failing repeatedly or a run stalling mid-turn, that suggest something's actually gone wrong

We've written each of those up individually, because each one is really its own small engineering problem with its own specific failure mode it had to be built to avoid. Together, they're what separates an agent you can leave running unattended from one you have to babysit.

Harness as software, agent as the thing you actually talk to

One more distinction is worth being explicit about, because it shapes how we think about building AI products going forward, not just this one. The harness is meant to work like software: something you configure once, plug a model and a set of tools into, and reuse, the same way you don't rewrite your accounting system every time you hire someone new. The AI agent, the thing a customer or a teammate actually talks to, sits on top of it. It's the visible right hand man. The harness is the invisible reason that right hand man is actually trustworthy instead of just impressive in a five-minute demo.

That split matters commercially, not just architecturally. It means a new AI product doesn't have to re-earn trust in its underlying reliability from zero; it inherits a reliability bar that's already been tested, tightened, and proven on whatever product came before it. The thing that changes from product to product is the job, not the foundation the job runs on.

A quick example: same equation, two different jobs

Say one Skill running on our harness handles customer enquiries: its system prompt describes the business and its tone, and its tool list is limited to drafting a reply and tagging the enquiry by urgency, nothing that sends anything or touches a record without a human approving it first. A second Skill, running on the exact same backend, handles internal scheduling: different system prompt, different tools, this time including one that can actually create a calendar event once approved. Neither Skill knows or cares how the approval gate, the memory system, or the monitoring pass underneath it works. They just inherit all three, already built, already tested.

That's the entire practical value of separating the equation into two parts. The model picks which words to say and which tool to reach for. The harness decides what's actually allowed to happen as a result, remembers what happened last time, and keeps a record honest enough to check later. Change the job, write a new Skill. The trust underneath it doesn't have to be rebuilt from scratch every time.

What this means if you're evaluating an AI vendor

If you take one thing from the equation, take this: the next time someone pitches you an AI agent, ask about the harness before you ask about the model. Which model is running underneath is genuinely the less interesting question, models converge in capability faster than most people expect, and a better model bolted onto a nonexistent harness is still an unreliable agent, just a more articulately unreliable one. What actually decides whether it's safe to depend on is what happens around the model: what it's allowed to do alone, what it remembers, and how you'd find out if it started going wrong. We've put together a fuller checklist for exactly that evaluation, since it's a question worth asking of any AI vendor, not just us.

AI Agent = LLM + Harness isn't a slogan we use for marketing. It's the design decision behind everything we build: the model changes, the task changes, the harness underneath stays the same, tested, tightened infrastructure, product after product.