Atrium

Overview

Claude Code is capable enough to do serious work — but a single generalist agent has a predictable failure mode at team scale. It tries to do everything inline. It invents anonymous sub-agents with no persona or boundaries. It forgets what it did last session. When a design platform team needs to ship frontend, QA, copy, accessibility work, and documentation in parallel, one "helpful" personality doesn't behave like a team.

Atrium is my answer to that problem: a centrally managed roster of Claude Code agents for Spring Health's design platform team. It ships as a monorepo platform — agents, MCP server, API, real-time dashboard, and CLI — with a thesis baked into the architecture: make delegation structural, not prompted. If a behavior matters, encode it in the infrastructure, not the instructions.

The Challenge

The market had plenty of "I've got a few subagents." It didn't have a platform that treated delegation as a structural property of the system.

The failure mode I was trying to solve: the orchestrator stops coordinating and starts doing the work itself. Prompt-based delegation works most of the time. Infrastructure-based delegation works every time.

Three other problems had to be solved simultaneously:

• Role fidelity. Specialists needed to stay in their lane. A QA agent that drifts into writing copy is neither a good QA agent nor a good copywriter.
• Session continuity. Claude Code agents can't persist across sessions — that's a hard platform constraint. Each session starts cold.
• Observability. In a multi-agent system, "what's happening" is a real question. Activity that isn't visible can't be governed.

The Architecture

Four decisions shaped the platform:

1. Structural delegation, not requested delegation. Clea, the orchestrator, has a frontmatter tool allowlist restricted to Agent, Read, Grep, Glob. A PreToolUse hook enforces the same rule at the top-level Claude context. She physically cannot call Edit, Write, or Bash — so she must delegate to a named specialist every time. Delegation is the path of least resistance because it is the only path.

2. One mental model: Claude Code + MCP + files. No Anthropic API keys. No autonomous background agents. No custom runtime. Atrium runs on top of Claude Code — agents are markdown files, orchestration is slash commands, state is MCP tools, and activity is JSON on disk and rows in Turso. Everything is inspectable and forkable.

3. Sprint stories as memory. Agents can't persist across Claude Code sessions. Rather than fight it, I turned it into a feature: every sprint closes with a story written to the database — what was done, where deliverables live, what the next sprint should pick up. Continuity becomes a written artifact rather than a live process.

4. TDD as the default, not the discipline. From v0.14.0, Tanner (the QA agent) writes failing tests before implementation agents write code. Tests are the sprint's acceptance criteria in executable form. Every release since has shipped with zero regressions against the prior release's tests.

What I Built

The roster is 18 specialists across 5 domains: Operations, Product, Design, Engineering, and Research. Clea (orchestrator) uses Opus for strategic reasoning; specialists use Sonnet for execution. Iris and Sheena (the design agents) auto-load the verdant-design skill via frontmatter, so all Figma output stays inside Spring Health's design system by default.

The MCP server bridges Claude Code and the platform with 37 tools across 11 sections — agent discovery, session lifecycle, project management, sprint lifecycle, and shared context for agent coordination. Five composite lifecycle tools (atrium_start_sprint, atrium_start_task, atrium_complete_task, atrium_close_sprint, atrium_kickoff_project) bundle multi-step operations into single calls so the sprint engine can't drift out of state.

The sprint engine runs a 5-step chain per task: Tanner writes failing tests → implementation agent codes to green → Roman reviews copy → Tanner re-runs as QA → activity logged. A /kickoff wizard handles new projects interactively. The /sprint command dispatches tasks in parallel waves.

A PostToolUse hook fires on every agent tool call and streams activity to the API. The 7-page dashboard (Projects, Sprint Detail, Sessions, Live View, Agents, Analytics, Insights Inbox) renders it live — with per-session activity timelines, a quality radar chart for each agent, a leaderboard, and a drift detector that compares agent markdown files against the database.

The CLI publishes the whole platform as @springcare/atrium. One command installs 18 agent files, 3 slash commands, 2 hooks, an MCP config, and a Git identity pointer into any project.

Outcome

At v0.24.0: 18 agents, 37 MCP tools, a 7-page dashboard, 378+ tests, and @springcare/atrium@0.23.0 live on GitHub Packages. Every sprint since the platform had a sprint engine has been delivered by the agents inside it — the changelog is a record of 24 disciplined releases, not a demo.

The portable idea: if you want an agent team to behave like a team, make the protocol load-bearing. Clea's frontmatter allowlist is one field in a markdown file. It's also the reason the platform works.