Each Role Owns a Contract: A Team Operating Model for Agentic Delivery

AI tools are making code faster to write. They are not yet making teams faster to deliver. Most teams that adopt coding agents see the same shape: implementation shrinks, and the team feels both faster and more frustrated. Frontend devs wait for signed-off designs. Designs wait for signed-off requirements. Business users change their minds mid-flight and send the cascade backward. PRs queue, reviews fall behind, testers run out of capacity.

That isn’t a people problem. It’s a structural one. Roles built around “writing code is the slow part” don’t survive once writing code stops being the slow part. The slow steps move — to clarification, sign-off, validation, integration — and those steps still rely on Slack threads, Word docs, and Figma files where you can’t even measure how long they take.

This article explores one way to absorb the new throughput: every role’s main deliverable shifts from doing the work to owning the contract that defines the work. It’s a hypothesis worth testing on a real team, not a proven pattern. Reports like the dramatic PR-throughput gains from OpenAI’s Symphony point in the same direction, but the harder question — what kind of team structure absorbs that volume without losing quality — is still open.

What “owning a contract” means

A contract here is an artifact that pins down one slice of the work clearly enough that anyone — human or agent — can build against it and check whether the result is correct. In practice:

• It’s versioned in Git (or somewhere else diffable).
• It’s owned by exactly one role.
• It’s machine-readable where it can be — YAML, schemas, executable tests.
• Changes go through review the same way code does.

The closest existing example is Requirements as Code: the BA’s wiki page becomes a YAML file in Git, reviewed via PR. The hypothesis here is that the same pattern applies to every other role.

It’s worth holding that hypothesis loosely. “Contract” is doing a lot of unifying work across artifacts that are genuinely different — a requirements YAML, an executable test suite, a set of design tokens, and an OpenAPI schema have very different properties (who writes them, who reads them, how they fail). Calling them all contracts is rhetorically tidy but flattens those differences. The argument works to the extent each role can find a versioned, checkable artifact that fits its work — not to the extent everyone has to call theirs a “contract.”

Each role’s contract

Contracts plug into each other. The BA’s acceptance criteria become the tester’s executable suite, which becomes the business user’s sign-off checklist. The designer’s tokens become the frontend’s component fixtures. The backend’s API contract is what the frontend builds against.

How this could speed delivery without trading quality

The speed argument has three parts:

Parallel work. With API, design, and acceptance contracts each owned and signed off independently, backend can build against the API contract while design is being finalized. Frontend can build against design tokens before full screens are approved. Tests can be written against acceptance criteria before any code exists. Today most teams sequence these because “what’s stable enough to build on” is a judgment call. Explicit contracts make the stable subset visible.

Scoped cascades. When a business user changes their mind, the contract diff shows the blast radius. Only the contracts that touch the changed field need re-approval. With prose specs, the same change feels global, so everything stops.

Smaller approval batches. A contract PR is reviewed in minutes. A 12-page spec document is reviewed in days. The throughput of approvals goes up because the units are smaller.

Quality isn’t traded away because the contract is the source of truth. Acceptance criteria are executable, so regressions are build failures. API schemas validate every PR. Design fixtures generate visual review. Code that drifts from a contract fails before merge, not in production. That’s what makes “agentic” work for teams that don’t vibe-code: agents do the implementation, but the gates around the implementation are authored and approved by humans, and they’re enforceable.

Small teams, contracts at the seams

The natural unit for this model isn’t a twelve-person project team in seven roles. It’s a small focused crew — usually 3–6 people — that owns one product surface end-to-end, from discovery through validation. Smaller than that and you lose resilience and specialist depth. Larger and the internal handoffs come back, dragging internal contracts back with them.

Inside a small team, fewer formal contracts are needed. People hold context in their heads, ambiguity is resolved in a five-minute conversation, and the artifact overhead would cost more than it saves. Contracts matter most at the seams between people and between teams — small teams have fewer internal seams, so they need less internal formalism.

The seams that remain matter more. The team’s boundary with the rest of the org — the API it exposes, the design system it consumes, the requirements it accepts, the validation it returns — is where contracts now do all the work. The org-level model becomes: many small focused teams, each coordinating informally inside, all communicating with each other and with the business through versioned contracts at the boundary.

Two honest caveats. Small focused only works when the team is also WIP-limited; a small team running five parallel workstreams is thrashing under a different name. And the bet that AI compresses enough work to make a small team viable holds best on green-field surfaces — it hits floors fast in legacy or regulated systems where the load is in context and compliance, not implementation.

Where teams actually lose time

Most teams that adopt agents but don’t restructure can’t answer “where are we losing time” — not because the answer is hidden, but because the gating artifacts (designs, specs, sign-offs) live in places where you can’t measure cycle time on them.

The usual culprits, roughly by impact:

1. Wait on sign-offs. A design sits in Figma waiting for a stakeholder. There’s no timestamp, so “sign-off” feels like part of the design step instead of a separate queue. It often dwarfs the design step itself.
2. Cascading requirement changes. A change ripples backward through every downstream role because the spec is prose and nobody can see exactly what changed.
3. Sequential dependencies that didn’t need to be sequential. Frontend waits for the whole design instead of the stable subset. Tests wait for the whole spec. The contracts that are stable get held hostage by the parts that aren’t.
4. Ambiguity that surfaces during implementation. Frontend hits an edge case the design didn’t cover, the question round-trips to BA → business user → back. Each round-trip is days. Versioned, diffable contracts surface ambiguity at the contract PR review instead.

The first thing to do isn’t to restructure. It’s to instrument every handoff. Timestamp when the BA delivers the spec, when the designer starts, when sign-off lands, when the frontend starts. Sum the gaps. The biggest gap names the artifact whose contract is worth moving first.

The honest limits

This model moves the queue. It doesn’t eliminate it.

• The bottleneck moves to writing good contracts, which has always been hard. AI helps with that less than it helps with implementation.
• Business users don’t naturally think in contracts. Asking them to formalize validation is a real change-management problem this model glosses over.
• The designer’s move from Figma exports to diffable tokens and fixtures is messy and takes months.
• The project lead can become the bottleneck on contract approval — a single chokepoint at a different layer.

So this isn’t a solution to the throughput problem. It’s a different shape of the same problem — one that’s plausibly more tractable because every gate becomes measurable, but not proven.

How to actually start

Don’t reorganize the team. New role descriptions written before any artifact has moved are guesses, and they generate more resistance than the change can absorb.

Instead:

1. Instrument the handoffs. If you can’t see the queue, no model will help.
2. Pick the slowest gap and move that one artifact into Git — usually requirements, because it has the most leverage, but follow the data.
3. Watch the roles around it reshape on their own, then expand.

AI tools don’t reorganize teams. They expose which parts of the team were coding-bound and which parts were doing something else — clarification, validation, approval, trust. A team that treats each role’s contract as the deliverable can plausibly turn AI throughput into delivered value. A team that leaves its roles unchanged feels the same throughput as pressure.

Related Reading

• Requirements as Code — the Git-native foundation under the requirements contract
• Coding Agent Swarms — what implementation looks like once contracts are authoritative
• The Agent Harness Pattern — the engineer-level parallel to the team-level move