From chat to agents: becoming a manager of your work

Your team is good at Claude now. Someone pastes in a tangled function and gets it untangled. Someone gets the awkward client email written in two lines. Someone argues through an architecture decision at 11pm instead of waiting for standup. Chat is the first thing everyone reaches for, and it has made all of them faster.

Look closely at the days, though, and the shape of the work hasn't moved. Each person is still doing their own work from start to finish: reading every answer, choosing the next step, carrying the task to the end. Chat sped that up. It didn't hand any of it to someone else. Your people are still individual contributors, and they are still the ones on the hook for the how.

Agents are a different proposition, and most teams underrate how different. It isn't that the model got smarter; it's usually the same model. What changes is the size of what you hand over. To chat you hand a sentence and get a sentence back. To an agent you hand an outcome (make the failing tests pass, work through this backlog of tickets, turn this spec into a running endpoint), and it plans, does the work, checks itself, and comes back when it's done or stuck.

The moment you hand over an outcome, your own job moves. You stop specifying method (how to do it) and start specifying intent: what a good result looks like and why it matters. You're no longer the person doing the task; you're the person who decided it was worth doing and judges whether what came back clears the bar. Your team spent years getting good at the how. Agents are now good enough at the how that the scarce, valuable work is the why: what to build, why it matters, and what "done well" actually means. That is a manager's job, and most strong makers have never been asked to do it.

Chat advises, agents act

It's worth being precise about the difference, because "agent" is getting stuck on anything with an API key. A chatbot is synchronous: you ask, it answers, you decide what to ask next, and nothing happens when you step away. An agent runs its own loop (set a goal, make a plan, take an action, look at the result, go again) until it reaches the goal or gets stuck. What makes it more than a chatbot is that it can act: run code, edit files, hit your APIs, change real systems. With chat, you drive and it advises. With an agent, it drives and you steer. Everything hard about this transition comes from that one move: your attention leaves the middle of the task and goes to the two ends, the brief and the review.

One more thing sets an agent apart from a person you hand work to: it only knows what's in its context (the window of text it can see for this task), and that window is finite. It isn't holding last week's thread or the knowledge in your head; if something isn't in the window, for the agent it may as well not exist, and everything that is in there competes for its attention. So managing an agent includes managing that window: the right things in, the noise out.

Owning the why

Think about what separates a strong senior IC from a strong manager. The IC's value is in doing: they hold the problem and produce the answer. The manager's value is in getting a good result through other people: choosing what's worth doing, describing it well enough that someone else can run with it, reviewing what comes back, and knowing when to step in and when to leave it alone. They trade the satisfaction of doing the work for the leverage of multiplying it.

Working through agents needs that same skill set, pointed at a stranger team. The person who thrives is the one who can turn a fuzzy goal into a sharp brief, say plainly what "done" means, and judge output quickly and honestly. If you already have good managers, they know how to do this with people; the task is to apply the same instincts to agents that happen to be fast, tireless, literal, and confidently wrong just often enough to keep you on your toes.

The uncomfortable part is that the instinct which made someone a great IC (see the problem, jump in, fix it yourself) is the exact instinct they now have to hold back. The discipline is to state the intent and let go of the method.

What the job actually takes

Write briefs, not prompts. A prompt is a nudge you toss off in the moment, often still telling the model how to do it. A brief is what you'd hand a competent new hire, and it states your intent: what you want, why it matters, what "good" looks like, what's off-limits, and where the context lives. The brief carries the intent; the method is theirs to choose. The best predictor of a usable result is a clear brief. If you're explaining the same thing for the fifth time, that's onboarding material, so write it down once and point every agent at it. And size each ask to what you can actually check: the right chunk is the biggest one whose result you can still verify with confidence.

Reviewing is the job now, so get good at it fast. This is where most teams are weakest, and the whole model rests on it. Output nobody checked isn't finished work; it's unverified, and some of it will be wrong in ways that look completely fine until they aren't. Reviewing agent work is its own craft: reading a diff with suspicion, running the thing, spot-checking the claims, catching the answer that's plausible and subtly off. Keep a few real tasks you can rerun on demand, so "did that change help?" has an answer instead of a feeling. If your team treats review as the chore after the real work, they have the priorities inverted.

Hand out autonomy in proportion to the cost of being wrong. You don't give a new hire the production database on day one, and you don't let an agent merge to main on its first run. Start supervised: it proposes, a human signs off. As a particular kind of task earns its reputation, loosen the leash: approve in batches, then spot-check, then let it run and only surface the exceptions. Trust is earned per task type, not granted across the board. Anything expensive, irreversible, or customer-facing stays supervised longer than feels necessary.

Context is the work, not prompt-wording. An agent is only as good as what it can see. The highest-leverage thing you can do isn't wordsmithing the prompt; it's making sure the agent has the docs, examples, access, and tools a capable human would need for the task. Most "the AI is dumb" moments are really "I didn't give it what it needed" moments. Curating that context is now a real part of someone's job. And it cuts both ways: supplying what the agent needs is only half of it; the other half is keeping the clutter out. Brainstorming the spec with a chatbot to sharpen what you actually want is good practice, but do it in a separate session, then hand a fresh one only the distilled intent. The exploration got you there; the agent building from it shouldn't have to wade back through the whole conversation. A focused context beats a crowded one.

Stop thinking in one conversation. The moment you're managing outcomes, you're not limited to a single thread. Good managers don't run one report's task at a time; they keep several moving and go to whichever one needs them. That's the shift, from "my chat window" to a portfolio of work in flight, and it's where the leverage shows up. It also means prioritizing and switching context matter more than how fast anyone can type.

Put a human on anything you can't undo. Autonomy is a setting, not a personality. Some calls should never be fully handed off: spending real money, touching customer data, sending anything external, doing something you can't take back. Draw those lines on purpose and staff them.

Who takes to it, and who struggles

Be straight with your team about this, because it changes what their days are made of. The hours move from producing to directing: less time writing the solution, more time framing the problem, writing the brief, and deciding whether the result is any good. The skills that suddenly matter are clear writing, fast and honest review, breaking work into the right pieces, and taste. Deep technical judgment gets more important, not less. You can't review what you don't understand, and an agent will lead an unwary reviewer off a cliff with total confidence.

Roles will drift this way whether or not anyone plans for it. "Manager of agents" isn't a job posting; it's a mode most jobs are quietly sliding into. The people who take to it fastest are often the ones who already liked the managerial parts of the craft: mentoring, reviewing, designing the system rather than typing every line. The ones who struggle are sometimes your best ICs, because "I'll just do it myself, faster and better" was their whole edge, and that edge is exactly what's being automated. Say so out loud. It costs them something, and it's worth naming before it curdles into resentment.

The ways it goes wrong

• Delegating without reviewing. Handing off outcomes and rubber-stamping them. The model depends on the review being real; rubber-stamping is just slower failure.
• Under-briefing, then blaming the model. If a new hire would have asked three questions before starting, your brief was missing three answers.
• Letting autonomy creep onto the dangerous stuff because it's been fine so far. "It's been fine so far" is how most expensive incidents start.
• Using an agent as a slow search box. Some questions chat answers better and cheaper; spending an autonomous run on them is just for show.
• Steering by vibes. Changing your setup with no way to tell whether it got better or worse. Keep the eval tasks and trust them over the feeling.

Notice how few of these are technology problems. They're management problems, which is the good news, because those you already know how to fix.

Where to start

You don't roll this out with a memo. You build the muscle on one real thing and then widen. A shape that works for a small team:

1. Weeks 1–2: pick one bounded workflow. Something that matters, repeats, and won't hurt anyone if it goes sideways. Write down what "done" looks like before you start.
2. Weeks 2–4: write the context. Pull together the docs, examples, and access the agent needs. Run it fully supervised: it proposes, a human approves every time. Keep a log of every failure.
3. Weeks 4–8: build the review habit. Turn that failure log into sharper briefs and clearer guardrails. Let the reliable task types run with a lighter touch. Stand up a few eval tasks you can rerun.
4. Weeks 8–12: widen. Add a second workflow. Have one person practice running several agents at once. Watch which skills the team is short on, almost always briefing and reviewing, and invest there.

The point of the ninety days isn't to automate everything in sight. It's to teach the team to brief, to review, and to trust in measured steps, on work that matters but won't sink you if an agent gets it wrong.

Your team already knows how to use Claude; that part is mostly behind them. The shift still ahead is the one nobody put on a training plan: getting comfortable owning the why, meaning what's worth doing and whether it turned out any good, while the how increasingly takes care of itself. Better to start building that muscle now, on something small, while the stakes are low.