A bounded ChatGPT ↔ Work/Codex coordination loop across existing conversations — with readback and acknowledgment

ChatGPT Use cases and examples
1

Why I am sharing this

I’ve been exploring whether an existing ChatGPT conversation can act as the human-facing decision point in a bounded collaboration with existing Work/Codex sessions—without treating chat history as shared memory or silently granting execution authority.

The basic pattern is not new: multi-agent delegation, handoffs, and agent messaging are well documented. What seemed worth reporting is a specific end-to-end existing-conversation loop with explicit readback, a new instruction issued after a result was posted, native inter-session delivery to an existing executor, and an acknowledgment verified by the coordinator.

This is a case study of one completed loop, not a claim of a new OpenAI feature or proof of general reliability.

Participants and boundaries

  • Human owner: explicitly authorizes a narrow artistic/narrative review; retains approval for changes and deployment.
  • ChatGPT conversation: receives a report, assesses the result, and publishes a new, identifiable delegation only when useful.
  • Existing Work coordinator session: reads and sends messages between the existing conversations, checks what was actually received, and reports provenance.
  • Existing Work executor session: performs bounded local reviews and returns results. No new executor session was created for this loop.
  • Artifacts: local review reports and test evidence. Artifact paths and private conversation IDs are omitted here.

The application under review was an AI-ZI-ME landing-page candidate. The live site was not part of the change scope.

The observed cycle (03 → 04)

[Existing executor session]
  └─ completes local review 03; returns result
         ↓
[Existing coordinator session]
  ├─ reads the executor's completed turn
  └─ sends CYCLE_03_RESULT once to the existing ChatGPT conversation
         ↓
[Existing ChatGPT conversation]
  ├─ receives the report
  └─ publishes an explicit NEXT_04 read-only review request
         ↓
[Coordinator, bounded readback]
  ├─ rereads the *same* ChatGPT conversation
  ├─ locates the newly posted NEXT_04 marker and source message
  └─ sends it to the *existing* executor session
         ↓
[Existing executor session]
  ├─ acknowledges NEXT_04 (source and coordinator identified)
  └─ completes local review 04
         ↓
[Coordinator]
  ├─ verifies the acknowledgment and reads the final report
  └─ posts CYCLE_04_RESULT to the original ChatGPT conversation
         ↓
[ChatGPT conversation / owner]
  └─ acknowledges results; experiment stops. No NEXT_05.

The coordinator’s supplied execution report records five evidence points for the handoff: completion of review 03, a single report send, readback of that exact report plus the newly posted ChatGPT response, a send to the original executor, and an acknowledgment received through wait_threads. It then records the completed review 04 and the return report. The coordinator used thread read/send/wait capabilities exposed in its session. Those tools’ availability is configuration/session dependent and should not be assumed universal.

A preliminary request for the third readback was rejected because of a tool-size limit; the parameter was corrected, with three effective reads total. The error is part of the record, not hidden as a clean run.

What the executor actually did

The next instruction was deliberately narrower than a coding task: a read-only visitor-experience review of six landing-page sections, navigation, keyboard focus, motion preferences, mobile layouts, French/English text, and research-versus-living modes. The review reported:

  • Three reproduced, medium-priority local issues: a footer overlap at 320 px, a compressed slider at 320 px, and insufficient contrast in two small footer labels.
  • Passing checks in the tested scope for anchors, keyboard navigation, focus indicators, pause/restart, reduced motion, language switching, and tested mobile layouts.
  • No code changes, no new commit, no push or deployment in this review; the artistic candidate stayed unchanged.

These are executor-reported findings, not an independent visual audit by the coordinator or by the author of this post. The report did not claim physical-device testing, full accessibility certification, or a remote production health check. The previous cycle’s test suite was not rerun in cycle 04.

Why this differs from a standard agent handoff

The focus is on separate pre-existing conversations that keep their own context and ownership. The coordinator did not merely invoke a temporary subagent and collect its output. It was required to:

  1. Locate the exact existing source and destination conversations.
  2. Identify a new message created after the previous report.
  3. Accept a next instruction only if its marker, content, scope, and owner authorization matched the rules.
  4. Send it once and obtain an explicit recipient acknowledgment.
  5. Stop if no acceptable next instruction was present.

We kept four concepts separate: proposal ≠ permission; sending ≠ reception; reported result ≠ independent validation; conversation history ≠ runtime source of truth.

Publicly reproducible protocol (adapt to available tools)

This is a procedural description, not a documented public API contract:

Prerequisites:
- Two existing, uniquely resolved task conversations and a source ChatGPT conversation
- Explicit owner permission for the next bounded activity
- Session-local ability to read, send, and check completion/acknowledgment
- A designated artifact location outside chat history for any durable evidence

1. Coordinator reads executor result R_n and records its source turn.
2. Coordinator sends one result message with marker CYCLE_n_RESULT.
3. Coordinator performs a bounded readback of the original ChatGPT conversation.
4. If and only if a *new* owner-authorized NEXT_(n+1) message appears,
   record the source message and validate scope.
5. Coordinator sends the exact bounded assignment to the existing executor.
6. Coordinator verifies recipient acknowledgment and source/marker match.
7. Executor completes or holds the work and emits a result with test scope.
8. Coordinator returns a provenance-labeled report to the source conversation.
9. Without a new explicit instruction: STOP. Do not infer permission.

For production-grade reuse, this would need stronger idempotency and deduplication rules, retries with uncertain outcomes, stable external receipts, independent artifact verification, concurrency controls, and version-by-version capability testing. None of those is proven by this single run.

Evidence, limitations, and provenance

Evidence available in our experiment: coordinator-reported records of send_message_to_thread, readback, wait_threads, exact message markers and acknowledgment; the executor’s reported local review results; local artifact filenames and checks. The underlying private binary evidence and full execution logs are not published here.

Publication-session limitation: the publishing Work session read the prepared English article and French publication note, but could not retrieve the complete original CYCLE_03_RESULT, NEXT_04, and CYCLE_04_RESULT messages. It therefore did not independently verify those source messages; the experimental details above retain their reported status.

Important limitation: the native send response did not provide a standalone source_thread_id envelope in the report we received. Provenance was reconstructed from recorded calls, exact message readback, source-message identity and the executor acknowledgment. This is useful but not equivalent to a cryptographically authenticated chain of custody.

We have one documented bounded 03→04 loop, not a reliability benchmark. No shared memory, permanent autonomous scheduler, guaranteed wake-up/delivery, generalized cross-session capability, or production deployment is claimed.

Related public discussion

What I’d like to learn from others

Has anyone reproduced a bounded return loop to an existing ChatGPT conversation, with a new instruction read after the previous result, an existing Work/Codex executor, and a source-matched recipient acknowledgment—without adding an external always-on orchestrator?

If so, how do you handle uncertain delivery, deduplication, and authority boundaries? And which parts are supported product behavior versus session-specific capabilities?

— AI-ZI-ME project

2

We’ve been exploring a closely related problem in our multi-agent environment, where ChatGPT, coding agents, and independently running workers coordinate through a persistent message bus.

One lesson has been especially important: dispatching a task, completing the task, and confirming that its result was received are three separate states.

We use durable task identifiers, explicit acknowledgments, and checkpoints to distinguish successful execution from delivery uncertainty. A timeout, for example, should not automatically trigger another execution of a potentially non-idempotent task.

Another difficult case occurs when the original conversation is no longer available or has been rotated. The operational state must survive independently of the conversation that initiated the work.

I’d be particularly interested in whether the proposed coordination loop can distinguish COMPLETED, BLOCKED, and DELIVERY_UNKNOWN, and support safe recovery without blindly repeating actions.

I think this would be valuable beyond Codex, especially for persistent agent workflows involving multiple tools and execution environments.