Supervising Agents Like a Team: The Contractor Model

Previous chapters focused on supervising a single agent in a single session. This chapter raises the question to a higher level:

When there are multiple sessions, multiple roles, and many changes flowing through a repository, how do you supervise agents in a way that resembles engineering team management?

The answer isn’t adding another tool. It’s applying engineering management discipline to the work agents do.

Think of every engagement as a small contract: with scope, resources, permissions, verification, review, and audit.

The principle of this chapter is best summarized:

Scope it, equip it, run it, review it like a PR, gate on CI, audit afterward.

Or in the language of this book:

Treat the agent like a contractor with commit rights.

Each part of this sentence serves a different function, and together they form a control loop for scaling agentic work from a single session to a team-level workflow.

The Contractor Model

The most useful mental model may not be “agent as tool” but “agent as contractor.”

A good contractor is capable, works quickly, and doesn’t need someone micromanaging every command. But a contractor doesn’t know the entire organizational context, and ambiguous specifications will be interpreted on your behalf.

Agents are the same.

So each engagement should have six parts:

1. Scope It

Define the work clearly, with done-when, constraints, and a blast-radius map.

No scope means no contract, and without a contract the agent fills gaps with its own interpretation.

Good scope doesn’t just say “what needs to be done”—it must also say “what’s out of bounds” and “what counts as complete.”

2. Equip It

Prepare what the agent needs to work: memory files, repository context, checks, tools, permissions, and a working plan.

Giving less than needed means the agent can’t work effectively.

But giving more than needed means every added capability is another part of the blast radius.

The same principle from security in general still applies:

Give permissions the work requires, and no more.

3. Run It

When the workflow has good enough verification, let the agent run the loop itself.

This is the walking-away discipline from previous chapters. Humans don’t need to be present at every iteration if the agent has checks that can tell whether the output is approaching or has reached done-when.

Autonomy isn’t releasing the agent to work without control. It’s moving control from watching every step to the workflow and verification system.

4. Review It Like a PR

Agent output is a diff, just like a pull request created by a human, and should be reviewed to the same standard.

Don’t review from the agent’s description.

Review from what actually changed in the repository.

The agent’s summary might say “added validation and fixed edge case,” but what matters more is where validation was added, how behavior changed, and whether code outside the scope was touched.

5. Gate on CI

Human review shouldn’t be the only gate.

Automated checks must serve as a machine gate too.

Tests, lint, type checks, and integration checks should pass before a human spends time reading the diff carefully.

No auto-merge remains the default for this model.

Agents can create branches, commits, and pull requests, but merging is accepting a change and should be a human decision.

6. Audit Afterward

An engagement doesn’t end when it’s merged.

After work is complete, you must verify what permissions the agent had, what it actually did, and whether those permissions are still needed.

The last two steps serve different purposes:

Review-before-merge checks the changes.

Audit-afterward checks the relationship between the agent and the system.

Many teams do the first but forget the second. That’s where unused permissions, stale configuration, and temporary access start becoming permanent infrastructure.

The Supervisor’s Posture

The Contractor Model tells us how the human role changes.

You don’t need to write every line of code anymore, but you shouldn’t become an audience waiting for results.

Your role is task definer and final verifier.

You define what “complete” means, verify that it actually happened, and are responsible for both decisions.

When agents write code faster, coding ability is no longer the only bottleneck.

The new bottleneck is the ability to define work and verify results.

This has two implications.

First, prompts matter not just because they’re “smart instructions” but because they serve as work contracts.

Ambiguous scope is a contract that leaves room for contractor interpretation.

Second, agent throughput isn’t the same as safe team throughput.

The ability to review is the actual ceiling.

If an agent can create fifty pull requests a day but the team can only review five, the safe throughput of the system remains five.

This isn’t a disadvantage of agentic coding.

It’s a property of systems that require accountability.

Review Gate

The most important mechanism of the Contractor Model is the review gate, because this is where verification-first and adversarial review converge.

A good gate has three layers.

Checks Must Pass

Machine gate comes before human gate.

Tests, lint, type checks, and CI should pass before a human spends time reading the diff.

When the machine gate is green, humans can focus their attention on what automated checks can’t prove: design choices, cross-cutting concerns, scope discipline, and hidden assumptions.

Diff Must Be Read

Humans must read the actual changes, not just the agent’s summary.

Read in adversarial mode:

• Does the requirement actually ask for this?
• Has any behavior changed without being specified?
• Are there boundary cases the checks don’t cover?
• Did the agent touch parts of the system outside the scope?
• Were any dependencies or configurations changed unnecessarily?

The purpose isn’t to “catch the agent doing wrong.”

The purpose is to find what the verification machinery can’t see.

Merge Must Be a Human Decision

Merging is the point where accountability meets change.

So agents may create branches, commits, and PRs, but the final merge should come after human review.

No auto-merge doesn’t mean agents aren’t trustworthy.

It means giving permissions to agents and accepting agent results are different things.

An adversarial subagent reviewer can help filter diffs before human review, but shouldn’t become the decision-maker replacing humans.

It’s a filter, not a gate.

Post-Engagement Audit

The step teams often skip is the audit after the engagement ends.

The basic question is:

What permissions does this agent still have, and what permissions expired with the task?

A good audit doesn’t need to be complex. Use a four-item checklist:

Privileges

What permissions has the agent accumulated?

Are allowlists that were added still needed?

Are there permissions given for temporary fixes that shouldn’t remain?

Expired permissions should be revoked, just like contractor access that ends with the contract.

Logs

What did the agent actually do?

Session logs and execution logs should let you reconstruct what tools the agent used, what commands it ran, and what changes it made.

If you can’t reconstruct a session, it’s hard to say how it was supervised.

Auditability isn’t just about compliance—it’s part of engineering control.

Memory

What did the agent learn that should be permanent?

If the repository has conventions the agent repeatedly violates, or failure modes that recur, these should become memory or rules.

Don’t force humans to type the same warnings in prompts every time.

Repeated failures should become system constraints.

Cost

Was this engagement worth it?

Look at token cost, compute cost, and human review time.

An agent that writes code fast but uses more reviewer time than it saves may not actually increase throughput.

Audit is where the cost ledger becomes decision information, not just numbers after the fact.

Set cadence appropriate to risk: monthly audit per integration, or audit after engagements that touch permissions, production, or high-blast-radius resources.

An audit that exists but never runs has no more value than a checklist that doesn’t exist.

Patterns Are Levers, Not Guarantees

Before moving to specific patterns in the remaining sections, there’s an important reminder:

Engineering patterns aren’t natural laws.

They’re organizational levers.

Patterns expand what teams already do.

If a team practices verification-first seriously, patterns help the team do that at larger scale.

But if a team stops reading diffs because they believe the agent is “probably right,” the same patterns can automate abdication of responsibility.

Teams with CI, review bots, permission policies, and scheduled agents aren’t safe by default.

Without active human judgment, these systems may just make mistakes happen faster and in larger volumes.

So every pattern in this section should be read as a mechanism that needs a supervisor, not a formula that guarantees results.

Where We Stand

This section shifts the unit of supervision from session to engagement.

This chapter frames it with the Contractor Model:

Scope → Equip → Run → Review → CI Gate → Audit

Following chapters will fill in details for this framework: organizational patterns, economics, governance, and how to manage agents when they become part of the actual team.

The principle remains the same from the beginning of the book:

You’re not supervising the number of lines an agent writes. You’re supervising the quality of the system it’s changing.

---

This article is adapted from Chapter 22 of the Agentic Coding book.