Build Your Own Agent Workspace Before You Buy One

There is a land grab happening over where your agents live.

Block shipped Buzz in July, an open-source workspace on Nostr where agents are channel members. xAI shipped Grok Bot in August, giving each agent a persistent cloud computer. Every major productivity suite has agents in the sidebar. The bet, across all of them, is that whoever owns the room the agents work in owns the relationship.

They are probably right about that, which is a good reason not to pick one yet.

The useful move, and it is cheaper than it sounds, is to build a rough version yourself on infrastructure you already run. Not because your version will be better. Because two weeks of running it tells you what you actually need from a workspace, and that knowledge is what turns a vendor evaluation from a demo comparison into a real one.

The four parts everyone is converging on

Strip the branding off the products in this space and the same four components appear.

Per-agent identity. Every agent is a distinct principal that can be named, addressed, and held responsible. Buzz does it with Nostr keypairs. Enterprise suites do it with service principals. The property that matters is that agents cannot act anonymously or borrow each other's identity, because without that, the audit trail collapses into one row saying the platform did something.

A shared, durable channel. Humans and agents post into the same place, and that place keeps a record. This is the part that looks like chat and is not really about chat. It is about the request, the work, and the human response ending up joined together in one log rather than scattered across three systems.

A protocol connection to the harness. ACP has emerged as the way a host application drives an agent, which is why Buzz can host Claude Code, Codex and Goose, and why Grok Build can be embedded in other applications. MCP does the equivalent job on the tools side.

An approval path. Some actions need a human before they happen, and the workspace is where that request appears and gets answered.

That is the whole architecture. Everything else in these products is convenience.

The two-week version

Here is roughly what I would build to learn from, using things you already pay for.

Start with the channel you already have. Slack, Teams, whatever your team lives in. Create one channel per agent-supported process, not one channel for all agents, because you want the human conversation about invoices and the agent doing invoices in the same place.

Give each agent its own identity in that system. A separate app registration or bot user per agent, not a shared one. This is tedious and it is the step that makes everything downstream possible. If your five agents post as the same bot, you have learned nothing about attribution.

Have each agent post three things into its channel: what it was asked, what it decided to do, and what it did, with a link to the full trace. Not the whole reasoning transcript, which nobody reads. A short structured summary and a link.

Put approvals in the channel as a message with two buttons. Anything irreversible, anything above a threshold, anything touching a customer. The agent waits. Someone answers. Both are in the log.

Keep a registry, which can be a table with agent name, owner, purpose, what it can read, what it can write, and a review date. This is the thing every organisation is missing and it takes an afternoon.

Connect your agents to tools through MCP rather than direct integrations, so the tool layer outlives whatever workspace you end up choosing.

That is two weeks of work for a competent engineer, most of it plumbing. It is not a product. It is an instrument for finding out what you need.

What you learn from running it

The things I have watched teams discover from doing this, which none of them predicted in advance:

Which agents nobody talks to. Some agents get corrected, questioned, and extended by the humans around them. Others post into silence for a month. The silent ones are usually either working perfectly or nobody is checking, and it is worth knowing which.

How much approval traffic you actually generate. Teams either massively overestimate this, and discover approvals are a few a day and entirely tolerable, or discover their agent is asking about everything and needs its thresholds fixed. Both are useful and neither is knowable from a design document.

Where the escalations cluster. The escalation log becomes a ranked list of exactly which data gaps and process ambiguities cost the most. That list is the best input you will ever get to a data quality project, and it is written by evidence rather than opinion.

What your team actually wants from the interface. Sometimes it is threading. Sometimes it is being able to correct an agent mid-run. Sometimes it is a digest rather than live posts. You will not guess it, and once you know it, vendor evaluation becomes a checklist rather than a beauty contest.

The part nobody ships

There is one component in that list of four that every product handles badly, and it is the one that determines whether a group of agents produces coherent work.

Shared semantics. What a customer is. What an order is. Whether an account in the CRM and an account in billing are the same thing, and what happens when they disagree.

Agents grounded in different systems will hold different definitions, and they will not experience that as a conflict. They will each be confident. The output will be internally consistent and wrong, and it will read fine, which is the worst combination available.

No workspace product solves this, because it is specific to your data. What you can do is define the entities once, in a place every agent reads from, and pass structured references between agents rather than prose. An order should move between agents as an identifier plus a schema, not as a sentence the next agent has to re-interpret.

If you build only one thing from this article, build that. It is more valuable than the channel, the buttons, and the registry combined, and it transfers to whatever workspace you eventually buy.

When to stop building and buy

I am not arguing for building your own workspace permanently. Chat products are a deep well of small features and you will not out-build Slack or Buzz on threading and search, nor should you try.

Buy when you know what you need and a product has it. Specifically, when you can say: we need per-agent identity that maps to our IdP, we need approvals with a defined SLA, we need retention that satisfies our legal team, and we need to host our own agents rather than only the vendor's.

That last one is the question I would weight highest. A workspace that only hosts its own vendor's agents is a lock-in decision dressed as a productivity tool. A workspace that speaks ACP, so you can bring the harness you already use, is a component you can replace.

On the current field: Buzz is the most interesting architecturally and the least ready, being pre-1.0 with a relay you have to operate. The big suites are the safest and the most closed. Grok Bot is a different category, an agent runtime rather than a workspace, and its own documentation says separate Bots are not a security boundary, which shapes what you can responsibly put through it.

None of those is a clear buy today, which is exactly why the two-week version is a good use of the time.

The one thing to get right regardless

Whatever you build or buy, the agents themselves should connect through standards rather than product SDKs. ACP between the workspace and the harness. MCP between the harness and your systems. Your evaluation sets and tool definitions in your own repository.

Do that, and the workspace question stops being an architectural commitment and becomes a preference you can revisit. Skip it, and you will be having a migration conversation in eighteen months about a decision you made in a fortnight.

The room your agents work in is going to matter. It just does not have to be decided this quarter.

We build agent workspaces this way, standards at the boundaries and a registry from day one, whether the front end ends up being your existing chat tool or something new. If you are weighing this up, we are happy to talk it through.