The popular question is whether AI will replace engineering managers. I think it is the wrong question, and the answer shows up quickly once you try to run agents as a working system instead of a chat window.
I have built four such systems: a print-on-demand shop run by nine agents, a workflow that scans repositories and opens pull requests for bugs, a dashboard that scores a team’s health, and a private dashboard for my lab. On the surface they have little in common. Underneath, I kept doing the same work, and it looked far more like managing a team than like writing prompts.
Agents as a team, not a tool.
In each project, agents hold a role, take defined inputs, and produce defined outputs inside a workflow, much like the roles on an engineering team. Treat AI as a tool and you ask what it can do. Treat it as a team member and you ask a different set of questions. What job does it hold? What will it receive? What must it return? Who checks the result?
Those are management questions, and engineering managers already know how to ask them.
Managing a system of agents draws on the same habits as managing people.
Six habits that carried over.
Write the role down.
Every agent in the print-on-demand shop has a written role, a defined input, and a defined output. An agent with a vague job behaves like a person with a vague job: it does something plausible that is not quite what you needed. The written role is what makes the hand-offs reliable, because each agent knows what it will receive and what it must return. Drop Shipping Automation →
Set the standard once.
One agent in the shop sets the brand standard that every stage is measured against. In Bug Manager, a custom set of skills describes what a problem looks like, so every repository is judged the same way. A team without a shared standard argues about taste. Agents without one simply drift. Bug Manager →
Keep a person at the decision points.
In the shop, the owner’s part is deliberate and small: raise a request, approve what lands in the review queue, and adjust the standard. In Bug Manager, the agent attempts a fix and opens a pull request, and an engineer reviews the proposed change from the ranked list. The agents do the work, and people keep the decisions.
Make the state visible.
Every product in the shop is a record with a current state and a version number. Each hand-off writes an event to a ledger, and work that is waiting sits in named queues that Mission Control shows. At the June 2026 snapshot the ledger held 2,886 events. Sprint Ledger does the same for a team, putting capacity, pace, and open pull requests on one board. Sprint Ledger →
Plan for repair.
A revision in the shop creates a new version and leaves the history intact, and one agent, Scanner, exists to rebuild the workflow’s records from the files on disk when they need repair. A system that runs without someone watching needs a way back.
Decide who can see what.
The version of Sprint Ledger I used at Fanatics held evaluations of staff, so it was visible only to me and senior leadership. Once agents read the data a manager holds, who can see the output becomes a management decision too.
The manager’s job moves into the system.
If agents do defined jobs, the work that is left for a manager is the work these projects kept returning to: defining roles and standards, choosing where human judgment stays, keeping the system visible, and deciding what a person should look at next.
Sprint Ledger reflects the last of these. A status with no next step is only a color, so each status comes with a written reason and a suggested opening for the next one on one. The same habit applies to a dashboard for people and to a workflow of agents.
AI does not remove the need for engineering management. It adds agents to the things a manager manages, alongside people and conventional automation.
Where I expect the argument.
The habit I expect the most pushback on is the third. Some will say that a person at every decision point slows the system down. Others will say those people are the only reason it is safe to run. In my projects, a person keeps the decisions, and I am curious where others have decided to take them out, and what happened when they did.
Over to you
- Where does your team draw the line between what an agent decides and what a person decides?
- What have you written down for an agent that you never wrote down for a human?
The projects behind this essay.
- Drop Shipping AutomationWritten roles, a standard, a review queue, a ledger, and a repair agent.
- Bug ManagerOne standard across repositories, and a person reviewing each proposed fix.
- Sprint LedgerTeam state made visible, a status that always leads to a next step, and a visibility boundary.
- Homepage DashboardA private dashboard of live cards for every service, refreshed every 15 minutes.