Operating harnesses are early, overhyped, and probably directionally right

I think operating harnesses are going to be useful for the same reason most good tools are useful: they have a specific purpose. We just have not fully honed in on what that purpose is yet.

Right now, a lot of the conversation around agents feels slightly ahead of reality. People talk about AI companies, autonomous teams, and agents collaborating in shared workspaces as if something radically new has already arrived. Underneath the surface, a lot of it is still fairly simple machinery: cron jobs, heartbeats, prompts, large context windows, role definitions, and shared project folders. That does not make it useless. It just makes it less magical than the story sometimes sounds.

The distinction I keep coming back to is between a coding harness and an operating harness.

A coding harness is basically one agent wrapped around a project. Claude Code is the clean example: it has a prompt, it has a repo, it can inspect files, make edits, run commands, and help move a software project forward. That model makes sense because the environment is relatively constrained. There is code, there are tests, there is a working directory, and there are fairly concrete outputs.

An operating harness is broader. It has multiple agents, multiple contexts, different specialties, and a shared space that includes both code and documents. It is trying to behave less like a single coding assistant and more like a lightweight operating layer for a project or business. Tools like OpenClaw and Paperclip point in this direction. They are not just asking, "Can an agent edit this file?" They are asking, "Can a system keep track of all the moving pieces required to build and run something?"

That is the part I find interesting.

I have tried the major LLM CLI tools, OpenClaw, and Paperclip. My read is that Paperclip could work well for SaaS because launching a SaaS is a huge horizontal problem. It is not just one hard technical problem where you need raw compute or rare talent. It is a wide coordination problem. You have product planning, bugs, SEO, customer communication, security, reminders, insights, infrastructure, bookkeeping, and a long list of things that are easy to forget or defer.

That is where an operating harness starts to make sense. Not as an autonomous company that goes out, makes money, and comes back with the results, but as a hybrid tool that helps a founder keep more of the surface area alive.

My own use case is a SaaS idea around personal finance budgeting for the Canadian market. That market has a specific shape because of the bank situation and the difficulty of working with personal finance data. I am mostly a developer. I have not run a company of my own before. So the appeal of an operating harness is not that it replaces me. The appeal is that it can help with business planning, remind me to check things externally when required, keep context around decisions, brainstorm, do creative work, and reduce the number of dropped balls.

That matters because a small company is not just code. Even a simple bookkeeping CRUD app with some specialty value still has a lot around it. You need the prototype, but you also need positioning, customer discovery, follow-up, basic security thinking, content, support, and a plan. A coding harness helps with the prototype. An operating harness is trying to help with the rest.

At the same time, I think the harnesses are ahead of the models.

We are imagining all kinds of ways to automate companies, but the models themselves are still not always strong enough for the environments we are putting them in. In my experience, open source models are barely able to handle a coding harness, let alone a company harness. Gemma is a good model, but trying to run it inside OpenCode on a local consumer Nvidia GPU shows the gap pretty quickly. It can be impressive and still not be reliable enough for a bigger, messier operating loop.

That gap is important. The harness can create roles, schedule work, run heartbeats, and load bigger contexts, but the model still has to reason well inside that structure. If the model cannot reliably navigate a repo, follow long instructions, make good judgment calls, or recover from mistakes, then adding more agents and more process does not automatically solve the problem. Sometimes it just creates a more elaborate failure mode.

This is where I think some of the online lore gets carried away. The claim is often framed as if the agents are forming little companies, collaborating with each other, and producing value independently. I am skeptical of that framing. I do not think agents are inventing private languages to coordinate with each other in some deep way. Collaboration can be useful, but mostly when there is real diversity in the perspectives being brought to the problem. Different model APIs looking at the same problem space can be useful. Two identical Claude agents reviewing each other's work can feel redundant when a follow-up prompt might have accomplished the same thing.

The bigger issue is that people overclaim autonomy and underestimate how much human input contributed to whatever success they saw. A human picked the goal. A human shaped the context. A human decided what mattered. A human judged the output. A human often stepped in when the tool got stuck. If the final story erases all of that, it makes the system sound more autonomous than it really was.

But I also think skeptics can miss the point.

The fact that these systems are not fully autonomous does not mean they are useless. Most LLM tools so far have been hybrid tools. They move the boundary of what a person can do, but they do not remove the person. Operating harnesses are likely to be the same. They will not suddenly become a magic business operator. They will become more useful as the trust dial moves forward.

And I do think it is a dial, not a dam break.

Over time, we will hand these systems more responsibility. Not all at once. Not because one model release suddenly makes every company autonomous. More likely, we will trust them first with reminders, drafts, plans, low-risk research, SEO tasks, bug triage, and internal reviews. Then maybe customer support drafts, security checklists, product analytics, and recurring business rituals. The amount of control we give them will move gradually as the models, interfaces, permissions, and observability improve.

One thing that matters a lot to me is manual control. When I need to take over, the system should make that easy. In Paperclip, if I want more manual control, it can feel awkward because I have to open tickets for everything. That makes sense from the tool's point of view, but it can also make the harness feel like bureaucracy. If operating harnesses are going to work, they need to let humans step in naturally. The human should not have to fight the process just to steer the work.

That might end up being one of the most important product questions in this category: how do you combine persistent agent work with easy human takeover?

The near-term market, in my mind, is founders, managers, solo entrepreneurs, and very small teams. Maybe a team of three sharing an instance. These are people who have enough going on that memory, follow-up, and coordination are real problems, but not enough people to cover every function. For them, an operating harness does not need to be a fake employee. It can be a cheaper, always-available layer of help.

It can remember what you said last week. It can keep a planning thread alive. It can notice that you never followed up on a bug. It can draft a customer email. It can suggest content ideas. It can ask whether the security checklist has been touched. It can help you think through the business side when your background is mostly technical. None of that requires pretending it is a CEO.

That is why I think operating harnesses are early and overhyped, but directionally important.

The current versions are not the final form. The language around them is too grand. The models are still catching up. A lot of the orchestration is less sophisticated than it sounds. But the underlying need is real. Modern work, especially building a small software business, has too many parallel threads for one person to hold cleanly in their head. If LLMs are useful anywhere, they should be useful there.

The question is not whether an operating harness can run a company by itself.

The better question is whether it can help a human run one better.