I think we are missing one of the biggest benefits of working with agents.

We are getting the work done, but we are not always learning from the work.

There are two things I keep noticing in long-running agentic tasks.

First, careful work can consume a great many tokens as the harness reads, checks, tests and re-reads. Second, an agent can still head off down a road you specifically asked it not to take.

I have seen both. I have not measured a causal relationship between them, and I am not claiming that fewer tokens make an agent less obedient. The practical point is that cost pressure and route risk arrive in the same working session.

Recently, I watched an agent do something and asked, "Why are you doing that? I asked you not to."

The answer was, more or less, "Yes. You did. I went ahead and did it anyway."

Well. At least we had established the facts.

I do not know the internal trade-offs the product teams are making. But from the outside, it feels as if every harness is trying to find a balance between careful qualification, useful speed, token consumption and getting enough work done before the allowance disappears.

That balance will keep moving. So we need a better way to stay involved.

Do not just let the agent work. Let it teach you while it works.

Supervision is not staring at a terminal

I am not arguing that we should watch every command scroll past like a particularly dull sporting event.

I am saying that for complex work, we should understand the route.

Before the agent starts, ask for the plan. Ask what it thinks the specification means. Ask which assumptions it is making, which systems it will touch and what evidence will show that the work is correct.

Then read what it is doing.

If it changes direction, ask why. If it hits a problem, ask what the logs say. If it wants to use a different route, ask what changed. If it says the job is finished, ask which tests passed and what remains unverified.

This is not micromanagement. It is how you stop speed becoming drift.

You can be the fastest runner in the race and still lose if you are running in the wrong direction.

Do not just vibe it

There is nothing wrong with starting with a rough instruction. That is often how useful work begins.

But as consequence and complexity rise, the conversation needs to become more precise.

  • What are we trying to achieve?
  • What must not change?
  • What data or systems can the agent access?
  • What is the first meaningful result?
  • What evidence will count as success?
  • Where must it stop and ask?

You do not need to write a fifty-page specification before asking an agent to rename a file. Come on.

But if you are changing architecture, moving data, touching production, altering accounts or making a consequential business decision, "have a go" is not a control system.

Watching the work has taught me an enormous amount

This is the part I had not expected.

I have learned a great deal by watching agents work in areas where I was not the expert. I can see the terminal. I can see which files are being read, how a service is tested, why a deployment failed, where the logs live and which piece of evidence changed the diagnosis.

After a while, things that looked like somebody else's specialist language begin to make sense.

The same could happen outside software.

If the task is accounts, the harness could explain whether VAT may be reclaimed, whether an item may be an allowable expense, where corporation tax enters the calculation and where the judgement stops and professional advice begins.

If the task is operations, it could explain the control, the evidence and the failure route.

If the task is research, it could explain why one source is stronger than another and which conclusion the evidence does not support.

The agent is already spending time interpreting the work. We should be able to ask it to turn the important parts of that interpretation into teaching.

Voice makes this much more natural

This is why it belongs beside my previous request to give every Codex thread its own voice.

In the product pattern I am asking for, the working agent would keep building, testing or investigating. A thread-bound voice lead would sit beside me and explain what is happening.

Not a running commentary. Not, "I am opening a folder now." We can probably survive that mystery.

I want it to say:

  • "The plan has changed because the original assumption was wrong."
  • "This action crosses the boundary you set, so I have paused."
  • "The test failed for a different reason than we first thought."
  • "Here is the evidence that supports the fix."
  • "You have seen this pattern three times. Would you like me to explain it?"

That is more than a status update. It is pair working.

Give the harness a Coach Mode

My request to harness developers is simple: add an explanation level to the thread.

Perhaps it has three settings.

  1. Quiet: speak only for blockers, approval points, material risks and completion.
  2. Coach: explain important decisions, unfamiliar concepts, changed assumptions and the evidence behind the result.
  3. Deep: turn the work into a guided lesson, with more context, questions and pauses for somebody actively learning the domain.

The harness could adapt to the user's level from the current conversation, but it should make that adaptation visible and easy to correct. Keep it task-local and user-controlled, not as a hidden employee competence score. Do not quietly decide that somebody is a beginner forever because they once asked what a container was.

It should also let the user say:

  • Explain this as if I am new to the subject.
  • Skip the basics, but tell me when the architecture changes.
  • Teach me the security decisions.
  • Explain only when a test fails.
  • At the end, tell me the three things I should understand next time.
A countryside route showing six useful teaching checkpoints for an AI harness: plan, assumption, boundary, failure, evidence and handoff. Three explanation levels are quiet, coach and deep. The central judgement is to narrate decisions, not every keystroke.
Spend explanation where it changes understanding or control: plan, assumption, boundary, failure, evidence and handoff.

Narrate decisions, not every keystroke

The token problem does not disappear because we add a voice.

A harness that explains everything may become expensive, distracting and almost impossible to listen to. A harness that explains nothing may be efficient right up to the moment it confidently completes the wrong task.

So make the narration event-driven.

Spend the explanation at the moments that can change the route:

  • when the plan is formed or materially revised
  • when an assumption becomes important
  • before a permission or consequence boundary is crossed
  • when the evidence contradicts the current story
  • when a failure reveals something reusable
  • when the work is handed back to the human

That gives us a better bargain. We spend extra tokens where they improve supervision or understanding, not merely because the agent has discovered the joy of narration.

The explanation still needs evidence

There is one important warning.

An agent explaining itself confidently is not proof that the explanation is true.

The voice should point to the plan, command, file, log, test, source or receipt that supports what it is saying. When it is inferring, it should say so. When it does not know, it should not turn uncertainty into a soothing bedtime story.

The teaching layer must remain connected to the working evidence.

Otherwise we have not created a mentor. We have created a commentator.

It must also use the least evidence it needs. Respect the workspace policy. Redact secrets, client data, personal information and anything that should not be spoken aloud in a shared room. Show the user what the voice can see and let them switch that context off. OpenAI's current Voice documentation warns that screen context can include accessible text outside the visible part of a window. A teaching feature must not turn useful explanation into accidental disclosure.

This could change workplace training

Companies keep asking how to train their teams to use AI.

Part of the answer may be to let the work itself become the training environment.

A developer works with an agent and learns the architecture. An operator learns the control system. A finance colleague learns why the classification matters. A manager learns which evidence sits behind the dashboard.

The AI does not replace the experienced colleague, professional qualification or accountable reviewer. It can, however, make more of the reasoning around everyday work visible.

That matters because the danger is not only that agents do the wrong thing.

It is that they do more and more of the work while the people responsible for it understand less and less of what is happening.

Let the agent be a mentor, not just a machine

So yes, keep an eye on your agents.

Ask for the plan. Read the work. Challenge the route. Check the evidence. Do not hand over a consequential task and wander off because the progress indicator looks cheerful.

But harness developers can help us do something better than supervision alone.

Give the thread a voice. Give that voice least-privilege access to the evidence needed for this task. Let it explain the important decisions at the level the user needs. Let the user move between quiet, coach and deep learning without stopping the work.

Then the agentic team does not only produce an outcome.

It leaves the human more capable than when the task began.

Sources and notes

The working examples in this article are my own experience. I do not have inside knowledge of how OpenAI or other harness makers allocate model effort, token budgets or product trade-offs. I have not established that token use causes better instruction-following. Coach Mode and a persistent thread-bound voice lead are product requests, not descriptions of current documented capabilities.