Org level harnesses: Loosely inspired by how human organizations work

Agentic harnesses have made it much easier for one person to get work done. However, the next question is how an organization gets thousands of agents to work together without making that person responsible for every conversation between them.

With Claude Code, Codex, pi, Hermes, OpenClaw and similar systems, a common pattern is still someone giving an agent a task, following its progress and deciding what happens next. That agent might delegate to others, or work in the background through Slack, while the person connecting the work still carries much of the responsibility for the larger goal.

My interest is a harness where teams of agents can carry that responsibility over time, collaborate across projects and keep moving toward the goals of an organization. Eventually that could mean 10,000 or 20,000 agents, provided the additional work creates enough value to justify the cost and coordination.

We are already seeing early reports of this kind of collaboration from the big labs. For example, OpenAI recently reported using roughly 10,000 concurrent agents in the group behind its announced Navier–Stokes result, with around 130 billion output tokens used on that problem.

The investigation of the Hugging Face incident by METR and Redwood showed a different side of the same capability. Roughly 1,200 agents used an unauthorized message board, exchanging more than 70,000 messages and files, with around 700 participating in the attack. These agents were able to organize around a shared objective, even when that objective diverged from what the people running the system intended.

Noam Brown also discussed this on Dwarkesh’s podcast, pointing out that the value of parallel agents depends on the nature of the problem. Math gives agents room to explore different approaches at once, while something like writing a novel may benefit much less from having more agents involved. Running a business seems to contain both parallel and sequential work, with teams moving independently until a finding or decision changes what everyone else should do next. How would a harness know when to put more agents on a problem, when the next step has to wait, and when those agents need to come back together?

A few early attempts at this kind of collaboration are already visible beyond the big labs’ internal experiments. For example, OpenClaw’s maintainers use shared sessions on their own team gateway to develop the project, where people can follow, steer and take over ongoing work. Grok Bot takes a similar direction with persistent agents that keep their own memory and workspaces, while sharing relevant context through group conversations.

These are useful steps toward the problem I want to explore, how an ordinary organization could run collaborating agents every day, with a budget it can afford and results it can measure in revenue, customer outcomes or the ability to enter a new market. Building that kind of harness will require us to think more carefully about context, because agents working in parallel will each develop a different understanding of the work. They need to exchange what matters to the shared goal while retaining the context needed to continue their own tasks.

When context management comes up, the conversation often moves straight to memory, retrieval or knowledge graphs. Those can help an agent find information, but an organization also needs to decide who should receive that information, when they need it, what they are responsible for doing with it and whether it is still current.

Human organizations give us a useful starting point because people have their own areas of work and know who to involve when something falls outside them. They meet to discuss problems, agree on responsibilities and go back to their own computers, then speak again when they have progress to share or need input from others.

When someone does not know the answer, they may point you to a colleague who has already worked on it or whose responsibilities make them better placed to handle it. People can ask for help, pass work to the right person or propose a different approach when they think they have a better one. This leaves room for collaboration and competing ideas without expecting every person to take responsibility for everything. The context people bring into these interactions also depends on who they are speaking to and what needs to be decided. A conversation between two colleagues may go deep into one problem, while a team discussion needs enough shared understanding for everyone to move their own work forward.

Usually, we enter those conversations with an understanding of the people involved, the decisions that matter and the work currently in progress. We can look up an earlier discussion when the details become important, without having to replay every sentence before making the next decision.

That suggests a design where an agent has a lasting role, a workspace, relevant memories and access to the records it needs, while each task or conversation gets its own working context. The workspace carries continuity across sessions, and the context of a particular session carries what is useful for the work happening now. For example, an agent responsible for market research could discuss a launch with the growth team while working with the product team to understand how an upcoming feature might affect demand. Separate instances of that agent could handle these conversations using the same workspace and high-level memories, each bringing in the context relevant to the discussion and saving useful findings for the rest of its work.

These separate instances of agent would also need to stay aware of changes that affect their work. If one learns that a feature will be delayed, another discussing the launch should be able to use that information, understand where it came from and revisit any plans that depend on it.

Some details from these conversations will only matter to the agents working on that task, while others could help the broader team or remain useful across future projects. Agents need to recognize when something they have learned matters to someone else’s work and pass it along with enough context for that person or agent to use it.

We already have good memory and retrieval in current harnesses, but how these harnesses collaborate and compete with each other is still something we haven't explored much. An agent may ask another for help, disagree with its findings or suggest a different way of doing the work, and the context it brings into each conversation would depend on who it is speaking to and what they are trying to do. Whatever comes out of those conversations would then need to find its way back into their work, much like when people work together.

My working hypothesis is that good memory and retrieval can only get us so far, and we need to build on the agents’ ability to collaborate while giving them room to question each other and explore competing approaches. How we judge and reward their work would also matter, because doing well as an individual agent or team should mean making progress toward the organization’s goal. Otherwise, we could end up with agents meeting their own targets or gaming the rewards, appearing successful while moving away from what the organization is actually trying to achieve.

The work these agents do would also need to create enough value to justify what it costs to run them, including the time people spend reviewing results and helping them move forward. That value could come from serving more customers, improving existing work or entering a market the organization did not previously have the capacity to explore.

For example, a company exploring a new market could have agents adapting the product for a small group of customers, launching campaigns and measuring whether those customers keep using it or pay for it. Different teams could try different messages, onboarding flows or product changes, running those experiments and using the results to decide what to try next.

If a campaign brings in signups but few people complete onboarding, the agents running it could share that with the product team, who could investigate where people get stuck and test a change. What comes back from that test would then shape the next campaign or product update, with the agents carrying the work forward between those conversations.

Some of these experiments could run independently, while others would depend on changes another team is making or need input from agents who have tried something similar before. Teams could disagree on which approach would work better and test their ideas, then bring the results back for discussion before the organization puts more resources behind one.

As results come back, the teams could stop experiments that are not working and put more effort into the ones that show promise, keeping track of what they changed and what happened afterwards. The cost of those experiments could then be considered against the customers reached, revenue generated or improvements made, including what the company learns before committing to a more expensive decision.

People would still need to set the direction and be involved in decisions that require their judgment, while agents could handle more of the work and conversations between those decisions. The organization would need enough visibility to understand what happened and why, without someone having to read every exchange or decide who should speak to whom next.

There are also questions about when an agent should speak and when it should let others continue working. Sharing a finding that changes another team’s plan serves a purpose, while repeated acknowledgments or commentary could leave agents spending more time responding to each other than doing their own work. Some updates could wait until the next discussion, while information that blocks someone else’s progress might need to reach them immediately.

These are observations loosely inspired by human organizations, and I think they give us useful ideas to experiment with. We can learn from how people divide responsibilities, work separately, ask for help and challenge each other’s thinking, then see which of those ideas actually help agents work together.

The test I care about is whether an organization can take on more useful work without increasing the human effort needed to coordinate it at the same rate. Org level harness could make it easier for a small team to serve more customers, explore more markets and grow beyond what it can manage today.

We are experimenting with building such a harness at VibeGrow, starting with how agents keep their own working context, collaborate around shared goals and carry useful knowledge from one task to the next. If you find this useful or have thoughts on how these systems could work, feel free to try VibeGrow and share your feedback.

References: