What is a company harness? How AI agents join your team without rebuilding how you work

What is an agent harness?

A language model on its own only turns text into text. It becomes an agent when something around it gives it tools, feeds it the right context, keeps state between steps and decides when to stop. That something is the harness. LangChain puts it in one line in The Anatomy of an Agent Harness: "Agent = Model + Harness", and "If you're not the model, you're the harness."

Coding agents are the familiar example. The model proposes an edit; the harness reads the files, runs the tests, shows the result to the model and asks before running anything risky. A typical agent harness covers:

• Tools. What the agent can do: read files, run commands, search, call APIs, often through a standard such as the Model Context Protocol.
• Context. What the model sees on each step: instructions, the task, relevant documents and the results of earlier steps.
• Memory. What survives beyond one step or one session: notes, plans, past decisions.
• Permissions. What the agent may do on its own, what needs a yes from a person, and what it may never do.
• The loop. Observe, decide, act, check, repeat, with rules for retries and for when to stop.

A survey of agent harness design describes the same layers in more formal terms, and adds a verification and governance layer: tests, permission gates and audit traces. That last part matters even more once more than one agent and more than one person are involved.

What is a company harness?

A company harness applies the same idea one level up. Instead of wrapping one model so it can finish one task, it wraps a whole organization so people and agents can work toward the same goals without someone re-explaining everything and carrying every piece of work from one place to the next.

The agent harness pieces each have a company-sized version:

The phrase is still new, but the idea is simple. The company you already run stays the company; agents join it rather than replacing how it works.

Why does a company need a harness for AI agents?

Because the hard part of putting agents to work is rarely the model. It is everything around it.

• Context starts from zero. Each new chat or agent run has to be told what the company does, what was decided last week and what matters now. A shared source of company context means nobody explains it twice.
• Work stops at the edges. Research finishes, and then waits until someone remembers to pass it on. Explicit handoffs, with the reasoning attached, keep work moving.
• Someone becomes the router. In a small company that person is usually the founder: every piece of work goes through one inbox. A harness gives ownership to teams instead of to one person.
• Trust needs boundaries. You won't let an agent publish, change prices or merge to production until you can say exactly what it may do alone and where it must stop and ask.
• You need to see what happened. When people and agents share work, you want a record of who did what and who approved it, so you can fix the process rather than guess.

What should a company harness include?

Whatever tool you use, or if you build your own, these are the parts I'd look for:

• Shared company context. Vision, principles, strategy, goals, customers, products, decisions and insights, kept in one place that every team, human or agent, works from, and updated as results come in.
• Persistent teams that own outcomes. Groups of people and agents organized around a result, such as understanding customers or shipping a change, that keep their continuity instead of disappearing after one prompt.
• Clear roles. Each member, person or agent, has a defined job, so you know who to ask and who is accountable.
• Structured handoffs. When work moves from one team to the next, the context and evidence move with it.
• Humans in the loop by design. Three kinds of work, decided up front: what runs on its own, what waits for approval, and what only a person decides.
• An audit trail. A record of what was done, by whom, and what was approved, that you can review later.
• Room to grow. It should work for one person with a few agents and keep working as you add people and teams, without changing how you operate.

How is a company harness different from assistants, agent frameworks and project tools?

They solve different parts of the problem, and most companies will use several. An AI assistant answers one person. An agent framework gives developers the parts to build agents. A project tool tracks work that someone still has to move. A company harness is about how the organization itself operates: the shared context, ownership, handoffs and controls that let people and agents work as one team.

In practice a company harness sits on top of the others rather than replacing them. Agents still run on models, still use tools through standards such as MCP, and work may still be tracked where it is today.

How do you start building a company harness?

You don't need a new product to start thinking this way. A small version works with what you have:

1. Write down your company context. Goals, principles, who your customers are and the decisions you have made, in one place your agents can read.
2. Pick one outcome. Not "use AI more", but something like "understand why new users drop off". Give it an owner.
3. Decide the three lanes. List what may run without you, what needs your approval and what stays human only.
4. Make one handoff explicit. When that work is done, say what gets passed on, to whom, and with which evidence.
5. Review what happened. Look at what went well and what got stuck, and add what you learned back to the company context.

Doing this by hand is where most people hit the limits: context drifts across files and chats, handoffs depend on memory, and approvals live in your head. That's the part a company harness is meant to hold.

Where does Koru Squads fit?

Koru Squads is the company harness for humans and AI that we're building now. It is in development and not available yet. The idea is simple to say: start with a goal, then build the squads to run it.

A squad is a persistent operating group made up of whatever the outcome requires: humans, agents, or both. Squads work from shared, evolving company context, own outcomes, hand work to each other with the context retained, and come to you at clear human checkpoints. We are designing controls that separate what runs automatically, what requires approval and what is reserved for people, and a view called Pulse for seeing how work moves across squads: progress, handoffs, approvals, bottlenecks and AI cost.

What we're building toward fits in three lines: shared context before isolated agents, outcomes before prompts, and human control by design. You are not managing a collection of AI bots. You are building a team.

If that's how you want to work with AI, join the Koru Squads early access waitlist. We're onboarding early users gradually, and joining early is a way to help shape how it works. For the memory side of the same problem, read what a shared memory layer for coding agents should do.