How I structure teams when AI joins them.

My last note covered the system side: a design system agents can query, lint against, and be measured by. This one is about the people, because the honest answer to "how do we adopt AI" is almost never a tool decision. It is an org design decision. Agents do not transform a team. Structure does.

The unit of work changed

For most of my career, team size was set by production capacity: how many hands it took to turn decisions into screens, specs and code. That constraint is gone. Production is cheap now; judgment is the scarce input. So I keep squads small, three to five people, and I stop treating AI as a tool somebody opens. An agent is staffed onto the squad like a teammate, with a defined scope of work, rules it must follow, and output that gets reviewed the way a new hire's would.

Agents get onboarded, not installed

A new designer gets an onboarding packet: how we work, what the system is, where the bodies are buried. An agent deserves the same, and that is exactly what messay.ai is: the onboarding packet for my coding agent, packaged as a Claude Code plugin. Thirty-one commands for the work we actually do, twenty-eight design and engineering lenses for reviewing it, about 800 tokens of startup context so it knows the rules before the first prompt, and a memory folder that carries decisions and the last handoff between sessions.

That reframing changes where management happens. I do not manage agents in meetings. I manage them in context files. When the agent gets something wrong, the fix is rarely a better prompt; it is a better rule, written once and enforced everywhere, for every future session and for every teammate's agent too.

The shape: squads on a context platform

The topology is squads over a platform. Each product squad owns outcomes and holds a lead, engineers, and the agents they direct. Underneath sits the shared context layer: the design system, the messay.ai rules, and the MCP server agents call for tokens, components and usage checks. One small systems team owns that layer like a product. Squads never negotiate consistency with each other; they inherit it from the platform. And the platform team reads adoption data, human and agent alike, to decide what to improve next.

Ownership: drawn where judgment lives

The line I hold is simple. Humans own intent, taste, tradeoffs, and accountability. Agents own execution inside guardrails: drafting, iterating, checking their own work against the rules until it passes. The system owns consistency and memory, so neither people nor agents have to carry those in their heads. Nobody reviews keystrokes. We review intent going in and outcomes coming out, and we let the gates in between do their job.

The rituals change shape

Design crit stops being the place where drift gets caught; the linter does that at the edit. Crit becomes the place where we argue about whether the rules themselves are right. Retros start from the adoption dashboard instead of from memory. Handoffs become files: the agent writes down where it stopped and why, and the next session, or the next person, picks it up from there. The meetings get fewer and sharper, because the system now carries what meetings used to.

You do not manage an agent with oversight. You manage it with context, and context is a design artifact like any other.

That is the real leadership work now: deciding what the team should want, writing the rules that make good work the default, and building the feedback loops that tell you when the rules are wrong. The org chart did not get smaller. It got an API.