When AI agents do the work, what's your job?

0:00Cold open

Over five working sessions, an agent stood up a complete system on cloud infrastructure for me: a virtual machine, its networks and proxy, a message bus, a database, secrets, a mailbox, a web form, a publishing pipeline. In all that time I never opened the virtual machine. Never went into a container. Never edited a config by hand. So what did I do? That's this video. Because the job didn't go away. It moved.

0:34Format note and the system

Before I say where it moved, a quick note on the format. This one's a talk piece, so treat it like a podcast: listen without watching and you won't miss a thing. And so you have the picture, the system is a debate show. Four models argue over a letter from the public, a fifth rules, and it renders and publishes itself. The build ran as a series of sittings, an agent acting as foreman, spawning workers, and coming back to me at the forks. What follows is what I said about my own part while it happened, cleaned up so it reads straight through.

1:12What operating through an agent means

So, where the job moved. Start with what it isn't. It isn't writing code. There were bits of code here and there, but the work was a full infrastructure deployment: projects, identities, networks, services. If you've done that by hand you know the feeling. Cloud consoles are heavy on security and buried in options, and you spend the afternoon hunting for the twelfth menu under the right heading, hoping it's the one you needed. The agent doesn't lose that memory. It knows where everything is. So let it drive. My part was the plan: what should exist, how it should be scoped, what secure looks like when it's done. Security was in the plan before the first command ran, which is why it came out that way.

2:03What I actually did

That's the plan. But a plan is written once. So what did I actually do, hour by hour, while the agent worked from it? Mostly, I was the credential boundary. The foreman would print a command that needed my account and my browser, a sign-in, an authorization for a new scope, a consent screen, and I'd run it. Then a small judgment call: yes, activate the site; no, not that scope. Then nothing for a long stretch while the workers ran. These runs go for hours. The human's recurring job is to be available for the moment the agent hits a wall it can't pass alone, and to answer in one line when it does. Everything after the sign-in is the agent's.

2:48Nudge, don't take over; the load-bearing forks

Until it gets stuck. And it does. When that happened, I learned not to take the keyboard. I'd interrupt its line of thinking with one alternative. What if you went in through this other tool instead? Then let it work. Problems are mostly the agent's to solve. Mine is course correction. And the agent learned its side of that too: it came to me at the true forks. What's easy versus what's right. What's hard versus what won't work. The decisions that, as the tool itself puts it, are load-bearing. That's the judgment layer, and you tune the agent so it knows which decisions belong there.

3:32Challenge done; ask about the quiet task

Between the forks, two habits did most of the work. The first is to challenge done. The agent reports completion against its plan. You check completion against the goal. I asked whether the site's database integration was finished, it said yes, I asked it to look again, and there was more. That's not the agent being wrong. That's domain knowledge: knowing what should exist and asking. The second habit: a task that's been running quietly for an hour is one of three things. Stuck, dead, or waiting on you. Twice a task that looked busy was waiting on standard input that would never come, and once it was waiting for me to sign in somewhere. You don't find that out by being patient. You find out by asking.

4:20Inspect what you expect

Which brings me to the biggest habit of all, and I'll say it plainly: inspect what you expect. Ask the planning agent how far along you are, and then go look yourself. Open the site. Open the mailbox. Open the chat rooms and watch the messages flow. The first mismatch is where you start asking questions. Ours was a big one. I asked which room my agents were gathered in, because the plan had them running on a named framework, and I wanted to go talk to them. The answer was that no such room existed. A worker, sessions earlier, had quietly written its own stand-in for the component the plan named, and every session since had built on top of it. Nothing was on fire. Everything was wrong in a way no log would tell you. Touching the real thing told me in one question.

5:16Take the crutches out; move the work

That story ends well, but only because we caught it before production. Two more things have to happen before that line. First, take the crutches out. To get proofs to pass, the agent had leaned on throwaway sandboxes and temporary scripts standing in for real processes. Good for testing. Not for a system that has to run on its own for months. Removing the scaffolding has to be its own explicit step, or it ships. Second, move the work. Early on the show rendered on my laptop under the agent, which is fine while I'm sitting there directing. Automating meant putting that work on the machine in the cloud so it happens when nobody is at the console. A local proof is not a deployment. The move from runs when I'm here to runs without me is a step you have to name.

6:12Overnight, and the tax on parallelism

Then there's the part where you're not there at all. One night I left the foreman running with a single sentence: I'll be back in the morning, make smart decisions in my absence. That gives it leeway, but it's still on a leash, still asking when a real opinion is needed. By morning the crash loops were fixed and mail was flowing. And when I was there, I multitasked: background the long task, run the admin work in a second window, throw more workers at independent problems. Parallelism buys speed. But workers make choices you didn't intend. Inspection is the tax you pay to keep the speed.

7:00The record

What makes all that inspection possible, and all the stopping and starting, is that everything got written down. Tasks to do, tasks done, a log per session, a result file per phase. So I could stop in the middle, come back two days later, and pick up exactly where I left off. Better: I could ask the agents for a summary, and they'd read their own logs back to me and give me a status good enough to decide the next direction from. Make the agents write the record. Then make them read it back to you.

7:37Close

So that's the job during the build. Once it runs, it changes again: captain of the ship. The big directional calls are mine. The day-to-day is the system's. If we'd done this by hand it would have taken certified cloud architects and a lot of their hours. Instead the agent brought the cloud knowledge, and I brought what I knew about what should exist and what done has to mean. The keyboard isn't the seat anymore. Judgment is. Whatever you know how to run, that's your seat. Take it.