I keep seeing engineers carry their laptops around with the lid held open just a crack. They’re walking to a meeting, or out to the car park, and they’re checking that the thing is still running. Some have tethered it to their phone’s hotspot so the agents keep going on the drive home.
Look at the screen and it’s usually three, four, sometimes six terminal tabs, each one a coding agent partway through something. One is waiting on a permission prompt. One finished ten minutes ago and nobody noticed. One went off down a rabbit hole and is quietly burning tokens on the wrong problem. Close the lid and they all stop.
The agents are fast, but the engineer has become a scheduler, and a tethered one. Their work is physically bound to a machine they have to keep awake, powered and online. That’s a lot of cognitive load, and a strange amount of logistics, for a job that was supposed to get easier.
The Console Is the Wrong Place
Local agents made sense as a starting point. You’re in your editor, you’ve got the repo checked out, you type a prompt and watch it go. Watching was the point, because early on you had to. You didn’t trust it and you shouldn’t have.
But watching doesn’t scale. A single console session is a fine way to supervise one agent. It’s a terrible way to supervise five. There’s no overview, no history you can skim, and no way for anyone else on the team to see what’s happening. The state of the work lives in a scrollback buffer on one person’s laptop.
That’s the part that bothers me most. We spent years getting work out of people’s heads and into shared tools, and then we put it back into a terminal.
Move the Work to Where Work Already Lives
Some of the most valuable work I’ve done in previous roles wasn’t writing code. It was making the engineering pipeline visible to the rest of the business. Product, support, sales, leadership: they all wanted to know what was being built, what was stuck and when something would land, and the honest answer used to be “ask an engineer”. Once that information lived somewhere everyone could see it, a whole category of interruptions and status meetings disappeared.
Agent work is no different. Right now it’s invisible in exactly the same way, except the audience is smaller. It’s the engineer, and nobody else. Agents are moving to the cloud. They run in their own environments, off your machine, kicked off from a ticket or a comment rather than a prompt you typed and then stared at. Once that happens, the console stops being the interface. It doesn’t need to be.
The interface becomes the tool your team already uses to track work: Linear, Asana, ClickUp, whatever you’ve got. Those tools exist to answer the questions the engineer with six tabs is trying to answer by hand, and the ones the rest of the business keeps asking. What’s in progress? What’s blocked? What’s ready for review?
A ticket moves to In Progress because an agent picked it up. It gets a plan attached. It asks a question when it’s stuck, and the question lands where a human will see it. It opens a pull request and moves to In Review. Nobody needs to watch a screen, and nobody needs to ask the engineer either.
This is the real shift. Agents stop being something you babysit and become something that reports in. You see what they’re doing when it’s appropriate to see it, and not otherwise. So does everyone else.
It’s the Same SDLC
None of this is new, which is what I like about it. The loop is the one we’ve been running for twenty years:
- Gather requirements
- Plan the implementation
- Execute
- Verify
- Review
- Iterate
- Ship
What’s changed is who does the executing, and where the humans sit in the loop. Requirements and planning are still very human, and they matter more than ever, because an agent will faithfully build whatever vague thing you hand it. Review is still human. Execute and a good chunk of verify are increasingly not.
Project management tools already model this loop. Statuses, assignees, comments, linked pull requests. We don’t need a new category of tooling to orchestrate agents. We need to take the one we’ve got seriously, and treat an agent as another thing that can pick up a ticket.
Visibility Without Babysitting
The word I keep coming back to is appropriate. I don’t want a live feed of every file an agent opens. That’s just the terminal tab again with a nicer font.
I want to see the plan before it executes, so I can catch a wrong turn early when it’s cheap. I want to know when it’s blocked and why. I want to see what was verified, and how, when it says it’s done. And I want a pull request that’s ready to review, not a diff I have to reverse-engineer.
Everything in between should stay out of my way. If I want to drill into the detail, it should be there to look at. I just shouldn’t have to look in order to trust that the work is moving.
What Still Needs Work
This isn’t solved. A few things I’m honest about:
- Tickets have to be good. An agent working from a two-line ticket will produce a confident guess. Backlog quality was always a problem. Now it has teeth.
- Cloud environments are fiddly. Getting an agent a working checkout, the right secrets, and a way to actually run the tests is real setup effort, and it’s the difference between useful output and expensive nonsense.
- Trust is earned per team. Some work I’d hand to an agent unattended today. Some I wouldn’t go near. The board should make that boundary visible rather than hide it.
- Local still has a place. For exploratory work, or when I’m figuring out what I even want, a tight loop in my own terminal is hard to beat.
This line of thinking didn’t arrive all at once. It started with the rise of the engineering agent manager, when I first noticed the job shifting from writing the code to directing and reviewing it. Then I went and built my own agent harness and orchestrator to see what it actually takes, and part 2 is where the limits of running it on a local box got hard to ignore. That was the experiment in building an agentic cloud harness. This post is what I took from it.
It’s also how I’m building ScaleBop. The work goes on the board, agents pick it up in the cloud, and I spend my time on requirements and review.
If your workday involves rotating through terminal tabs to see which agent needs you, that’s the signal. The work has outgrown the console. Put it on the board, let the agents report in, and spend your attention on the parts that need a human: deciding what to build, and deciding whether what came back is any good.