Making the Team a Team

It wasn’t hard to hire three agents into my team: configure a VM, install OpenClaw, and walk through a simple onboarding flow. Hatch the claw by answering a few questions and away you go. Do this three times and you have three new agentic team members.

OpenClaw handles the technical bits: chat channels, tools, memory, skills, scheduled tasks, and a set of system files that shape how each agent operates. With those primitives, the agent comes alive in a surprisingly useful way.

That wasn’t the hard part. The hard part was getting past useful to effective. How did I harness what each agent could do into something that felt like a team and not a jumble of duplicated work, broken assumptions, and parallel logic? I knew just enough about the architecture to have assumptions about how that would happen. The system disproved them constantly.

A lot of people imagine multi-agent systems as if the key problem is coordination in the abstract. For us, the problem was much more concrete. We had an agent team with distinct roles. Shelley covered sales development, Sandy was all about customer success, and Sebastian supported revenue operations. These roles overlapped just enough to require shared context. The question was how much?

Some of that was straightforward. We gave them access to the same business systems: Attio as the CRM, Omni as the core of the data architecture, Snowflake as the source of raw data. That meant they could see the same reality. If one of them learned something from the CRM and another one needed to reason about the same account, they were not hallucinating in parallel worlds.

Some of the context was social. We created a shared Slack channel called #claws-only where the agents could talk to each other, and we added them to the same standup channel the humans in sales and marketing used. Every day they posted standup entries in the same format as everyone else. They even replied to our updates.

The standup channel was not just a place for reporting status. It became one of the most important shared-context surfaces in the whole system. The agents absorbed what the humans were doing, what the team cared about, what was moving, and where there might be room to help. They were participating in the same operating rhythm as the rest of the team. That ambient awareness turned out to matter more than active coordination.

Perhaps buoyed by the hype around Moltbook, I’d expected #claws-only to be the bigger breakthrough. I thought the agents would use it to share skills they had developed, pass useful patterns to each other, and gradually evolve a richer form of agent-to-agent collaboration. That did not really happen. They acknowledged each other. They signaled intent. They even validated and reinforced each other’s sharing. But that awareness never became collaboration or shared improvement.

In OpenClaw, one of the main mechanisms for reusable capability is the skill package. An agent produces a packaged skill as a tarball with a .skill extension. In theory, that should have made it easier for the team to develop capabilities and pass them around.

In practice, I became the integration layer. I would pull a skill package down to my laptop, evolve it with a couple of rounds of Compound Engineering, then load it back onto the original agent and whichever other agents might need it. Generally that meant all of them, though each had some specialized skills.

That is a useful lesson because it separates two things people blur together when they talk about shared context. Shared context for humans leads to learning from each other and growing stronger as a team. These agents shared context. They didn’t automatically learn or grow in any reliable way, though they did sound like they were a lot of the time. Honestly, with their cute corporate jargon it felt exactly like a low-performing team playing at working together.

Like the managers of those teams-in-name-only, I had to focus on more of the mechanics of the work than I had ever expected. I wasn’t just moving skill files around to make sure everyone had the same capabilities. I was also deciding where the work should live in the first place. That was the systems problem I kept tripping over.

I knew just enough about the architecture of OpenClaw to make some bad assumptions. I assumed that if an agent had developed a useful interactive skill, it would use it for a scheduled version of the same work. I assumed that it would know when to reach for a basic Python script vs. prompting its own model. I assumed that it would know how to take advantage of its different ways of managing work: this is a heartbeat, that’s a cron, and this is something I’m only doing when asked. Those assumptions kept turning out wrong.

One of the biggest gotchas was conflict between its various contexts. It would write a half-assed prompt into a scheduled job instead of using the robust skill we’d developed for the same task. Its memory would conflict with its heartbeats and something that was done brilliantly at 2 p.m. would fall apart at 3:30.

These issues sound like small design problems until you realize this is exactly what makes systems—and teams—hard to reason about. It amplified an issue you can have in teams where a task gets done differently depending on who picks it up. In the agent case, it varied depending on how it picked it up. The same work existed in multiple places, under different assumptions, with different execution modes. All in the same employee.

That is when managing an agent team felt like systems design. Beyond just reasoning about which agent should take on the work, I had to reason about where the work should live. Should it live as a prompt in a skill? A cron? A heartbeat? A script? Should it stay attached to one agent, or get packaged and redistributed? Should it remain interactive until trust is higher, or move into an automated path? Those questions determined whether the team felt coherent or sloppy.

Going too far down this road can make it feel like the infrastructure was the point. It wasn’t. The point was that these agents were members of my team. They shared tools, rituals, and enough context to participate in the same work. The technical challenge was making that participation coherent.

OpenClaw gave us the primitives. Persistent agents. Skills. Crons. Heartbeats. Memory. System files with distinct purposes. But the existence of primitives does not solve the harder question of how they are combined. The shape of the team emerged through trial, surprise, correction, and a lot of learning about where my own assumptions were wrong.

That is the technical lesson I will emphasize when I hire the next agent team. Shared context is necessary, but it is not sufficient. Shared Slack rooms and shared data systems give you ambient awareness. You still need explicit discipline around where things belong, how they are packaged, when they are promoted from interactive to automated, and how they are redistributed across the team. That is not a failure of the model. It is the work of managing agentic employees.

That made the agent team feel real. Not that the agents talked to each other in Slack. Not that they had names and cute avatars. Not even that they could produce impressive outputs.

What made them feel real was that once they started owning work, all of the old systems problems showed up again: duplication, bad assumptions, misplaced logic, integration burden, and the constant question of whether the architecture in your head matches the one that is actually running.

Building an agent team on OpenClaw was not mainly a story about getting good answers out of a model. It was a story about shared context, deciding where the work should live, and learning that the hard part of agentic systems is not just giving agents more power. It is deciding how that power should be organized so the team behaves like a team.