Draft status
This is a fork-local draft note. Do not open this upstream yet.
Revisit after Codex monitor support has settled as a first-class or at least stable feature. Until then, this issue is only a place to keep the idea and dogfood observations in the fork.
Motivation
For agent-to-agent work, an ongoing topic should ideally continue between the same agents/sessions whenever possible.
This matters for two reasons:
- Context quality: the receiving agent already understands the prior decisions, assumptions, and local terminology for that topic.
- Token cost: routing the same topic to a different agent often requires re-explaining background, rereading history, or summarizing prior turns.
Today this can be handled manually by remembering which agent owns which topic. That works for small cases, but it is easy to break once there are multiple agents, sessions, projects, or temporary dogfood agents.
Problem
A plain agent-to-agent message answers "who is this for?", but not "which ongoing conversation is this part of?".
If an agent reads broad team history to recover context, token use can grow quickly. If it only reads the latest isolated message, it may miss prior decisions and repeat earlier discussion.
Feature idea
Add a lightweight conversation line / topic thread concept.
A line would represent a continuing conversation around a short subject, for example:
- subject:
Windows monitor dogfood
- participants: a small set of agents
- state:
open, waiting, done, archived
- summary: compact current-state text
- messages linked to the line
Delivery should not inject the full line history by default. A monitor/turn delivery should usually include:
- the short subject
- the current line summary
- unread messages for that line
Full history would be fetched explicitly, e.g. last N messages or full archive only when needed.
Non-goals
- Not trying to recreate Slack channels.
- Not trying to make all team history visible by default.
- Not proposing a full implementation yet.
- Not proposing upstream changes until Codex monitor is stable enough to dogfood this safely.
Open questions
- Should this be first-class storage metadata, or only a message header convention at first?
- Should lines be strictly two-party, or allow a small participant set?
- How should line summaries be maintained: manual only, automatic, or hybrid?
- How should archived lines avoid accidental prompt injection?
- How does this interact with channels/broadcasts if those are added later?
Possible minimal local experiment
Start with a convention or fork-local wrapper:
line open <agent> "<short subject>"
line send <line_id> <agent> "<message>"
line status <line_id>
line history <line_id> --last 10
line close <line_id>
The important invariant is: save full messages if useful, but only inject compact line state plus unread messages by default.
Draft status
This is a fork-local draft note. Do not open this upstream yet.
Revisit after Codex monitor support has settled as a first-class or at least stable feature. Until then, this issue is only a place to keep the idea and dogfood observations in the fork.
Motivation
For agent-to-agent work, an ongoing topic should ideally continue between the same agents/sessions whenever possible.
This matters for two reasons:
Today this can be handled manually by remembering which agent owns which topic. That works for small cases, but it is easy to break once there are multiple agents, sessions, projects, or temporary dogfood agents.
Problem
A plain agent-to-agent message answers "who is this for?", but not "which ongoing conversation is this part of?".
If an agent reads broad team history to recover context, token use can grow quickly. If it only reads the latest isolated message, it may miss prior decisions and repeat earlier discussion.
Feature idea
Add a lightweight conversation line / topic thread concept.
A line would represent a continuing conversation around a short subject, for example:
Windows monitor dogfoodopen,waiting,done,archivedDelivery should not inject the full line history by default. A monitor/turn delivery should usually include:
Full history would be fetched explicitly, e.g. last N messages or full archive only when needed.
Non-goals
Open questions
Possible minimal local experiment
Start with a convention or fork-local wrapper:
The important invariant is: save full messages if useful, but only inject compact line state plus unread messages by default.