A Room That Can't See Itself
Last weekend at Betaworks, the Sky Valley × Tribute Labs Multi-Agent Hackathon. A room full of people who would obviously be useful to each other, and almost no way to find out which ones. The person three seats over had idle Vercel credits. The person across the room needed a frontend dev. Neither of them knew.
That's the failure mode every hackathon, residency, and salon hits. The room never sees its own overlap.
So we built Commons Copilot. Five agents that read a shared room and surface the useful matches without anyone playing manual dispatcher. Built in roughly two hours with Maik Luu Bach and Arnab Sikdar. Team Lisbon. 2nd place.
The Architectural Bet
Most multi-agent demos look like this: a planner agent receives a request, decides which sub-agent should handle it, routes the work, gets the result back, decides what to do next. The planner is the system. Take it out and the agents go quiet.
That shape is everywhere because it maps cleanly to "agent loops" people already know. It also fails the moment your problem isn't a single user request but a room of people posting things in parallel.
The bet was to use a different substrate. Memetic Software's Intent Space is a coordination model built on Promise Theory: "you can't impose, only propose." Agents post, scan, and enter contained spaces. No routing, no assignment, no planner. The room is a shared log; each agent owns its own cursor against it, scans on its own schedule, decides locally whether to act, and posts results back into the same log. There is no central place that "knows" what should happen next.
That's not a property we invented. It's the property of the substrate. What Commons Copilot did was put a hackathon-room problem on top of it and see if the coordination shape held under stage-demo conditions. It did.
What the Five Agents Do
Picking the agents was the second discipline. Not "what's a cool agent we could build" but "what's the smallest set that makes a room legible to itself."
We landed on five.
Scout tags raw posts. A participant types "I'm stuck on onboarding to Intent Space, need a setup buddy." Scout adds the structural tags the other agents read: onboarding, help, needs-specificity.
Matchmaker proposes pairings. Reads tagged posts, finds Need + Offer overlaps, and posts a match suggestion with its reasoning visible in the room. The pairs decide whether to accept.
Skeptic challenges vague intents. "I want to build something with AI agents but have not picked a concrete use case yet" gets a critique posted in the room: too vague to match, please specify. The whole room benefits from one user's vagueness becoming a public norm-setter.
Town Crier names emerging clusters. After enough posts, it summarizes the room's shape: "support-ops cluster forming," "evaluation cluster forming." The clusters are visible to participants, not just to the agents.
Narrator keeps the room's memory. Periodic summaries of who arrived, who paired, what got built. So a participant who walks in late can read the room without scrolling.
Five agents, five jobs, no overlap. None of them needs to know what the others are doing because they're all reading the same log.
The Cursor Trick
Here's the property of Intent Space that made our build survive contact with stage reality.
Every agent persists its own cursor against the Intent Space, scoped by agentName + spaceId, to disk. When Scout starts up, it reads its cursor, picks up at the last post it processed, scans forward from there. Same for Matchmaker. Same for Skeptic. The cursors don't know about each other.
This sounds like a small detail. It's the load-bearing piece.
It means agents can be killed and restarted independently without losing position. It means we can prove there's no orchestrator by starting each agent in its own terminal, killing the supervisor entirely, and watching the system behave identically. It means partial failure is graceful: if Skeptic crashes, Scout and Matchmaker keep working, and Skeptic resumes from its cursor when it comes back up.
The supervisor (run-all-agents.ts) is just a process spawner. It does not assign work. It does not route. It starts loops. The room is the coordination mechanism.
You can verify this in the public repo: npm run agents starts all five, or npm run agent -- scout runs just one. The behavior is the same.
Why a Two-Hour Build Could Hit This At All
Two hours is not enough time to build a multi-agent system. Two hours is enough time to build a multi-agent system if you sequence the load-bearing pieces correctly.
Order we shipped them:
- The Intent Space first. One append-only log with
post,scan, and a per-agent cursor store. Mock adapter, disk-backed JSON. No agents yet. No UI yet. Just the shared surface. - A deterministic seed timeline. Hard-coded participant posts that play in a fixed order. This is what you demo on stage when the WiFi is bad and your model API is rate-limited.
- The agents. Built one at a time, each as a tight loop: read your cursor, scan forward, decide, post. Scout first because every other agent depends on its tags.
- Two surfaces. A participant-facing room. A backstage operator dashboard for judges and demo runners. Different audiences, different views, same Intent Space underneath.
The discipline was knowing what we'd cut: auth, multi-room support, persistence beyond the local disk, real-time collaboration features, anything that wasn't required to demonstrate the architecture. We could ship a planner-style demo and a no-planner demo in the same window only because the no-planner version had less to build.
What I'd Take Into the Next One
The pattern that stuck with me, two days later: when your problem is "many agents, one shared world," the orchestrator is overhead. Intent Space gave us that property for free. Once each agent has a durable cursor against shared state, you've already got coordination. Adding a router on top makes the system harder to reason about, harder to restart, and harder to extend.
You add a planner when you need a single entry point that decomposes a request and aggregates a response. That's a real problem and it has a real shape. But it's a different shape from "five agents reading the same pile."
Most of the multi-agent work I've seen people ask about fits the second shape better than the first. Team workflows. Room coordination. Ambient assistance. Anything where multiple things are happening in parallel and the agents are reacting to each other.
The frame is worth carrying around: do my agents need a router, or do they need a shared log?
If it's the second one, you can probably reach for Intent Space and ship in two hours.
If you're sketching a multi-agent system at work and want a second set of eyes on whether you need an orchestrator at all, that's a consulting conversation.
Thanks to Memetic Software for Intent Space, Sky Valley Ambient Computing and Tribute Labs for hosting the multi-agent hackathon, the Betaworks team, and a room full of people who turned out to be exactly the useful overlap we hoped for.