Your AI Agent Is a Contractor. Treat It Like One.

For a big part of my career I was the contractor. Consultancy after consultancy, client after client. And one thing kept surprising me: the team that was supposed to help us was often the least helpful group in the building.

Access requests took weeks. Questions got one-line answers, if any. In meetings we were the outsiders who didn’t know how things worked here, the ones who would break something, the expensive people who needed everything explained twice. Sometimes it was subtle. Sometimes it was not subtle at all.

I didn’t take it personally, or at least not for long. Mostly I was curious. We were there to help, the budget was already spent, so why act like we were the enemy?

Then I Changed Sides

A few years later I was working for product companies that relied heavily on contractors. Several of them weren’t software companies at heart. Software was something they needed, not what they sold. Small internal teams, a long backlog, and a management layer that solved capacity problems by calling a consultancy.

About a month in, I understood the hostility. I didn’t agree with all of it, but I understood it.

The contractors got the interesting work. The internal team usually knew exactly what needed building and had a pretty good idea how. They had been asking for time to do it for a year. Then management signed a contract, and a group of strangers turned up to build the new platform while the internal team kept patching the old one. The consultancy, of course, sold it as bringing in the experts.

The contractors had no context, and they said so loudly. “Why is this running on VMs?” “Why didn’t you use a managed service?” “This should really be in Kubernetes.” Every one of these questions has an answer, and the answer is rarely “because we didn’t know better”. It’s usually three people, no budget for the managed service, a migration cancelled halfway through because of a reorg, or a security team that took nine months to approve the current setup. From the outside, a compromise looks like incompetence.

The contractors got a different budget. This one hurts the most. The internal team fought for every licence and every extra node. The contractors arrived with a fresh budget and permission to pick tools, spin up environments and try things. The same organisation, playing by two sets of rules.

I lived this one. At one company I was the only DevOps engineer, and we went through the cloud bill line by line. We were deleting core network components that cost $70 a month because someone had asked whether we really needed them. Then a contractor team came in and set up a managed service at $600 a month, and it barely got used. Nobody said a word. It was fine. I remember looking at that invoice and finally understanding every cold look I’d ever got from a client team.

And then the contractors left. The engagement ended, there was a handover session, maybe a Confluence page, and the thing they built became the internal team’s problem. Their pager, their weekends, their incident reviews. For something they didn’t design, often didn’t agree with, and only half understood.

Put those four together and the frosty reception makes complete sense. The team wasn’t hostile to us as people. They were hostile to the arrangement.

The Comparison That Stuck

I was reminded of all this watching Kelsey Hightower’s talk on Zero Token Architecture. It’s a really good talk, full of ideas and opinions, and you should watch the whole thing. What I’m picking out here is probably the least important point in it. At one point he compares AI agents to contractors. It’s a passing remark, but it hit me hard, because it put a name to something I’d been feeling for the last five or six years. Now I see the same thing happening with agents, and it’s more true than it first sounds.

Go back through the list.

Agents get the interesting work. Nobody asks an agent to sit through the change advisory board. It gets the greenfield service, the new Terraform module, the prototype someone has been wanting to build for months. The team that knows the system gets to review it.

Agents have no context, and they’re confident about it. Ask one to add a queue and it will happily suggest the textbook option, without knowing you have a two-person platform team, a cloud bill someone in finance already watches closely, and a very specific reason you don’t run that particular service anymore. It will tell you the existing setup “could be improved”. So could everything. The reasons weren’t written down, so the agent can’t see them. The contractor couldn’t either.

Agents get a different budget. A team that had to fight for a second environment watches an agent burn through tokens, spin up test clusters and regenerate a module four times because the first three attempts weren’t quite right. I’m not saying that’s wrong. I’m saying the team notices.

And agents leave. They leave faster than any contractor I’ve ever worked with. The session ends, the context window is gone, and whatever reasoning led to that design went with it. The next session starts from zero. The contractor at least left a Confluence page.

The Dark Factory Argument

There’s a school of thought that says none of this matters. The idea of the “dark factory” is that agents build the software, agents maintain it, agents debug it, and humans don’t need to understand the code at all. You don’t read what the compiler produces, so why read what the agent produces?

I want to take this seriously, because parts of it are right. Nobody reads all of their dependencies. Nobody reads the Terraform AWS provider before running apply. We already trust a lot of code we have never seen, and teams that insist on reading every generated line will be slower than the teams that don’t.

But the argument breaks in a few specific places.

The compiler comparison doesn’t hold. A compiler is deterministic and has a spec. The same input gives the same output, and when it doesn’t, that’s a bug someone else fixes. An agent is a very capable colleague with no memory who is sometimes wrong in new and creative ways.

Somebody still gets paged. When production is down at 3am, “the agent will debug it” is a plan until the agent confidently fixes the wrong thing, or the outage is in the thing that lets the agent reach production in the first place. Accountability doesn’t move to the tool. Your auditor, your customer and your CTO will all want a human who can explain what happened.

And the next agent is also a new contractor. This is the part that people skip. Handing a system from agent to agent is exactly the contractor-to-contractor handover every ops team already dreads. Nobody holds the full picture. Each new session reads the code, infers intent, and makes changes based on its best guess. I’ve inherited systems built by three consultancies in a row. I wouldn’t wish that on anyone, and doing the same thing at machine speed doesn’t sound better.

So the dark factory doesn’t remove the problem of understanding. It moves it to a different place.

Own the Contract, Not the Code

So is the time spent reading what agents or contractors built worth it? I think we’re asking the wrong question. Reading every line doesn’t scale, not with agents and honestly not with contractors either. Reading nothing isn’t ownership. The goal is to understand the parts that matter and to make them cheap to understand.

That’s a platform engineering problem, and it’s one we already know how to solve. It’s the same thing a good platform team does for its internal developers: you don’t review how each team writes its service, you control the paved road it runs on.

In practice, the team that will own the result needs to understand five things, whoever or whatever wrote the code:

• The boundaries. What does this thing talk to, what does it expose, what does it have access to? If you can draw the box and its arrows, you can operate it. If you can’t, no amount of line-by-line review will save you.
• The guardrails. Tagging, allowed instance types, approved images, cost limits. These shouldn’t depend on anyone remembering them, human or agent. Write them as policy and run them in the pipeline. That’s what the policy as code series is about, and it works just as well on a pull request from an agent as on one from a consultant.
• The golden paths. If the approved way to get a database is a module, the agent should use the module. Put your platform where the agent can find it, which is the argument I made in The AI-Native Internal Developer Platform.
• The why. The context contractors never got. Why we don’t use that service. Why dev runs in one region. Why the budget looks the way it does. Write it down as ADRs, and keep them as plain .md files in git, next to the code. Not in Confluence, not in a wiki behind SSO, not in someone’s head. An agent can read docs/adr/ in the repository without any integration work. It can’t read a page it has no access to. Contractors can’t either, for the first two weeks.
• The proof. Tests, SLOs, dashboards, alerts. You judge the result by how it behaves, not by how the code looks. If you can’t tell whether it’s working, you don’t own it yet.

The “why” is the one that gets skipped most, so here’s what I mean. A few lines in the repository, loaded into every agent session and read by every new contractor on day one:

## Platform constraints (read before proposing changes)

- Compute runs on ECS Fargate. We evaluated EKS in 2024 and rejected it:
  two-person platform team, no appetite for cluster upgrades. See ADR-007.
- All infrastructure goes through modules in `platform-modules/`.
  Do not write raw `aws_*` resources for databases, queues or buckets.
- Monthly budget for non-prod is fixed. New environments need a cost
  estimate in the PR description (Infracost runs in CI).
- `eu-west-1` only. Data residency requirement, not a preference.
- If you think one of these is wrong, say so in the PR. Don't work around it.

None of this is clever. That’s the point. It’s exactly what I wanted from every client as a contractor, and almost never got. Most of the “why would you do it like this?” arguments would never have happened.

If You Are the One Hiring

Everything above applies whether you bring in a consultancy or roll out agents to your engineers. A few things I would do differently from what I saw on the client side:

Give them the context before they start, not after they’ve complained. Onboard an agent the way you wish you’d onboarded the last contractor, and you’ll find the contractors benefit too.

Give them the real constraints. If the internal team has to live within a budget, so does the work the agent or the contractor produces. Two sets of rules is where the resentment starts.

Keep the internal team in the loop on design, not just on review. The people who’ll carry the pager should decide where the boundaries are. Let the agent or the contractor fill in the boxes.

And measure the handover, not the delivery. The engagement isn’t done when the thing is built. It’s done when the team that owns it can run it, change it, and explain it to an auditor without calling anyone.

A Note From the Contractor’s Side

I still do this work. I’m a contractor, and these days I work alongside agents most of the day. I know how it feels to be the outsider in the room, and I know how it feels to inherit something built by one.

The best engagements I’ve had were the ones where I left behind something the team understood and could run without me. That’s the bar I’d set for agents as well. If they can’t meet it, the problem is probably not the agent. It’s the platform around it.

If your team is dealing with this, whether it’s contractors, agents, or both, and you want someone who has been on both sides, get in touch.