The Tools That Scale My Team Now Scale My Agents
Agents need a culture too. AgentsMD is where it lives.
When my team and I first started building with agents, we had to review every line of code they wrote. It prevented issues but capped velocity at human reading speed.
The same instinct shows up in management. The first version of being a manager is leading by editing the work product, because editing was what made us effective as ICs. With agents, that instinct turns into reviewing every line, fixing every example, patching every prompt. Both stop scaling at the same point, for the same reason.
So we ran an experiment. We codified a whole organizational system into the AgentsMD and let agents run coherent, 24/7 coding loops against it. They produced more than 500,000 lines of code that came close to production quality after human review and hardening, because the consistency was already in the spec.
Building Culture at My Last Company
The frame for this came from running a tech-enabled services company through its first three years. We raised a lot of money, hired two hundred people across operations, sales, and engineering, and were disciplined enough to get to cash flow positive. The hardest problem was not any one function but keeping everybody pulling in the same direction once the team got too big to know each other.
What worked was a layered culture deck shared across the company. At its core were five archetypes: Owner, Athlete, Lifelong Learner, Troupe, and Pioneer. Each archetype carried two values, defined with what they meant, why they mattered, and a concrete example from our work. Customer Obsession under Owner read: before building anything, solicit feedback via text from five customers. The deck was a hundred slides and read like a constitution.
People joining the company learned it. People leaving the company quoted it. Once the foundation was in place, decisions came out the same way across every situation, regardless of who was in the room.
Identity, Values, and Mission Are the Foundation
The same seven layers show up in every spec I write now. Identity, Values, and Mission are the shared foundation: who we are, what we care about even when it costs us, and what we’re here to do.
Above the foundation, each domain adds four more layers. Principles are the physics of the domain. Patterns are reusable solutions to common needs in the domain, like the hamburger menu in design or test-driven development in engineering. Processes are sequences of activities, like a deploy pipeline in engineering or a customer onboarding flow in operations. Examples are the concrete rules and anti-patterns that fall out, like a ban on hardcoded color tokens or a requirement that every test assert a single behavior.
The split lets product, design, and engineering each move at their own speed while retaining quality. Each layer compresses many concrete rules into a smaller set of more abstract ones. Specify at the foundation and the layers above follow. Specify only at the examples and you are playing whack-a-mole: fix one output, the next one breaks.
Centralized vs Decentralized Organizations
Organizations come in two shapes, and they pull against each other.
A centralized organization concentrates decision-making in a central system and rolls out a consistent version to every unit. Most traditional software companies run this way: features are built and tested centrally, then released to every customer in one version. Quality stays high because every customer gets the same product, but velocity caps at whatever the central team can ship.
A decentralized organization gives each unit the autonomy to operate on its own. Uber did this in its early years, putting every market under its own GM, free to make local calls. The company added markets almost as quickly as it could hire, but consistency suffered: every market built a different product, and integration became the new bottleneck. Both shapes ship software; the difference is where the autonomy lives.
Identity, values, and mission keep parallel units in sync across domains. Each domain’s principles, patterns, processes, and examples keep that domain consistent within itself. The deeper the foundation and the richer each domain’s stack, the further the parallelism can stretch before the seams start to show.
The same shape applies to working with AI. Reviewing every line of agent output is the centralized model: high quality, low autonomy, hard cap on velocity. Running multiple agents against a shared spec is the decentralized model, and it only works if the foundation is in the spec.
When We Are Not in the Room
Culture is not the slogan on the wall. It is what people actually do when values collide: speed against quality, revenue against trust, short-term against long-term. AgentsMD does the same job for a workforce of agents.
All of this now lives in the AgentsMD file at the top of every repository I run. The root file imports a per-agent role file, a company file holding identity, values, and mission, and one file per domain:
@ROLE.md
@agents/COMPANY.md
@agents/PRODUCT.md
@agents/ENGINEERING.md
@agents/DESIGN.md
@agents/OPERATIONS.md
@agents/FACTORY.md
@agents/DECISIONS.mdThe structure is written before the agents touch the codebase. Each parallel agent inherits identity and values from the foundation and works within the principles, patterns, processes, and examples for its domain.
The artifact teaches the agents how to behave when the literal instruction runs out, which is often, because no spec covers everything. Without that anchor, an agent falls back on its training distribution instead of how the company actually behaves. With it, the foundation keeps the next decision consistent with every decision before it. Patches at the top never reach the layers below; the only way to change behavior at scale is to change the foundation.
The 24/7 coding loop was the first real test. Several agents worked in parallel against the AgentsMD, with no human in any individual decision. The output composed back together cleanly because the foundation was in the spec, not in the review.
Living specs grow only by addition. We kept a Decision Log with seventy-nine timestamped decisions and rationale, never deletions. When a behavior looked odd six weeks later, we could trace it back to a specific decision and see why it existed.
The Frameworks Come With You
Vibe coding hits the same wall first-time managers do: without a foundation, the work cannot scale past a single person. The fix in both cases is to write identity, values, and mission first, then the principles, patterns, processes, and examples for each domain, and then let the team or the agents run.
Agents need a culture too. The AgentsMD gives them one, shared across every domain just as the deck was shared across every team.
The tools that scale my team now scale my agents.