I think I found my favourite way of working with agents today.

It happened while I was using the new voice experience in Codex.

I had an agent doing the work in one thread. I was talking to another agent about what was happening: what had failed, what the logs said, whether the working thread had stopped, what we might try next and whether somebody needed to give it a nudge.

And suddenly it clicked.

The working agent and the agent I talk to are not always the same job.

One is inside the work. The other is beside me, helping me understand and steer it.

That combination is brilliant.

The voice became my technical project lead

The useful conversation was not, "Write this function for me." Another thread was already doing that.

It was:

  • What just happened?
  • Why did that thread stop?
  • Can you look at the logs?
  • What is the team trying now?
  • Does that explanation actually make sense?
  • Can you keep an eye on it?
  • If it has stalled, can you help it recover?

That is not quite a programmer. It is not quite a project manager either.

For me, it is closer to a technical business analyst or technical project lead: somebody who understands the objective, can see the work, can translate the technical detail and can challenge the route without pretending to own every decision.

OpenAI's current Voice documentation already describes the foundations of this pattern. Voice can start separate threads for longer work, check existing threads, send follow-up instructions and bring progress, blockers and results back into the conversation.

That is the clever bit. Voice is not only a different way to type. It can become the human coordination surface for parallel agentic work.

It is a rubber duck that can fetch the logs

Developers have used rubber duck debugging for years. You explain the problem to somebody, or literally to a rubber duck, and the act of explaining forces you to make the hidden assumptions visible.

The voice agent creates the same effect, but with a rather useful upgrade.

The duck can answer.

It can ask what you meant. It can inspect the thread. It can find the failed command. It can read the logs and tell you that the problem you thought you had is not, in fact, the problem you have.

Sometimes I ask it to explain what went wrong and hear the answer halfway through. I go, "Oh. Yes. I see it now."

Sometimes the agent hears its own explanation, looks again and changes its view.

The value is in the pause. Work stops being an opaque stream of commands and becomes a conversation about evidence, assumptions and the next sensible move.

But I do not want one voice

This is where my request begins.

I normally have four or five projects moving at once. Some tasks take half an hour. Some are waiting for a build, a test, a server response or another agent. I cannot sit staring at one thread while every other piece of work politely waits its turn.

Codex already gives us parallel threads. Voice can already coordinate work across them. But the voice conversation still feels like one person floating above the projects.

I want a voice attached to each thread.

When I open the Orchistra thread, I want the Orchistra voice lead there with the context of that project. When I move to Tonywood.org, I want that project's voice lead. When I move to a client project, I want a separate conversation with separate context, permissions and history.

I do not want to brief one global voice all over again. I do not want to end one conversation before I can speak to another. And I definitely do not want one shouted instruction to wake up every agent in the building.

I want project rooms.

A project-room model for thread-bound voice. A work agent builds, tests and investigates while a voice lead explains, challenges and coordinates. Six requested harness features are thread-bound voice, persistent project context, visibility of work and logs, the ability to explain and challenge, bounded recovery authority, and decision receipts.
One project room, two roles: the work agent does the work; the voice lead helps the human understand and steer it.

My request to harness developers

Here is what I would like Codex, and eventually every serious agent harness, to support.

  1. Bind voice to a thread. Let a task keep its own voice conversation and reconnect it automatically when I return.
  2. Keep the project context. The voice lead should know the objective, recent decisions, current blockers and what the working agents have actually done.
  3. Let it see the work. Give it a clear, permissioned view of plans, tool activity, tests, logs, diffs, approvals and terminal output.
  4. Let it explain and challenge. It should translate the technical state, ask whether the evidence supports the story and point out when the team may be running quickly in the wrong direction.
  5. Give it bounded recovery authority. With explicit permission, it should be able to nudge a stalled thread, request the missing evidence or propose a restart. Conversation must not silently become unlimited authority.
  6. Keep every room separate. Project context, audio, permissions and memory must not leak casually from one thread into another.
  7. Make listening visible. I should always know which project voice is active, which microphone is live and which thread will receive my words.
  8. Leave a receipt. After the conversation, record the decisions, instructions, unresolved questions and actions sent to the working thread.

The interface could be simple. Select a thread. Its voice becomes available. Speak. Move to another thread. Speak to that project's voice instead.

Perhaps only one listens at a time. That is sensible. I am not asking for five agents to talk over one another like a particularly badly chaired meeting.

I am asking for five persistent relationships that I can move between without destroying their context.

This is not just a voice feature

The obvious interpretation is that this is about audio.

I do not think it is.

It is about separating execution from explanation.

We already do this in human organisations. The engineer may be deep inside the incident. The technical lead keeps the wider picture, asks for the evidence, explains the trade-off and helps the decision-maker understand what matters.

Sometimes one person can do both jobs. Sometimes they cannot. Agentic systems should allow the roles to separate without losing the connection between them.

The voice lead should not invent a reassuring summary while the working thread is on fire. It needs the same observability we would expect from a competent human lead: current status, logs, evidence, decisions and clear uncertainty.

And it should remain accountable to the project's permissions. OpenAI's current documentation says Voice follows the same permissions as the tasks it directs. That principle should stay intact as the feature becomes more capable.

The harness becomes the room

This is another step in the harness becoming the operating layer for work.

The model is not the whole colleague. The harness gives it the thread, memory, tools, permissions, visibility, recovery route and relationship with the human.

Voice adds presence.

It lets me move from issuing instructions to working things through. It gives me a way to ask the slightly vague but important questions that do not fit neatly into a ticket:

What do you think is really happening here?

That question is often where the useful work starts.

I now miss this when I move back to a harness where I cannot have the same spoken relationship with the work. Once you have sat beside the agentic team and talked through what they are doing, going back to silent boxes feels rather limited.

Give every thread its own voice

So that is my request.

Do not give me one voice floating above all my work.

Give every serious thread a voice of its own: familiar with the project, able to see the work, careful with authority, ready to explain what happened and able to help me get the team moving again.

The work agents can keep building.

I would like somebody beside me who can tell me what on earth is going on.

Sources and notes

  • OpenAI: ChatGPT Voice in Chat, Work and Codex. Checked 25 August 2026. The documentation describes starting, checking and steering work in other threads, and states that Voice follows the permissions of the tasks it directs.
  • OpenAI: ChatGPT and Codex changelog. Checked 25 August 2026. The changelog records the July 2026 Voice release and Codex's parallel-thread and long-running-work capabilities.

The working pattern and product request in this article are my own experience and opinion. Product behaviour and availability can vary by plan, workspace settings and rollout status.