Once more than one Codex task was running at a time, I could no longer answer basic questions from the conversations themselves. Which of these is finished? Which is waiting on me? Was that fix actually applied, and where does the decision live?
The problem was not that the model was not smart enough. It was that the current state of each task lived inside chat threads, and chat threads are a terrible place to look something up.
So I built a private admin screen, Task Control Room, and made it the single source of truth for tasks. This is a record of what I moved into one place, what I deliberately kept out of it, and the two things I tried that made the operation worse.
Originally published in Japanese on July 29, 2026. This English version was written in September 2026.
Chat threads record process well and state badly
A Codex conversation carries everything needed to follow one job: the request, the investigation, the intermediate decisions, the failures, the fixes, the completion report. For reconstructing how something happened, that is genuinely useful.
What a conversation cannot do is list what to prioritize right now. Three jobs means three threads. Handing work to a different role adds the destination thread. Once articles waiting to publish, changes waiting for review, and calls waiting on an external service are mixed together, picking out only the unfinished items becomes its own task.
My first attempt was to write the next action at the end of each thread. In practice, each time the next action was updated, the older completion reports and stale assumptions stayed there too. Working out which statement was still valid meant reading the thread again.
The work was delegated to AI, and the human was patrolling conversations to reassemble the state. That was the first sign something was wrong.
More notes did not decide where the truth lived
Next I pushed state into Obsidian daily notes and Markdown task lists. Easier to scan than a conversation, and the previous day carries over. I still use Markdown for specifications and for recording why a decision was made.
For task state, duplication broke it. The same job existed in the conversation, the daily note, the article candidate list, and the repository docs. Marking one DONE left the others open. Automating the morning handoff carried stale state forward into the next day.
There was no shortage of information. There was too much information carrying the same meaning.
So I split things by purpose. Anything with a fixed date and time goes in the calendar. The actual work and discussion happen in Codex. Specifications, reasoning, and verification results go in repository docs. Tasks, priority, owner, blocked state, and completion live only in Task Control Room.
Obsidian came out of the task path entirely, and the old lists are no longer updated. The fix was not more synchronization. It was fewer places claiming to be authoritative.
One board, four columns
Task Control Room is a private screen I built for my own operation. It is not a Codex or OpenAI feature. Codex is the side that executes work; Task Control Room is the side that decides what gets executed and what is blocked.
- P0 — moving today
- P1 — moving next
- WAIT — waiting on my decision, another role, or an external system
- DONE — finished today
Deciding not to grow it mattered as much as building it. DONE is not a permanent achievement log; it is a place to confirm what closed today. Completion records and publication results go to the docs that need them, and the board returns to the current decision.
After this, the instructions I give an agent got shorter. Instead of “read the whole conversation and work out what is next,” a session can start from “confirm the current state and completion condition of this task.” The model did not improve. The volume of stale assumptions it had to read did.
Cards carry routing, not the work itself
Save everything onto a card and Task Control Room becomes another long conversation log. That is the same failure in a new place.
A card holds a title, owner, priority, due date, state, a short note, and subtasks. The note carries the reason for a decision and the next action, not the full work log. Subtasks exist to break a completion condition into smaller ones.
For an article, that means splitting outline, body, and pre-publication QA, so it is visible where the work is stuck rather than just “write the article” sitting there. The draft and the verification record do not get copied onto the card; those live in docs, and publication state lives in WordPress.
The point was never to put everything in one database. It was to avoid creating a second authoritative copy of the same fact.
The roster view is not process monitoring
With more tasks running, I wanted to see who was working. So I added a Company view listing the AI roles by function.
It does not monitor real processes. It does not show token usage or what is being generated at this instant. An agent doing ordinary work reports a small piece of metadata only when its state changes: started, waiting, finished.
If no new report arrives within a set interval, the entry falls back to “awaiting observation.” A stale working is never displayed as if it were still live. The view is an aid for seeing owners and recent state, not an accurate picture of throughput.
Finer-grained visibility is not automatically more accurate. If observing costs you new work, the management layer becomes heavier than the thing being managed.
Failure one: a heartbeat job that generated its own workload
To keep the Company view fresh, I first ran a scheduled job that polled each agent for liveness. The check itself created new Codex tasks, duplicate checks piled up, and it consumed usage. A screen meant to reduce work was manufacturing observation work.
Even with tasks broken small, long-running work runs into Codex usage limits. I wrote up the reset behavior and my own measurements separately, in the record of Codex rate limits and the 30-day window.
Worse, a periodic check only ever tells you the last observed state. From the outside you cannot reliably distinguish “long job still running” from “job finished, report is stale.”
I dropped the approach. No heartbeat, no polling task: the agent already doing the work reports only when its own state changes.
Initially those reports went through a logged-in Chrome session, but depending on a browser connection meant keeping a screen alive purely for a status display. Now a shared local helper posts metadata alone to an owner-only API. No credentials are exposed to the agent, no browser is opened, and no other role’s state is touched. The monitoring did not get more capable; the reporting path got small enough that failing it does not stop the real work.
Failure two: approving everything made me the bottleneck
The second mistake was inserting approval into every agent operation. It looks safer when a human confirms each step. In practice, stopping on every state change, reorder, and note update turns the human into someone who processes approval notifications. Every task delegated added confirmation work.
I split operations into three tiers instead.
- Green — state updates inside a pre-agreed scope, and idempotent updates to the same task
- Amber — multiple changes, or pre-publication copy: reviewed once, as a batched diff
- Red — publishing, deleting, authentication, spending, revenue settings: explicit human decision required
This is not a classification for automating everything. It narrows what a human looks at down to exceptions and high-risk operations. Normal updates leave a record only; conflicts, failures, blocked items, and out-of-scope attempts are made prominent. Approval started working as a safety device rather than a queue.
Five fields are enough to start
You do not need to build the same screen. What my operation actually required was five things.
- Task — what is being finished
- Owner — which human, agent, or reviewer holds it
- State — in progress, waiting, or done
- Evidence — what confirms the decision or the completion
- Next action — who does what next
A spreadsheet or a small board will do. What matters is ending the state where you have to search conversations to find out where something stands.
And once you pick the authoritative place, resist syncing it into other lists. Keep schedule, work, specification, and task separate, and give the agent only the current state plus the evidence that particular job needs.
Build the surface the agents stand on first
When I started giving Codex more work, I thought about model capability and prompt wording first. Running several agents inside an actual business surfaces a different set of questions: which item advances, what is being waited on, who confirms it, and what evidence closes it.
Split those across conversations and a capable model still gets lost — and the human ends up patrolling threads to rebuild the state by hand.
Task management for AI work needs an authoritative record that is not the conversation. Not just more capable agents, but an operating surface that keeps them from dragging stale assumptions into current work.
Related
- What Codex’s banked rate limit reset actually does
- Routing GPT-5.6 Sol, Terra, and Luna across 66 production runs