The biggest recent change in how I run AI work is unglamorous: I stopped being the courier between agents.
Giving agents roles already worked. A director thread for direction, an engineer thread for implementation, a tester thread for verification, a designer thread for UI, a document owner for what gets written down. What I was still doing by hand was the relay — reading the engineer’s report and pasting it to the tester, reading the tester’s findings and pasting them back, then returning the result to the director.
The work was being done by agents and the message-passing by a human. That part is now handled between threads.
One limit up front: this is what I observed in my own environment. The same tool surface is not guaranteed to be visible in every Codex environment, and I am not claiming it is a documented, universally available feature.
Originally published in Japanese on June 9, 2026. This English version was written in September 2026.
The human relay was the bottleneck
You can put specification discussion, implementation, testing, rework, and decisions into one long chat. For small jobs that is enough.
Scale it slightly and things bleed together. A direction discussion turns into implementation detail. An implementation report arrives with no test perspective. A test fails and it is unclear which premise to send back to the engineer.
Splitting by role fixes that. The next problem is immediate: who passes what to whom? I was doing it — director handoff to engineer, engineer’s completion report to tester, tester’s failures back to engineer, tester’s pass to director.
Dull, and consistently heavy. Worse, a human courier drops things: forgetting to state what is out of scope, omitting the verification condition, pasting a stale premise, sending to the wrong recipient. The bottleneck in an AI team stops being the AI and becomes the human’s copy-and-paste.
What thread-to-thread handoff changed
In an environment where the thread tool is available, role threads can message each other directly. In mine, I confirmed thread-management tools through tool_search and got handoffs working using send_message_to_thread. Again: my environment, at the time I checked.
What changes is not that there is a convenient send function. It is the shape of the flow. The engineer finishes and requests testing directly. The tester finds a failure and sends it back directly. The tester passes and reports to the director directly. The director concentrates on final judgment and on explaining the state to me.
The human leaves the forwarding job. Approval is still mine — whether it ships, where to stop, what is publishable. But I am no longer carrying every message between agents.
Role threads are persistent, not disposable
I do not treat Codex as one long chat. Each role is a continuing thread with its own accumulated context: director (goals, priorities, what is in and out of scope, decision history), engineer (implementation approach, diffs, verification, commit and push state), tester (expected values, reproduction steps, failure conditions, pass judgments), designer (UI friction, feel, alternatives), document owner (what gets recorded and what deliberately does not).
Not having to re-explain from zero is the difference from one-off agent calls.
Splitting is not always right. A small fix is faster in one thread, and over-splitting makes the operation heavier than the work. The split earns its keep when specification discussion, UI judgment, implementation, end-to-end verification, and rework are all in play at once.
A worked example, abstracted
The subject was a working-time input UI in a web app under development. No repository names, URLs, commit hashes, or thread IDs here — this is abstracted to what is safe to publish.
The initial proposal made elapsed working time a required field, with hours and minutes selected manually inside the form. Defensible as a specification, heavy on mobile. My own feedback was blunt: this is not stepper-like input, and the interaction is wrong.
So the designer thread reviewed the UI options — not “build an input field,” but: does it feel natural to touch on mobile, how does an empty state look, can only the people who want to enter it do so, and does cancelling leave the value intact?
The outcome was to make elapsed time optional. The normal screen shows something like “elapsed time / not entered / enter,” and a bottom sheet opens only when entering. Inside the sheet you manipulate a draft value; it is written back to the form only on submit; cancel or close preserves the original; and there is a route back to “not entered.”
The director consolidated that and handed off to the engineer. The engineer implemented it, including the display on the post-save detail and result screens. The tester verified. It reads like an ordinary development flow — the difference is that designer proposal, director decision, engineer implementation, tester verification, failure return, and pass report all moved between role threads, without me re-pasting each step.
Missing perspectives got picked up afterwards
Looking only at the input control would have been insufficient. The tester surfaced surrounding end-to-end concerns: day-level deletion, previous and next day navigation, the 24-hour boundary, future-dated cells, error display, the detail screen after saving, and reflection on the result screen.
Individually small, and not the kind of thing you can thin out if you care about shipping quality. Ask an agent for implementation only and this is exactly what gets skipped, because “built to spec” is a complete answer to the question that was asked.
A tester thread reads the result, checks it against expected values, names what is missing, and sends it back when needed. Not having to copy that round trip in full, every time, is where the time went.
This is not the same as subagents
Subagents are useful for temporary investigation, parallel checks, and a second opinion — called when needed, returning a result. That is a different shape from what I am describing.
Here the director thread stays the director. The engineer thread stays the engineer. The tester thread stays the tester. Prior decisions, prior failures, how far verification got, which areas are off limits, and where reports go — that information lives in the role’s own workspace.
The value is not summoning a clever agent on demand. It is having places that hold a role.
Convenient enough to be dangerous
Send to the wrong thread and a handoff lands in the wrong role. Send a stale premise and implementation proceeds on it. Send something confidential and it stays there.
So there are rules. First, check with tool_search whether the thread tool exists in this environment at all. Only then use it. If it is unavailable, return the reason plus a copy-pasteable handoff instead of failing silently.
A handoff states the scope, what to do, what not to do, the verification condition, where to report, and the current working baseline where relevant.
And a hard line on what never goes into a handoff or a published article: thread IDs, internal repository names, commit hashes, credentials, admin URLs, tokens, cookies, secrets, API request bodies, and anything that identifies a client or company.
Operations design comes before automation. Skip it and you have not built a convenient system, you have built a leaky one.
Roles beat one very capable assistant
The change was not the model getting smarter. It was the human stepping out of the relay: the director consolidates, the engineer implements, the tester verifies, failures go back, passes go forward.
One capable assistant is convenient. For anything larger, designing it as several agents with roles is easier to run. The thread tool is, for me, the practical component that makes that possible.
Still in progress, still environment-dependent, and I would not claim anyone can use it the same way. But in this environment, the human stopped being the courier, the agents relay the work, and I concentrate on the last decision.
References
This article separates what the official documentation describes about the Codex app, subagents, and skills from the thread-management tools I confirmed via tool_search in my own environment.