Agentic Workflows Lead

Overview

Spring Health did not have a structured approach to agentic AI work when this started. Today there is one: a 19-agent platform that any team can install with a single command, an AI context kit any designer can use in 30 minutes, and a personal AI operating layer that serves as the live prototype for all of it.

I built all three — with no charter, no team, and no internal precedent.

The category name I use is agent operating system, and it's deliberate. An operating system manages resources, schedules work, enforces contracts, provides services, has an interface, and is installable. Atrium does all of that for a team of AI specialists. The agents are the processes. The MCP server is the kernel. The sprint engine is the scheduler. The frontmatter contracts and enforcement hooks are the permissions layer. The dashboard is the process monitor. The CLI is the package manager. That framing is not marketing — it explains why the platform works where a pile of prompt templates would not.

Three Artifacts, One Framework

Atrium is the agent platform. Nineteen specialists across 6 domains — Operations, Product, Design, Engineering, Growth, and Research — coordinated by an orchestrator (Clea) who physically cannot do implementation work because her tool allowlist doesn't permit it. A PreToolUse hook enforces the same rule at the top-level context. The sprint engine runs TDD by default: the QA agent writes failing tests before implementation agents write code. A 7-page real-time dashboard surfaces what's happening at any moment. A CLI installs the full platform in one command. 24+ sprints shipped; every one delivered by the agents inside the platform.

Context Engine Starter is the enablement layer. A structured, model-agnostic AI context kit for the design team — personal workspace template, pre-built Spring Health reference engine (Verdant design system, UX writing guidelines, brand standards), five slash commands for session tracking and synthesis, and a 30-minute getting-started guide. The bridge between Atrium (team infrastructure) and individual designers (personal workflows).

Mission Control is the personal AI operating layer — the Obsidian-based markdown system I use daily that serves simultaneously as a productivity system, a live prototype for team enablement patterns, and the proving ground where Atrium agents run every day. Every pattern I recommend to others gets validated here first.

The Patterns

Working across these artifacts, I developed several practices that are genuinely new for Spring Health — and, I believe, for the broader field of AI-native work:

Frontmatter as contract. Agent roles encoded in YAML frontmatter that Claude Code reads as hard constraints, not advisory notes. When a constraint is in frontmatter, it is enforced. When it is in a prompt, it is a suggestion.

Structural delegation. The orchestrator cannot do implementation work — not because it is told not to, but because the tool allowlist removes that option. Correct behavior is the path of least resistance because it is the only path.

Sprint stories as memory. AI agents cannot persist across sessions. Sprint stories are the architectural fix: a written handoff artifact that explains what was done, where deliverables live, and what the next sprint should pick up. Memory becomes a document, not a runtime.

TDD as the sprint default. Tests are executable acceptance criteria. Every release since v0.14.0 has shipped green against its own new tests, zero regressions.

Context as a library. Designers feed relevant files to Claude before asking questions instead of re-explaining context every session. The context engine starter is the infrastructure for that behavior.

Activity as data. Every tool call every agent makes is a row in agent_activity and a WebSocket event on the dashboard. Observability is first-class, not a postscript.

Why It Matters

This body of work answers a question that most organizations will spend the next five years figuring out: how do you go from "individuals using AI tools" to "a team operating with AI as a structural collaborator"?

The answer is not more capable models. It is not better prompts. It is infrastructure: roles that hold, context that persists, governance that scales, and an enablement layer that makes adoption easy for people who didn't build the platform.

The precedent is set, the patterns are documented, and the platform is installable. That's what I built.