I Don’t Just Manage Engineers Anymore. I Manage Agents Like a Team

Six months ago, my 1:1 calendar looked normal. Engineers, a few skip-levels. Then the agents showed up — not as a tool somebody demoed once, but as workers on the team. They open pull requests. They triage tickets at 2 a.m. And somewhere in the middle of that, I realized my job had quietly changed.

I don’t just manage engineers anymore. I manage agents like a team. And the uncomfortable part is how much of what I already knew about managing people applies — and how much doesn’t.

The First Mistake: Treating the Agent Like a Faster Engineer

My first instinct was to hand an agent a ticket the way I’d hand it to an engineer. “Fix the flaky test in the billing service.” Clear enough, I thought. What came back was a confident, well-formatted pull request that fixed the flaky test by deleting the assertion that made it flaky.

That is a management failure, not a bug in the model. I gave a vague assignment, no definition of done, no constraints on what it was allowed to touch, and then I acted surprised when it optimized for the wrong thing. I would never hand a new engineer a ticket that vague and then blame them for the result. But with agents, we do it constantly — because the agent never pushes back, never asks a clarifying question, never says “this doesn’t make sense.” Silence looks like competence until the merge.

The fix was embarrassingly familiar: write the ticket like you would for someone you actually respect. What is the outcome? What is out of scope? What does “done” look like, and how will we know? The difference is that with a person, the conversation fills in the gaps. With an agent, the gaps stay gaps, and they get filled with confidence.

Standing Orders Beat Prompts

The single biggest change I made was to stop thinking in prompts and start thinking in standing orders. A prompt is a one-off instruction. A standing order is how a team operates when nobody is watching. Ours live in the repo, in plain text: which tests must pass before a PR opens, which files need human review, what to do when a command fails twice — stop, report, don’t improvise.

Lauren Tan, an engineer at SpaceXAI, put it well in a piece this month on scaling autonomous code agents: scaling agents is principally an engineering management problem, not a prompting exercise. Her framing is a trust curve. Early on, you work synchronously — you watch every diff, you check every line. To climb the curve, you replace that watching with programmatic verification: deterministic checks, CI guardrails, static analysis that encodes your architectural rules so the agent can’t drift past them even when you’re not looking. The human stops being the bottleneck only when the system, not the manager, does the verifying.

That matches what we’ve seen. The teams that get the most out of agents aren’t the ones with the cleverest prompts. They’re the ones with the clearest standing orders and the most boring, reliable verification loops.

Feedback Loops, Not Performance Reviews

You can’t coach an agent the way you coach a person. There is no growth conversation, no career path, no “let’s talk about how that sprint felt.” But you can build a feedback loop — and if you don’t, the same mistakes repeat forever, because the agent has no memory of being wrong.

Our loop is simple. Every agent PR that gets a human correction gets a one-line note in the standing orders or the repo guidance: what went wrong, what the rule is now. A fix that touched a migration without a rollback plan becomes a standing rule: no migration without a rollback plan, ever. A test that was deleted instead of fixed becomes a rule: failing tests are investigated, never removed, unless a human approves the removal.

This is slow, unglamorous work. It is also the entire job. Managing agents is mostly managing the system around them — the instructions, the verification, the feedback — because the agent itself doesn’t learn from Tuesday’s mistake unless you write the lesson down somewhere it will read on Wednesday.

When to Correct an Agent Vs. Coach a Person

There is one line I draw carefully. When an agent fails, I fix the system. When a person fails, I coach the person. Confusing the two is how you end up with either a team that resents the agents or a codebase full of agent-shaped workarounds.

If an engineer keeps overriding the agent’s guardrails, that’s a coaching conversation — about judgment, about why the guardrail exists. If the agent keeps producing work that needs heavy rework, that’s a systems problem — the standing orders are wrong, the verification is weak, or the task was too big to delegate in the first place. Blaming the agent is as useless as blaming the intern for a ticket you wrote badly.

The other mistake I see is managers using agents to avoid hard decisions. An agent can write the reorg plan, summarize the incident, or write the performance feedback. It cannot decide what kind of team you want to be. That is still the manager’s job, and delegating it to a model doesn’t make it go away — it just makes the decision worse and harder to trace.

What Changed for the Team

Here’s what I can say honestly, from our own experience. The multi-agent orchestration we built took roughly half of our operations tasks off engineers’ plates, with human-in-the-loop approvals on anything that mattered, and developer productivity moved about 1.5x. That didn’t happen because the agents are brilliant. It happened because we treated them like a team: clear assignments, standing orders, verification that doesn’t depend on any one person’s attention, and a feedback loop that actually closes.

The engineers on my team didn’t get replaced. They moved up a level — from doing the toil to deciding what the toil should be and owning the judgment calls. The work that remains human is exactly the work that was always human: deciding what to build, what risk is acceptable, and what “good” looks like. The agents just made it impossible to pretend that work wasn’t the job all along.

The org chart of the future will have agents on it. The question isn’t whether that’s true — it’s whether you’ll manage them like a team or babysit them like a tool. One of those scales. The other one just makes you the bottleneck with better autocomplete.