We ship the AI layer with the code

Every repo we hand back carries instruction files, specs, skills, a DESIGN.md, and an MCP server. What each one is for, and how our people and the agents split the work of building them. When we finish a project, the client keeps the code. That used to be the whole list. Now the layer that drafted the code has to come with it, or the client's own team cannot extend the system the way we did. This is what we leave in the repo, in the order we hand it over. The instruction files At the root of every repo we hand back sits an AGENTS.md. It says how the system is built, what the pull request gates are, which data may never appear in a prompt, and where the runbooks live. It is the first thing an agent reads and the first thing a new engineer reads, and it is the same file. That is the point. The specs Requirements that live in chat history die with the session. We keep them in the repo with OpenSpec, an open source spec driven development tool that works with Claude Code, Cursor, Copilot, and most other coding agents. Two folders. openspec/specs holds the current truth about how the system behaves. openspec/changes holds each proposed change as a small folder: a proposal, a design, a task list, and the delta to the specs. The agent works the task list, a person reviews the proposal, and when the change ships the delta folds back into the specs and the folder is archived with a date on it. That archive is where a new engineer goes to learn why the system behaves the way it does. The skills A skill is a folder of instructions an agent loads when a task calls for it: how to write a migration for this database, how this framework wants a route structured, how to score a support call against the client's own quality rubric. Most of a modern stack already has one. Frameworks and databases ship them, or the community maintains them, and they install with one command. When a maintained skill exists for Next.js or Supabase or the agent framework we picked, we use it and stop there. Maintaining our own copy of someone else's knowledge is a way to fall behind. When nothing fits, we write our own. The ones we write most often are for the client's own process, because nobody else can: the integration playbook, the rubric a support team uses to grade its own calls, the escalation rules a voice agent has to follow before it hands a caller to a person. Those live in the repo next to the code and change in the same pull requests. An engineer who joins next year and asks the agent to onboard a new data source gets the answer the team agreed on, not the answer the model guessed. DESIGN.md Design systems used to live in Figma and in the heads of the designers who made them. That worked while people built every screen. Now agents build screens too, and an agent that has never seen your design system produces the internet's average: default spacing, default blue, a card that looks like every other card. DESIGN.md is the fix. It is a plain markdown file at the root of the repo, a format Google Stitch introduced, that gives an agent the design system in the form it can use: tokens with their real values, the type ramp, the spacing habits, the component rules, and the reasoning behind them. When we deliver a design system, the Figma library gets a DESIGN.md twin and the file ships with the code. The result is simple to state. A feature the client's team builds with AI six months after we leave looks like it belongs. Two cautions we give every client. The file goes stale unless it is versioned with the product, so it changes in the same pull requests as the components. And it does not replace review. Generated UI is still work someone signs. The MCP server On a customer journey platform we built for a US airline, leadership used to wait two weeks for an analyst to score a handful of calls by hand. Now they ask a conversational agent a question in plain language and get an answer the same day, grounded in every conversation rather than a sample. The agent r