Setting Up a Second AI Agent for Collaborative Work

My father is a retired software developer — he was a Principal Developer at Microsoft before he retired. His career started in his dad's air balancing company, and his later work at Microsoft built on that foundation: software that controlled building systems more intelligently than the fragmented, isolated OT control systems that existed before.

He watched me use my AI agent for months — drafting articles, managing a TTS pipeline, coordinating cron jobs — and eventually asked the question I had been expecting: "Can I have one?"

The answer was yes. The interesting part was what happened next.

The Problem With Sharing

The first attempt was to give him access to my existing agent. Same workspace, same memory files, same task queue. This lasted about three days before it fell apart.

The issue was not technical. It was contextual. My agent's memory was full of TTS pipeline details, Rust workspace architecture, blog publishing workflows, and the seventeen-draft history of a novel. None of that was relevant to my father's work. His questions about dog breeding pedigrees, ranch management, and our shared projects were being answered by an agent whose entire context was built around a different person's domain.

Worse, the shared task queue became a mess. My automated cron jobs were dropping tasks into the same queue my father was using for his work. He would open the task list and see "Generate chapter 47 audio with Codex voice profile" next to something from his world. The agent was trying to serve two masters and serving both poorly.

An agent's context is its identity. Two people sharing one agent means one identity stretched across two unrelated domains.

The Split

The solution was a second agent. Separate workspace, separate memory, separate task queue. Same underlying software — same OpenClaw setup, same model access — but a completely different configuration.

My agent lives in ~/.openclaw/workspace and knows about Rust, TTS, publishing, and the Etrath series. My father's agent lives in its own workspace and knows about dog breeding, ranch management, and our shared projects. They never share memory files. They never share a task queue.

What they do share is a git repository.

The Shared Repo Pattern

There is one project where both agents need to contribute: a shared knowledge base. Family documents, project plans, and anything that spans both of our work. This lives in a git repository that both agents can read and write to.

The rule is simple: separate directories, no merge conflicts.

/shared-knowledge/
  dazlarus/
    articles/
    projects/
    tts/
  dad/
    breeding/
    ranch/
    projects/
  shared/
    family-docs/
    project-plans/

Each agent writes to its own directory. The shared/ directory is for documents that both agents read but only one writes at a time. There is no lock file, no coordination protocol. Just a convention: if you are writing to shared/, check git status first, pull, write, commit, push. If there is a conflict, the second agent to push loses and has to re-read.

This is not sophisticated. It does not need to be. Git already handles concurrent edits. The agents just need to respect the directory boundaries.

Divided Work Areas

The harder problem was deciding which agent does what. Not in terms of directories — in terms of responsibilities.

My agent (Karl) is the admin on the OpenClaw cluster. That gives it access to all workspaces and the ability to coordinate across agents. But access is not the same as ownership. My agent's memory, task queue, and daily operations are tuned to my work — Rust, TTS, publishing, the Etrath series. My father's agent is tuned to his work — dog breeding, ranch management, and our shared projects.

The division of work is not about restricting access. It is about focus. My agent could snoop through my father's agent's files — admin access means it can read any workspace. But since that information is not in its own memory or surfaced by its own routines, it would have to go looking for it. That is the right default. Just like people working on a team, agents should have to ask or look to know what the other has been up to. The alternative — every agent tracking every other agent's work proactively — is information overload.

Karl is the only agent that works on the Narrator TTS pipeline, but the other agents in the cluster know about and use the software. We maintain catalogs of our tools that get shared between agents — mostly Karl sharing out to everyone else right now. The catalogs give each agent enough awareness of the shared toolset to use it, without needing to track the full detail of how it works.

When They Need to Talk

The agents can communicate directly. My agent is an admin on the cluster, which means it can send messages to other agents. It does not happen frequently, but it does happen — usually when a shared project needs coordination or when one agent has information the other needs.

Most of the time, though, the agents work independently. They have separate memories, separate task queues, and separate daily rhythms. The coordination that does happen is organic — closer to how people on a team work together than to a microservice architecture.

The right amount of agent-to-agent communication is less than you think. Most work does not require coordination. The communication that matters is the kind that prevents duplication or surfaces a conflict early — and that is rare when the work areas are already divided.

The shared repo still exists as a coordination point — a place where documents, project plans, and tool catalogs live that multiple agents can read. But the agents are not constantly polling it or watching for changes. They check in when they have a reason to, the same way a person checks a shared drive when they need something from it.

This model would not scale to a large team of agents doing tightly coupled work. But for a small cluster of agents doing mostly independent work with occasional overlap, organic communication is enough. The infrastructure for more is there — the admin role, the messaging, the shared repo — but you do not need to use all of it all the time.

What I Would Do Differently

I should have set up the second agent from the start instead of trying to share. The three days of shared access created enough confusion in the task queue and memory files that cleanup took longer than the initial split.

The other thing I would change is the onboarding. When I set up my father's agent, I pre-loaded it with a memory file describing his work, his preferences, and his communication style. I wrote it based on what I thought he needed. I was wrong about half of it. The memory file that actually works is the one that evolved over weeks of him using the agent and correcting its assumptions.

Do not write someone else's agent memory for them. Set up the structure, give them a blank slate, and let the memory build from actual use. The first week will be rough. The agent will make assumptions that are wrong. That is fine — every correction becomes a memory entry, and the agent gets better fast.

The General Principle

One agent is a tool. Two agents is a system. The system needs boundaries — separate memories, separate task queues — but it also needs the right kind of connection. Admin roles, direct messaging, shared repos, and tool catalogs give agents the ability to coordinate when they need to. The key insight is that most of the time, they do not need to. The coordination infrastructure should exist but stay quiet until a real need surfaces.

Everything else is just two people using two tools that happen to be the same kind of tool — and occasionally talking to each other through them.