The CTO's playbook for AI coding agents at a 30-70 person company

A CTO at a 45-person company gets the same question from two directions in one week. The board asks how the AI rollout is going. A staff engineer asks why the agent in her repo keeps re-adding a dependency the team banned in July.

The honest answer to both is the same: adoption happened, coordination did not. Four teams picked four setups. Three repos have a CLAUDE.md, two have an AGENTS.md, one has both and they disagree. The July dependency call lives in a meeting note that no agent has ever read.

This is the normal state of a 30-70 person company six months into agents. It is also fixable, mostly with decisions rather than tools.

Why 30-70 is the hard size

Under 30, coordination is still atmospheric. People overhear decisions, the CTO is in every review that matters, and an agent that gets something wrong gets corrected by the person sitting next to it.

Over 70, there is usually a platform team or at least a staff engineer whose job includes this infrastructure.

In between, you have too many decisions for any one person's memory and no one whose job is the memory. Agents make the gap visible because they amplify whatever is written down, and at this size what is written down is incomplete, contradictory, or both. An agent with no decision record does not pause and ask. It picks something plausible and ships it at machine speed.

Decide once, company-wide

Four decisions are worth making at the company level rather than letting each team rediscover them.

Which agents are sanctioned, and for what. Not a procurement exercise: a short list everyone knows. Which tools, which models, and which kinds of work they may touch. Prototype code is a different risk class from billing logic, and the list should say so.

What agents may do unattended. The usual line is that agents propose and humans merge, enforced by branch protection rather than by convention. Whatever line you draw, draw it explicitly, because the default is that each senior engineer draws their own and the org ends up with twelve policies.

Where instructions live. One convention, not five. If agents read CLAUDE.md or AGENTS.md at startup, then every repo gets one, it is reviewed like code, and it points at the decision record instead of duplicating it. The failure mode of the alternative is documented in CLAUDE.md vs agent memory: instruction files go stale the moment they try to be the decision log.

Who owns the decision record. Not who writes every entry. Who is accountable for the record existing, being current, and being where work happens. At this size that is usually the CTO or a head of engineering for the first year, explicitly, in writing.

Write down the short list

You do not need to document everything. You need the calls that are expensive to violate:

• The pricing and packaging model, and what is frozen while it changes.
• Data boundaries: what customer data may touch which systems, and what may never leave.
• Architecture invariants: the queue technology, the auth pattern, the "we do not add a second" list.
• Security and compliance constraints that apply to every change.

For each: what was decided, why, what was rejected, who owns it, and its status. A reversed decision stays in the record, marked superseded, pointing at its replacement, because a deleted decision comes back as a fresh proposal argued by people who were not in the room. The format question is covered in ADRs for AI coding agents and the tooling comparison in decision log software for product and engineering teams.

The location rule matters more than the format: the record has to live where agents read and humans review. A perfect log in a tool nobody opens during a pull request is decoration.

Roll out in an order that survives contact

One team, one repo, four weeks. Pick the team with the most patient lead, not the most enthusiastic one. Give the repo a proper instruction file and a real decision record before the agent writes a line.

Measure rework, not volume. Lines of agent-written code is a vanity number. Track how often agent PRs get reverted, how often review catches a decision conflict, and how long PRs wait for review. If review is the constraint, fix that first: smaller agent PRs with the reason attached, and the team's decisions in the same room as the review. What agents should carry into a task is mapped in best tools for AI coding agent context.

Codify as you go. Every time the pilot team corrects the agent twice on the same thing, that correction becomes a written instruction or a recorded decision. Two corrections is a pattern; a pattern is a policy.

Then expand, team by team. Each new repo gets the same starter: instruction file, decision record, named owner. New engineers joining a team with this in place onboard faster than they did before agents, because the briefing exists as an artifact instead of as a series of hallway conversations.

What breaks if you skip this

The failure mode is not dramatic. It is drift, at machine speed. Each team's agents learn their local habits, the habits diverge, and six months later the services disagree about things the company decided once. Multi-agent setups make it sharper; multiple AI coding agents, one repo covers the shared-memory version of the same problem. By the time it shows up as an incident, the decisions were made correctly and the record simply never reached the work.

Where Lockstep fits

Lockstep is built for exactly this gap at exactly this size. It is a shared record of accepted product and engineering decisions, versioned so a reversed call points at its replacement. Engineers and agents get briefed on the decisions relevant to what they are touching when work starts, and a PR check flags changes that collide with a binding decision. One team and one repo is enough to start; company-wide onboarding is not required.

The honest caveat: Lockstep is early stage, onboarding design partners, and the individual pilot starts with Claude Code. If that fits your rollout, it is the fastest way to give the playbook above a working record. If it does not, the playbook stands on its own with a wiki, ADR files, and discipline.

The short version

At 30-70 people, your agents are only as coordinated as your decisions are written down. Decide the four company-level things once, record the short list of binding calls where work happens, pilot with one team, and measure rework. The companies that do this get compounding returns from agents. The rest get very fast drift.