What Is a Harness?

6 hours ago (earendil.com)

I’ve been working on a harness for accounting agents at my job recently and it’s been a pretty interesting experience.

We originally started with building a CLI tool so our LLMs could more easily interact with our platform. I cannot recommend enough the value of having an internal CLI. It’s both fun to build and extremely useful for agents.

We paired this with skills initially, but found that the way folks built skills was often too prescriptive and limited to the authors own specific function in the company. A 2k line long skill suffers from the same gaps as we do, if an agent is just following a laundry list it’s less likely to reason about the request it’s doing.

So we instead asked ourselves: what if we just _let_ the agent reason about the work to be done and only provided the tools + guardrails to gather context and perform accounting work?

Turns out frontier models are GOOD at what they do, they outperformed our highly prescriptive skills and were able to work across a larger set of tasks even without instruction on how to do those tasks.

It’s a breath of fresh air from the decade of CRUD I’ve worked on, harness engineering is very neat.

  • This is the same "tension" I keep seeing in my day job. Some people approach LLMs like they're writing code. They give a long list of detailed instructions for specific scenarios. When I use LLMs I leave things as open as possible. I just give them the information they need and my ask.

    As you say frontier models are very good at figuring things out. Being too prescriptive is counterproductive, it over-constrains the model, it fills the context with conflicting instructions, it reduces the ability of the agent to respond to novel situations (and really in real life most situations are going to be novel). If you want to follow a process or a checklist you probably shouldn't use an LLM, or you should use it for some sub-tasks in the checklist/process but something more deterministic to work through the list.

    • That works for well trod paths, e.g “fix ci” works exceedingly well. “why app slow” obviously doesn’t work because the task is underspecified. But in order to properly specify you either need an experienced engineer who knows how to narrow the problem domain, or you have to provide some template instructions/output formats (e.g, skills) which will invariably never fit the problem perfectly

      4 replies →

  • I've been building a harness (on top of Pi for that matter) and have had similar experiences. Pi itself helps a lot with it being extensible by design but it's definitely been a challenge to make certain things work in an expected way.

    The native app I'm building on top, which I hope people who are less technical (or not technical at all) will use, is even more interesting because it's not just supposed to shell out to the CLI for everything and needs its own state.

  • Can you post a generic version of code for this somewhere (e.g. codeberg or whatever)?

    I find your description intriguing but I'd like to see it to make sure I understand it.

  • So you still have CLIs but they have I presume an help command that describes the capabilities right.

    Could you give an example of an accounting guardrail you created?

    • I’ve also found that Claude and friends are eerily good at using classic Unix CLI tools so I build mine in the same style, not unlike the `gh` CLI from GitHub, though with an agent-first design shape.

      Usually I’m returning TSV as a default format and I add a `help-all` subcommand to list every available command at once when needed. Another thing that helps is adding just-in-time context-sensitive hints, such as: user has just run a list query with at least one result. Add a one-liner to the response explaining the command shape for getting the detail view of the first response.

      In terms of skill files, I like to have my CLI generate them dynamically at runtime by walking their own current command tree and then feeding that through a text template.

      Examples from a public project: https://github.com/radiusmethod/gitlab-kiosk/blob/main/skill...

    • Yeah the CLI can provide schema for commands via the usual ‘—help’ syntax, so agents are able to discover + explore commands on their own.

      As for an example: if our agent wants to book a journal entry to cash accounts for a client, it MUST provide receipt and directly link the transaction from the clients bank feed, if it attempts to do so without the requisite information we deny the tool call and ask the agent to escalate back to the client for proof of receipt.

      Often times this results in the agent not doing the work and instead sending a message back to the client asking for proof of the transaction.

      For humans on our platform there may be valid situations where we’d want to allow this, but for our agent this is a hard guardrail thus why it’s not just standard validation for any JE posting on our platform.

      2 replies →

I feel like harnesses will become massively important for enterprise AI agents.

Right now every tool is shipping some kind of AI agent, but I can’t help but feel that AI agents in large companies will eventually be some kind of internal app with internal MCPs, CLIs, APIs etc.

There might be different harnesses for different use cases that different people have different levels of access to.

This would make sense for the platform/infrastructure engineers who can build a modular harness that a person or team can get access to.

You could have agents team members use locally that have memory enabled for personalization and then agents that anyone can use to ask questions about company context, which wouldn’t personalize things.

Does anyone have a suggestion for a harness that is good at handoff?

When I say handoff, I mean:

  * handoff from a terminal CLI to webui (on a phone)? 
  * handoff from one team member, to another?
  * handoff from one communication modality, like writing a prompt in a TUI, to email? 
  * handoff from one model to another, or one provider (openrouter)( to another (llama.cpp)

Does such a thing exist?

I used to think that a PR would be a good place to centralize all this. Who cares what IDE, or developer, or location. But, now I feel like an agent harness might contain that better.

Why do I want handoff? I keep losing context of where my harness is running. Sometimes I am inside an isolated VM. Sometimes I'm on my laptop, sometimes I'm on my home machine with the big GPU for local models. If I could spin up a harness that could identify itself inside my tailscale network, then I could probably have a single web UI which allows me to keep all that context straight.

I'm tempted to experiment with Pi to configure such a thing. But, perhaps there are patterns out there already with a harness I have not considered.

  • The session is "just" the raw chat history in it's entirety (human and agent) and can be disseminated as such. This is what enables swapping between models, you simply send the whole context.

    Not sure how others do it, but opencode stores sessions in a sqlite db and you can extract them and share them as needed.

    https://opencode.ai/docs/cli/#export

    Pro-tip: Building your own extremely minimal harness takes about 15m and is both fun and enlightening. Agents are unsurprisingly quite good at it, but ask them to walk you through it step by step.

  • Sounds like you want an orchestration.

    Let's assume handoff happens when one "agent" finishes its work on one task, i.e. "submit a PR".

    At that point you want to exit the agent/clear context etc (any context the next actor needs should be in the handoff artifact).

    And the orchestrator calls the next agent with the artifact.

    Claude can do this with subagents. If you want to get more serious, I'd look at "durable workflows" and check out what the pi people have to say: https://earendil-works.github.io/absurd/ https://earendil-works.github.io/absurd/patterns/pi-ai-agent...

    you should also look at dbos https://www.dbos.dev/

    And then do a search for these terms on HN and get some idea of their shortcomings vs a 'real' orchestration tool like Airflow or Dagster

  • I do this all the time in my workflow. Use any harness. Ask it to create a markdown file with the information required for the handoff. Use that downstream. Keep a "repo" of those markdown files. Are you trying to orchestrate or manage this sort of process?

Harnesses are the next frontier. If LLMs are electricity, harnesses are the “electronics.” Right now, it’s like an AC vs DC between Claude and ChatGPT, but once that settles, the harnesses will be the actual value providers.

And Pi is the best harness because of the amazing extension system. You can build extensions that turn Pi into a stock trader, software factory, anything. I tried switching to another harness but none have extension functionality as good as Pi.

Even if there is a new harness or agent project, I tell Pi to dig into the codebase and then make me an extension that brings that functionality into Pi. I did it with Prime Intellect’s and Deepseek’s harnesses and those are built on Pi.

  • > If LLMs are electricity, harnesses are the “electronics.” (...) the harnesses will be the actual value providers.

    Don't get ahead of yourself. Harnesses are not exactly rocket science and will be a commodity.

    The real value providers here are the hardware, then the LLM as a distant second, and at a much larger distance the harness.

    • Either part can be branded a "commodity" or a "sovereign privilege" depending on supply and demand.

      Solar goes all the way up => power is commodity.

      Some hyperscaler goes bankrupt => hardware is commodity.

      Models get real good => output is a commodity, no profitable problems to solve anymore.

      Open source models get good => models are commodity.

    • I was saying more the custom skills and extensions that make the harness not a commodity. Yes people will use Claude Code, Codex, or Pi but their customizations will make their harness unique and more powerful.

  • > Harnesses are the next frontier. If LLMs are electricity, harnesses are the “electronics.”

    I really though this comment was a satire ...

  • > ...once that settles, the harnesses will be the actual value providers.

    The words "once that settles" are doing historic levels of work here.

    No human on earth has a clear idea whether model technology will settle tomorrow or 100 years from now.

    There's every reason to expect architectural breakthroughs will keep being discovered and causing nuclear blasts of forward progress.

  • I've never used Pi but I don't see why you can't use stock codex or claude code for the same purpose, what makes Pi special? I've built plenty of custom harnesses on top of claude code and codex using custom skills or simple markdown instructions and subagents. Never had any issues or limitations with that approach.

    I do agree that harnesses are going to extend AI capabilities a lot in the next year, but after reading Pi's page I don't see anything that makes it particularly special in terms of functionality, other than being more provider-agnostic.

    • For one you can ask Pi to create a TUI extension, so along with the agent interface you can add whatever custom TUI you need, such as portfolio stock tickers, alerts, whatever you want.

      Many of my harnesses eventually turn into customized UIs around the chat interface.

    • Codex and Claude historically had more bloat in their system prompt and tools. Pi is minimal by design so more adaptable. But to be fair Claude Code is moving in the Pi direction with a small system prompt.

    • Author here. I think our website could be much clearer - but Pi is fundamentally easier to mold than other harnesses. It’s not magic but it strikes the balance well of letting you shape it extensively without letting you break it.

      1 reply →

  • If LLMs are oxen, harnesses are... the harnesses

    • Yeah. This is pretty clearly the origin of the usage.

      The harness facilitates the work animal doing work for you.

      Not climbing harnesses to keep you safe.

  • This is a plug, but relevant. I recently added a 'build native tools on the fly' functionality to Dirac (https://github.com/dirac-run/dirac) that works like:

    1. You can use the '/new-tool' and tell what kind of tool you want (including whether it should be task-scoped, workspace-scoped, or global), the model builds it, the harness runs validation and other tests until the tool is ready

    2. The model decides that in such and such task, it would be helpful to have a tool like this, it can build a task-scoped tool.

    In either scenario, the tool catalog is rebuilt, and the new tool is instantly available in the next turn.

    • This type of modification of the harness on the fly to fit the need is the future. The only thing left after that is the mobile front. I think static app store type software as we know it is a thing of the past. You'll only ever need one self modifying app.

  • I don't think so.

    What I can see is a world where we end up with a Chromium-shaped harness, a fully featured standard implementation everyone builds against, because doing every single thing yourself would be crazy.

    The antithesis to Pi, if you will.

    • I disagree with this. Unlike training models (which requires huge compute), harness development is available to anyone with an editor and ideas. That means that solo devs and small startups can still make meaningful progress.

      Also, having only a "standard implementation" makes no sense for a harness. A standard implementation would need to try to be as good as possible at all things. But you'd often want a specialised harness designed for exactly your use case.

  • I want to move from Claude Desktop to Pi, but I found it a little unfriendly. Any tips to set it up?

    • Pi doesn’t have a UI like Claude Desktop. It also doesn’t work with the Claude subscription, only API key and pricing.

      So if you do want to use it, use the Codex sub. Once you install it, run Pi and /login and you’ll get login with ChatGPT. From there, Pi can tweak it’s settings if you ask. Check out their extensions (or ask Pi) and that will take you most of the way there.

      What hiccups were you having?

      1 reply →

    • I haven’t tried it myself yet but I’m under the impression that Hermes Agent might be what you’re looking for?

  • Please tell me this is satire, it reads like straight from the depths of LinkedIn where a while loop is seen as the second coming…

  • Both Claude and codex are unappealing, crap, generic agents that you have 0 control over.

    Don't understand what people see in them.

  • The harness is just another codebase for the model to write and optimize. The value is still very much in the model.

  • i think its the opposite. claude code apparently removed hundreds of lines of system prompt because its not relavent anymore with newer models.

    also i think its hard to build general harnesses if they were trained on specific harness architecture.

    • Yes but Pi has had a minimal system prompt since inception. Skills and Pi extensions let you make a hyper specific harness for specific use cases. For general conversation, harnesses are overkill most times.

      There’s evidence of harnesses making a smaller, weaker model perform better than SOTA and some benchmarks ban harnesses because it becomes too easy.

      1 reply →

Author here. It’s ironic because this post was clearly geared towards non-hackers. But now that we’re here.. the other analogy I considered presenting was:

harness = chassis, model = engine, fuel = tokens, agent = car

I’m curious what y’all might think and whether that analogy carries more explanatory power

  • I'm a climber so I'm biased but I really liked your climbing harness example because of the configuration you're able to easily make to the harness.

    Saying the harness is like a car's chassis doesn't work as well for me because the chassis isn't as configurable as a climbing harness for as little work.

    Getting deeper into the climbing analogy you can even swap out the harnesses themselves for wildly different climbs. Like using Claude Code with a bunch of agents for medical software (climbing K2 where that extra padding comes in super handy) and pi.dev with a local model for a respectable web project (sport route where you'll be back in a few hours and it's safe to be a little more exposed).

    I'm glad your article made HN, and thank you for pi!

  • The first analogy that comes to mind, growing out of "harness", is more like harness = harness, model = horse (rather than harness as in climbing harness).

    I guess you could say that tokens = hay, and agent = horse and cart, from there? Not sure how useful the hay part is but you could observe from the second that there are many different things you could harness a horse to (also a plough, or a coach, or just a saddle) based on your goal.

The ai hype word for 2026 after agent in 2025 for any LLM powered application.

Well kind of, I wouldn't be surprised to see that some things marketed as agents are actually good old deterministic software.

  • It's really funny (and a bit obnoxious) to watch the vocabulary from the outside. In 2023 everybody learned the word moat, then it's been agent(ic), from last year there's more talking about harnesses than at a bungee jumping convention. The mot du jour is frontier.

    It truly proves like there's a handful of thought leaders on Twitter that everybody follows blindly and start to copy down to the lexicon and parrot everywhere else.

  • My guess is that everything "reliable" in LLM/agentic-coding comes down to either calls to reliable/deterministic tools or providing well-defined success criteria (such as loads of unit tests) for the LLM to throw its stuff at in "agentic loops" until something sticks.

Clear, relevant, and easy to understand. Thank you for writing this up, I’ll be sharing this link with all my non-tech friends!

  • I second that. Not using agents myself but trying to get an idea on how this stuff works, so I always wondered what an "harness" even is, since anyone seems to assume that this is common knowledge. Now it is really clear to me!

i also like the backpack analogy

the harness is what you take with you on a trip/task

whatever you take with you is not free (system prompt, tools, skills …)

some models are really good even if you bring almost no skills, tools or system prompt

the harness is the complement to the model

the better the model the more minimal the harness can be

harnesses like pi [0] and smol [1]are on the more minimal end of things

[0] https://github.com/earendil-works/pi

[1] https://github.com/smol-env/smol

  • Not a bad analogy because the bigger your backpack the slower you walk. With models a big context and tool set degrades performance. So you want the smallest harness/backpack that can do the job.

From these comments, it seems like people still don't understand what harnesses are... The point is you shouldn't build a harness, you should use a harness and change its system prompt, the tools it has, MCPs it has, give it skills, etc, to make it work for your usecase. You aren't "building a harness on top of pi" if all you're doing is the above. You're just using the harness to connect different things to the LLM.

To me, Before agentic programming a harness was like a mini framework in the app. Like for testing mostly. You’d set up the harness and configure it for your test and it would take care of boilerplate setup / optional reporting / benchmarks ect. Still works for both - but yea need a new word I guess

  • From a naming terms yes, the closest equivalent of the past is the term "framework". Having written a Go service framework that's how I perceived it and as I started to work on agents, anything related to that became an "agent harness". I guess naming and terms change with different paradigms.

I have a similar mental model to the climbing harness. I think of LLMs as horses and harnesses as the saddle, reins, etc that you put on your horse. You might configure your harness for an individual rider or you might hook together several horses to pull a carriage.

I think a harness is kind of anything around the intelligence that allows the intelligence to be applied towards something, some sort of task. A great (if off-color) example I remember hearing was how Steven Hawking was brilliant, but really needed that computer setup to be able to apply his intelligence. It really stands out to me as such a clear visual example of what a harness actually is.

Anyway I've been building my own harness on top of pi- www.freepi.ai (it's based on Pi, but now I have an OpenAI compatible endpoint so I'm thinking of it more like free-api :-) ). Basically ad+training supported so I can offer completely free inference. It's really important to me that we don't have harnesses and intelligence trapped in a "have and have not" world. If we don't all have access to intelligence we will end up in a dark place.

Thats again where the visual of Steven Hawking and the wheelchair really stand out in my mind. It's not enough to have the raw intelligence, we need a really good wheelchair too.

Great example of writing about AI that maintains a human voice. Starting off the post with a picture of the author + nod to real-world experience (climbing) is a reasonably strong “this is not slop” signal.

I thought this was the next evolution of the smartphone. One so smart that it does all the thinking for you. You don't even have to be conscious, you just do whatever it tells you too. Oh wait, that's what they do already.