I have been noticing a change in how I work with AI agents. At first, I wanted to delegate as I would to a member of staff: explain the job, agree what a good result looks like and leave them to it.
That works rather well for some jobs. Give an agent twenty pages with a clear structure and a known template, and it can get on with the work. I can come back, check the pages and deal with the exceptions.
But my more complicated projects rarely work like that. We discover a connection nobody wrote down. A decision about one system affects another. If I hand over the whole thing and disappear, I can come back to a lot of work heading in the wrong direction.
So I am trying a different approach: do not just delegate to the agent. Work beside it.
The induction nobody gave it
Imagine a new person joining your team. You give them a brief. Then, over the following weeks and months, they learn the things you did not think to put in it. They ask a colleague which system has the current information. They find out why a process looks odd, who can make a decision and which old promise to a client still matters.
An agent does not automatically get that induction. It may have a repository, a document folder and access to a few tools. That is not the same as knowing how your organisation actually works. It cannot casually ask the person at the next desk unless you have given it a way to do so, with the right permissions and boundaries.
Of course we can improve this. We can write things down, connect systems, give agents useful memory and let them ask questions. But we often expect an agent to understand from one opening prompt what a new colleague might take months to learn.
We need to be honest about how much of that background we have actually given the agent.
Stay close enough to see the shape
On a complex project, I now spend a surprising amount of time saying, “Show me.”
Show me where that data lives. Show me the page you changed. Explain how these two pieces of code connect. Which system owns this field? What happens if this step fails? Draw the structure, or give me the files and a small diagram so I can draw it myself.
Those questions help me spot where the agent and I have understood things differently. They also help me understand the project I am responsible for. If neither of us can explain how it fits together, perhaps we should pause before making the next change.
I do not need to watch every keystroke. I need to agree when we will stop and check, and be able to see what has happened. A summary helps, but I still want to look at the actual page, file, test result or data behind it. When the agent says “done”, I want to see what it has done.
Not everything needs a conversation
I do not want to turn every little task into a committee meeting. If the task is clear, we have done similar work before and I know how to check the result, I am happy to delegate it. Those twenty structured pages are a good example.
The question is whether the agent is following a process we understand or helping me work out what the process should be. A long project involving several systems and people needs more discussion. Sometimes I need to stop adding tasks and draw it on a whiteboard.
I have been on one such project for months. Models and tools have changed while we have been working. Each new capability brings a tempting idea: we could do this part faster now. Perhaps we can. But first I need to see where it fits, what it replaces, and what we would have to check again. A better model does not remove the need to understand the project.
Focus is part of the job
This is also why I cannot always run five complicated threads at once. I can start them. That is easy. The harder bit is keeping the decisions, assumptions and unfinished questions straight in my head.
So I set aside time for one project. While the agent works through an agreed task, I might read a book, play a game or go outside for a bit. I can take a break without opening another complicated project every time there is a pause. Then I come back, still knowing where we were, and ask what changed.
I still use parallel work when the tasks really are independent. I just no longer treat an idle minute as a failure to optimise my day. This is the point I explored in Go Slower Than You Think You Need To. Here I am taking it one step further: the human is not only there to approve the answer at the end. Sometimes the human and the agent need to work out the question together.
A better brief for a changing project
When the work is uncertain, I would rather begin like this:
Help me understand where we are before changing anything. Show me the relevant files, systems and decisions. Tell me what you know, what you are assuming and what you need to ask. Suggest one manageable next step and where we should stop to review it. Then show me what changed and how you checked that it worked. Ask me before deploying, publishing or contacting anyone.
The wording matters less than the conversation it starts. We need to agree what the agent can do, when it should stop and what I will check. Its access settings need to match that agreement, and I need to read what comes back.
I would love to make this more visual. I use a physical whiteboard because it lets me point at a connection and ask, “Hang on, why does that go there?” For now, a photo of the board and a discussion with the agent will do. One day perhaps the goggles and shared drawing space will catch up with the way we actually think together.
Until then, my question is simple: can I still see the work clearly enough to steer it? If yes, let the agent move quickly. If no, slow down, ask it to show you, and get back alongside it.
Related: Give Every Codex Thread Its Own Voice.