Steer or dispatch: the two modes of working with agents

A debate between two coding tools contains one of the clearest frameworks yet for how any knowledge worker should think about agents. The question is not which AI is smarter. The question is whether you are steering, or dispatching.

This is not a developer argument

Nate, who documents AI workflows for a large audience, recently compared Claude Code and Codex: the two dominant coding agents in use right now. His framing is worth reading past the software context.

His argument is that Claude makes steering agents feel natural, and Codex makes dispatching agents feel natural. His label for what this builds over time is agent literacy. Not prompting. Not prompt engineering. Literacy: the ability to run agents that get work done, with results you can inspect and trust.

The framing matters because it applies everywhere, not just to software. A chatbot answers. An agent takes a job. That distinction, and what it demands from the person managing the agent, is what the debate is actually about.

Two modes

Steering means staying close to the work. You guide the agent as the problem takes shape. You correct it, push back, ask it to rethink. You bring a half-formed question and work it out together. Good for design, strategy, architecture, writing: anything where the problem itself is not yet clear.

Dispatching means writing the assignment and sending it off. You define the goal, the tools available, and what done looks like. The agent works. You check the receipts. For dispatching to work well, the problem has to be specified clearly enough that the agent can act without constant guidance. In return, you get parallelism: two or three jobs running while you work on something else.

Both modes require judgment. Both require proof. Neither is set-and-forget.

The point Nate makes: most people have only ever worked in one mode. They talk to the AI the way they would talk to a colleague. Question, answer, question, answer. That is not agent work. That is a chat. Agents take a job and come back with something you can inspect.

The receipt is the whole point

One of the most useful lines from the video: he does not trust the agent because it sounds confident. He trusts the receipts. The files. The logs. The comparison table. The rendered document. No receipt, no done.

This is where most teams get stuck. They see a polished output and assume the work is complete. But the agent may have optimised for completeness instead of quality. It may have followed the instruction too literally. It may have used the wrong source. It may have created a pile of work that takes longer to review than it would have taken to do the task manually.

The answer is not to trust the agent less. The answer is to define, upfront, what proof looks like. Not just "produce a report," but: produce a report, link every claim to a source, flag any data gaps, include the raw input you used. If the assignment is written well, reviewing the receipt takes sixty seconds.

What your operations team is sitting on

Most back-office work is dispatchable. Your team does not need to be close to every PIM update, every returns reconciliation, every supplier communication. The problem is well-specified. The input is known. The output is known. The rules, once written down, are clear.

What is missing is the assignment layer. Someone has to define what done looks like for each process. Someone has to decide which tools the agent can use and which systems it cannot touch. Someone has to specify what the receipt should contain. That work, the work of turning a process into an assignable job, has not been done in most companies. Not because it is hard. Because it has never had to be done before.

Nate frames the skill of 2026 as agent literacy: the ability to write assignments that come back as inspectable work. That is correct. It is also learnable. But companies that move fastest start from a well-mapped operational layer, not a blank prompt window.

What this means in practice

Building the dispatch layer is the work. Map the process, write the assignment, define what the receipt should contain, and take operational responsibility with an SLA. The client does not buy the conversation. The client buys the outcome, with proof attached.

The debate about which coding tool is better is worth following even if you will never write a line of code. The habits showing up in software first are coming for every knowledge workflow next. Understanding the difference between steering and dispatching is not optional.