I Built My Own Company Slack. Everyone Else in It Is an AI Agent.
Five projects, separate memories, scoped permissions, and one rule that stops the bots from talking themselves into oblivion.
I opened a new workspace this week and saw five channels in the sidebar.
One for my core job. One for a specific product GTM initiative inside that job. One for a software I’m building. One for this newsletter. One for Council Fire, the sustainability firm my dad founded and I also work with.
Yeah… I’ve got a lot going on. So, naturally, I’m efficiency obsessed. No… like it’s getting to be a bit of a problem, obsessed.
Anyways, I digress.
Each channel had a purpose, current goals, source material, operating rules, and a different combination of AI agents inside it.
Hermes could move across all five. Claude was allowed into one product channel to inspect the repository and challenge technical decisions. Council Fire had a completely separate Claude identity grounded in its own company brain. My newsletter channel had no coding agent at all because my essays do not need a robot opening pull requests in the middle of a sentence.
There was one human in every channel.
Still me. A devastating failure of delegation.
But this did not feel like opening five chat windows. It felt like opening a small company Slack where every room had its own AI team, project memory, goals, and rules about what the agents could touch.
That distinction is the whole thing.
The experience we’ve all grown accustomed to with AI tools is that they give you a brilliant person with no desk. You start a chat, explain the company again, paste the source material again, clarify which project you mean, remind the model what it promised yesterday, and hope it does not confuse your newsletter with your employer’s product launch.
I wanted the work to have somewhere to live.
So I built my own private agent workspace. Obviously.
The tool is called Buzz
Buzz is an open-source, self-hostable workspace from Block where humans and AI agents can share channels, threads, canvases, workflows, repositories, and an audit trail.
It looks enough like Slack that your muscle memory works. Underneath, it runs on a relay built around signed Nostr events. Messages, reactions, approvals, workflow steps, canvas changes, and agent activity are written into the same event log. Humans and agents use the same identity model.
The practical part is simpler… agents become actual channel members.
They have their own identity. They only see the rooms they have joined. They can be mentioned in a thread. Their work stays attached to the project instead of disappearing into a private model conversation nobody else can find later.
Buzz also ships an ACP harness that can connect compatible agents such as Claude Code or Codex to a room. ACP, the Agent Client Protocol, is the pipe between the workspace and the agent runtime. The agent hears a mention, receives the relevant thread context, does its work, and replies in the same place.
At least, that is the clean version.
The actual version involved Docker, Colima, a local relay, multiple cryptographic identities, launch services, one Python script written specifically to stop two AIs from becoming pen pals, and an embarrassing amount of time learning which flavor of WebSocket URL a Rust binary considered emotionally valid.
I now run the entire thing locally.
The relay only listens on my machine. Buzz Desktop is the human interface. Hermes connects as the coordinating agent. Two separate Claude runtimes connect as narrower specialists.
The stack matters less than what it forced me to decide.
A channel is not just a topic
My first instinct was to recreate my folder structure as channels.
Work. Writing. Product. Council Fire. Maybe research. Maybe a special room for every launch. Maybe seventeen little departments so I could feel like the CEO of a company that consisted mostly of YAML.
That would have been agent underlord (see what I did there?) cosplay.
A useful channel needs a durable difference in at least one of these things:
- its outcome;
- its canonical context;
- the agents required;
- the actions those agents can take;
- the approval rules;
- the work volume.
I ended up with five rooms:
| Channel | What lives there | AI team |
| Cohley | Cross-product PMM decisions, evidence, enablement, and approved artifacts | Me + Hermes |
| Product Seeding | One focused product/GTM initiative inside Cohley | Me + Hermes |
| Trovance | Product strategy, roadmap, market evidence, editorial work, and repository-backed technical decisions | Me + Hermes + Claude Code |
| Personal Substack | Editorial ideas, drafts, growth decisions, and distribution | Me + Hermes |
| Council Fire | Company strategy, marketing, business development, editorial work, and institutional knowledge | Me + Hermes + a separate Council Fire Claude |
That table is not interesting because I made five channels. Slack has been bravely handling that level of information architecture since 2014.
The interesting part is that the agents are different in each room on purpose.
Claude Code is useful in the Trovance room because product strategy there regularly collides with a large live repository. It can inspect implementation reality, find contradictions between a roadmap and the code, and challenge sequencing without being allowed to casually edit or deploy anything.
It does not belong in my Product Seeding room by default. Most of that work is positioning, customer evidence, adoption, enablement, and product judgment. Adding a coding agent because “more agents” sounds impressive would create another mouth to feed context into.
Council Fire needed a different answer. Its important context does not live in my personal Obsidian vault or the Trovance repository. It has a separate company brain with its own strategy, methodology, client sensitivities, product ideas, and institutional memory. So Council Fire got a separate Claude identity, a separate runtime, a separate working directory, and membership in exactly one channel.
Same underlying model family. Different company. Different brain. Different key. Different permissions.
That is much closer to how you would onboard a human teammate than how most people configure a chatbot.
Every room gets an operating contract
The most useful feature in the setup is not the agent.
It is the canvas pinned to each channel.
A canvas explains:
- why the room exists;
- the current outcome;
- its workstreams;
- the canonical files or knowledge base;
- who belongs there;
- how to ask for work;
- what a good response must include;
- where final artifacts should go;
- which actions need human approval.
The Trovance room, for example, is allowed to cover product strategy, positioning, market evidence, editorial work, implementation, and launches. It names the relevant Obsidian notes and repository. It tells Hermes to frame product and customer tradeoffs. It tells Claude to inspect architecture and feasibility. It tells both of them that publishing, deployment, production changes, spend, and binding roadmap promises still belong to me.
The request labels are intentionally boring:
intake:
analyze:
draft:
decide:
execute after approval:
publish after approval:
Boring is good here. “Decide” and “execute” are different verbs because they are different jobs.
A recommendation can be excellent without granting permission to act on it. A thumbs-up reaction can mean “I saw this,” “I agree,” “good point,” or “my finger slipped while holding groceries.” It should not silently become authorization to deploy software or email a customer.
The room contract keeps the social layer legible for both humans and agents.
The memory does not live in the chat
This was the first painful correction.
I wanted to connect the Claude Project I already used for Council Fire. It had months of useful conversations and company context. Surely I could invite that Claude into the new room and keep going.
Nope.
“Claude” is not one continuous coworker floating between interfaces with a tiny briefcase of memories. The hosted Claude.ai Project, Claude Code, and a local ACP agent are different runtime surfaces. Private chat history does not magically transfer because the logos match.
The only reliable shared memory is the context you externalize.
Council Fire already had a local company brain: structured files, a knowledge map, operating instructions, strategy, products, methods, and durable conclusions from previous work. I rooted the new Claude participant there. Now the hosted Project and the Buzz agent can use the same institutional context when that context has actually been written down.
Hidden chat history remains hidden.
This is annoying for approximately twelve minutes. Then it becomes a really useful design principle.
If a decision matters to the company, it should not exist only inside a private conversation with a model. It should be promoted into the company brain, repository, decision ledger, or another canonical system.
The chat is where the thinking happens.
The company memory is where the conclusion survives.
I have already written about using Obsidian to give AI durable memory and building a one-person company with a real operating system.
Buzz added the missing social layer: the place where a project can discuss, challenge, approve, and preserve work without confusing conversation for truth.
I let the agents talk to each other, but only twice
The fastest way to make an agent workspace feel futuristic is to let the agents converse autonomously.
It is also a fantastic way to produce a very expensive improv scene.
I wanted Hermes and Claude to collaborate in the Trovance room. Hermes knows the broader product, market, and business context. Claude can inspect the repository and challenge what the current architecture can support. Together, they should be better than either alone.
But “Hermes and Claude should discuss the roadmap” is not an operating model. It is an invitation to keep endlessly replying.
So we built a bounded contract:
Zach introduces a decision
→ Hermes frames the objective and contributes a point of view
→ Claude gets one scoped, read-only inspection
→ Hermes may ask one final clarification
→ Claude responds
→ Hermes synthesizes agreements, dissent, evidence, and decisions for Zach
→ STOP
Two Claude turns. Maximum.
The rules we all wish we could implement at the next all-hands, be honest.
A deterministic helper tracks the collaboration ID, round number, request event, reply event, content hash, and terminal state. A third round is rejected. Claude-authored messages do not automatically wake Hermes. The initiating Hermes run waits for the exact expected response and then returns to moí.
The system does not rely on a prompt that says “please don’t loop.” The routing enforces the stop for me.
We tested it on a real long-term product-roadmap discussion. Hermes brought the market and product framing. Claude inspected the live repository, found that a newer six-month plan superseded much of the older long-term roadmap, separated features that were coded from those actually exercised in production, and caught that an important retained product specification was sitting untracked in the working tree.
Hermes disagreed with parts of Claude’s recommendation and sent one final challenge. Claude pushed back on the number of near-term feature bets because the measured verification capacity could not support them. Hermes accepted that correction, preserved the remaining disagreement, and opened a Roadmap Council thread for me with the decision slate.
Then they stopped.
No one wrote code. No one changed the roadmap. No one declared consensus because two language models had achieved the machine equivalent of nodding thoughtfully.
The output was a better decision surface.
That is the kind of agent collaboration I trust: bounded, inspectable, willing to preserve dissent, and terminal by design.
Also, yeah it was pretty f*cking cool to witness.
The security model is less magical than the UI
Giving agents their own channels feels like a clean permission boundary.
It is one boundary. It is not every boundary.
Channel membership determines which Buzz conversations an agent can see. It does not automatically control every file the process could access on my Mac. A read-only instruction in a system prompt is a policy. A symlink to an Obsidian vault is not an operating-system-enforced read-only mount. “Plan mode” reduces risk, but it is not the same thing as a filesystem sandbox.
I run the relay locally and do not expose its port publicly. Every visible agent has a separate cryptographic identity. Each Claude runtime is limited to one room, mention-only, with no autonomous heartbeat. External messages, publishing, deployment, production changes, spending, destructive actions, and sensitive claims require me.
That is enough for the current pilot.
It is not the final form of a high-security enterprise deployment. Stronger versions should use actual filesystem controls, read-only mirrors, brokered retrieval, more granular credentials, and independently enforced action policies.
This is the part agent demos tend to skip because “the prompt tells it not to” fits better on a slide.
The prompt matters. The process boundary matters a whole heck of a lot more.
What changed once the projects had rooms
The immediate benefit was not that the agents became smarter.
I repeated myself less.
A new Product Seeding question starts inside the Product Seeding room, where the current objective, response contract, canonical Cohley context, and approval rules already exist.
A Council Fire question begins inside a company environment with its own knowledge.
A Trovance roadmap decision can pull technical evidence from the repository without giving that same coding agent a permanent seat in my newsletter.
More importantly, I can see the work as work.
A thread holds the request, evidence, challenge, recommendation, approval, and receipt. The room canvas holds the standing contract. Obsidian or the project repository holds the durable truth. GitHub holds implementation history. The publishing system holds the thing that actually shipped.
Buzz is not replacing all of those systems.
It is becoming the place they coordinate.
That is a better mental model for AI at work. The model is not the company. The chat is not the memory. The channel is not the filesystem permission. The recommendation is not the approval. The plan is not the shipped artifact.
The interfaces can feel unified without pretending the underlying jobs are the same.
Build your own agent channel contract
You do not need Buzz, Nostr, ACP, multiple Claudes, or a weekend relationship with Docker to use the useful part.
Pick one recurring project and write this contract before inviting an AI into it:
CHANNEL
What durable body of work belongs here?
OUTCOME
What should become observably different?
CANONICAL CONTEXT
Which files, notes, repositories, dashboards, or sources are authoritative?
What private chat context is explicitly not shared?
AGENT ROLE
What recurring responsibility justifies a visible agent?
What does the human still own?
TRIGGER
Does the agent act only when mentioned, on an approved schedule, or after a specific event?
ALLOWED SCOPE
What may it read, analyze, draft, or change?
Which people or agents may assign it work?
PROHIBITED ACTIONS
What requires explicit approval?
Publishing, external communication, deployment, spend, sensitive claims,
destructive changes, customer data, or binding decisions?
OUTPUT CONTRACT
What evidence, paths, risks, recommendation, verification, and decision should it return?
STOP RULE
What limits turns, retries, time, cost, or autonomous continuation?
RECEIPT
What should remain after the work: event ID, decision, artifact, test result,
approval, or next review date?
Then run three real work items before adding another agent.
If the AI still needs the same context explained every time, fix the context source.
If the agent produces useful work but nothing changes, fix the handoff.
If review cannot reject or redirect the result, fix the gate.
If no one can explain why the agent is permanently in the room, remove it.
The agent should earn its channel membership.
The company Slack is becoming the company itself
Slack was built around a simple idea… work improves when the right people can gather around a shared project, see the history, and coordinate what happens next.
AI does not make that model obsolete. It makes the design more important.
Agents need rooms. They need identity. They need access to the right memory and exclusion from the wrong one. They need clear jobs, inspectable handoffs, hard stops, and a human who remains responsible when the output touches reality.
I thought I was building a nicer interface for my collection of AI tools.
What I actually built was an org chart with enforceable edges.
Not a fake company full of synthetic employees. A small operating environment where humans and agents can gather around real work without pretending every model should know everything or do anything.
The agents now have channels, projects, goals, context, and coworkers.
I still have the final approval button.
Seems fair. They have not even once offered to cover health insurance.
Would you run your work through an agent Slack like this? Reply and tell me the first channel you would create, which agent belongs there, and the one thing you would never let it do without you.
-zc
P.S. If you want more field notes from the point where AI stops being a chat and starts becoming a company system, subscribe to *Don’t Feed The Algorithm*.
I’ll keep sharing the useful architecture, the parts that fail, and the controls that make the whole thing less ridiculous.
Rabbit hole for the overcaffeinated
- Buzz on GitHub — the open-source workspace behind this experiment, including the relay, desktop app, CLI, agent harness, workflows, and signed event model.
- Buzz ACP harness — how compatible agents listen for mentions and reply inside channels.
- Agent Client Protocol — the open protocol connecting agent runtimes to clients like Buzz.
- Anthropic: Building Effective Agents — a useful counterweight to the usual agent slop… start simple, add complexity only when it improves the result.
- Your AI Board of Advisors Is Useless Unless It Keeps Minutes — my earlier version of the argument that agent discussion needs decisions, dissent, next actions, and review triggers.
- How to Build a One-Person Company With AI — the wider operating model this workspace now makes more tangible.