Agentic engineering: how to manage AI agents like a team

Agentic engineering is software engineering where AI agents write the code and you run the work. You decide what gets built, hand each piece to an agent, and review what comes back. You are no longer the person typing every line. You are the manager.

That sounds like a small shift. It is not. It changes what a good engineer spends the day on, and most people trying it are still doing it badly.

What agentic engineering is

For most of the history of programming, the unit of work was a keystroke. You thought, you typed, you ran it, you fixed it. Autocomplete and chat assistants sped that loop up, but you were still the one in it.

Agentic engineering moves you out of the loop and above it. An agent takes a task, reads the code, makes a plan, edits files, runs the tests and opens a pull request. You are not watching each step. You are deciding which tasks exist, which agent gets which, and whether the result is good enough to ship.

This is different from agentic coding, which describes what the agent does. Agentic engineering describes what you do around it: how you scope, supervise and review the work so it holds up in a real codebase.

It is also different from vibe coding, where you prompt until something seems to work and never read the result. Agentic engineering keeps the standards of engineering. The difference is who does the typing.

The manager's job

Once agents do the typing, four jobs are left, and they are the same four any engineering manager has.

Assign. Decide what the work is and who does it. A vague goal produces vague code, so the assignment is where most of the quality is won or lost.

Unblock. Agents get stuck, just like people. They hit a missing credential, an unclear requirement, a test that fails for reasons nobody told them about. A stuck agent that nobody notices is wasted time, so you need to see who is waiting on you.

Approve. Some actions should never happen on their own: pushing code, installing a package, deleting files. A good manager does not read every keystroke, but does want to sign off on the moves that are hard to undo.

Review. Nothing ships because an agent said it was done. You read the change and decide.

If that list sounds like management, that is the point. The skills that make a good tech lead, such as writing clear tickets, noticing who is blocked and reviewing with care, are exactly the skills this way of working rewards. The engineers who thrive will not be the fastest typists. They will be the clearest thinkers.

Practices that actually work

We have run a lot of agents. These are the habits that survived contact with real work.

One ticket per agent. Give each agent a single, well-defined task with a clear finish line. "Add a rate limit to the export endpoint" works. "Improve the API" does not. One ticket also gives you a natural unit to track, review and revert.

Keep scopes small. An agent that touches three files is easy to review. An agent that rewrites a module is a gamble. If a task feels big, split it into tickets before anyone starts. Small scopes also fail cheaply: if the agent goes wrong, you lose twenty minutes, not a day.

Isolate the work. Two agents editing the same checkout will step on each other. Give every agent its own copy of the repo and its own branch, so their changes only meet when you decide they should.

Require approval for pushes and installs. This is the rule we would keep above all others. Let agents read, edit and test freely inside their own sandbox, but make anything that leaves the machine or changes the environment wait for a human yes. It costs you a few seconds per approval and saves you from the one bad afternoon.

Review the PR, not the terminal. Watching an agent scroll output is the new version of watching a progress bar. It feels like diligence and tells you almost nothing. The pull request is where the real information is: the diff, the tests, the summary. Review there, the same way you would review a teammate.

Write the plan down first. Ask for a plan before code. A two-minute read of the plan catches the wrong approach before it becomes two hundred lines.

What this looks like in The Agent Office

We built The Agent Office because we wanted these practices to be the default, not something we had to remember.

The board is where the work lives. Your tickets show up as cards. Click one and hire a worker for it, and that worker gets its own workspace and branch. One ticket, one agent, no collisions.

The office itself is a small isometric room where each worker sits at a desk. You can see at a glance who is busy. When a worker needs something from you, such as permission to push or install a package, it raises a hand. That is the unblock-and-approve loop made visible: you do not poll terminals, you just notice the hand and answer it.

When the work is done, the pull request and a summary go back to the ticket, so review happens where review should happen.

And the trophy cabinet keeps score. Every finished piece of work lands on the shelf. It is a small thing, but a manager should be able to see what the team shipped, and it is more fun than a spreadsheet.

None of this is magic. It is the practices above with the friction removed.

The shift is the point

The homepage line says it plainly: congrats, you are the manager, and your agents do the work. People hear that as a promise of less effort. We think it is a promise of different effort, and better effort. You spend your day on what to build, what good looks like and whether the result is right. The typing was never the hard part.

The teams that get good at this early will ship more with the same people. The ones that skip the management part will ship more bugs with the same people. The tools are the same. The difference is whether you run the agents like a team or like a slot machine.

Try it on one ticket this week. Scope it small, hire one worker, approve the push and review the PR.