Roundtable — OpenAI Edition

One real Codex GPT-5.6 seat, one clearly labelled mock critic, and a human-controlled path from deliberation to action.

Comment

Judge fast path

Watch the 2:30 demo, then run npm run demo:buildweek from the exact repository branch. The command visibly prints [LIVE CODEX GPT-5.6] Advisor, [MOCK SEAT] Critic, and a convergence-card header naming [LIVE CODEX GPT-5.6] Lead; it exits non-zero if that complete, labelled topology cannot be produced. The deterministic mock command and full verification commands are listed below for reviewers without local Codex authentication.

Inspiration

Roundtable began with a simple idea: a useful AI collaborator should behave more like a well-run review meeting than a single confident chatbot. Different seats should contribute visible perspectives, a lead should synthesize without erasing disagreement, and the human should remain the final authority over execution. For Build Week, we focused on making one narrow live path real, inspectable, and honestly labelled.

What it does

The Build Week command runs a small local roundtable:

  1. One real local Codex GPT-5.6 integration contributes as [LIVE CODEX GPT-5.6] Advisor.
  2. One deterministic counterpoint appears as [MOCK SEAT] Critic, visibly labelled as mock.
  3. The same real Codex provider is called again, serially, as [LIVE CODEX GPT-5.6] Lead.
  4. The Lead produces a convergence card with exactly four fields: Conclusion, Consensus, Disagreements, and Next Steps.

This is one real Codex provider used in two serial roles, not two independent live models. Live mode fails closed: if the Advisor, Mock Critic, or Lead does not complete, or if the round becomes single-source, the command exits non-zero instead of presenting the fallback as a successful live demo.

Roundtable also contains an existing governed action path. Structured action proposals become reviewable action cards, and interactive write or danger actions wait for human approval. The Build Week Codex extension itself is text-only and does not autonomously edit files or execute actions.

How we built it

Roundtable is a local Node.js/Electron project with a shared orchestration core and a CLI host. The July 21 extension implements the existing seven-method SeatDriver contract with an opt-in local Codex process.

The integration sends the dynamic prompt through standard input, never through shell interpolation or process arguments. It uses native process spawning with shell:false, a fixed argument list, an ephemeral Codex session, Codex read-only sandboxing, a synthetic demo_workspace, a minimal environment, output caps, bounded timeouts, and process-group cleanup on abort or timeout. Unsupported models, missing login, empty output, non-zero exit, and timeout all fail closed. The default CLI path remains mock-only; a live call happens only when --live-codex is explicitly selected.

No OpenAI API key is required for this local demo. The verified path uses the Codex executable bundled with ChatGPT desktop and an already authenticated local Codex session.

Build Week scope and provenance

July 11 baseline — pre-existing work

Before Build Week, Roundtable already had:

  • a local orchestration kernel and mock CLI flow;
  • persistence, convergence parsing, and the action-approval framework;
  • a working Electron shell; and
  • one separately authorized DeepSeek Electron path that completed one real guest response followed by one real lead synthesis.

That baseline did not prove a live Codex seat, live multi-provider roundtable, Gemini or Doubao automation, production MCP stdio, or autonomous Codex file actions.

July 21 meaningful extension — work judged for Build Week

The Build Week extension added:

  • the opt-in real Codex GPT-5.6 SeatDriver;
  • explicit live-versus-mock topology labels;
  • one real Codex provider called serially as Advisor and Lead, plus one labelled Mock Critic;
  • a fail-closed multi-source requirement for the live command;
  • stdin prompt isolation, model allowlisting, environment filtering, synthetic-cwd fencing, timeout/abort process-group termination, and output limits;
  • focused driver and regression tests; and
  • Build Week documentation separating the old baseline from the new extension.

Only this July 21 extension is presented as the Build Week contribution.

Challenges we ran into

The first end-to-end live run exposed two problems that unit tests had not revealed. A legacy five-second orchestration timeout ended the real Codex turn early and allowed a single-source fallback. We passed the bounded live timeout through the orchestration layer and made multi-source evidence mandatory. We also found completed timers that kept Node alive after output was printed, so every settle path now clears resolver and termination-grace timers.

The larger design challenge was resisting impressive but inaccurate claims. We deliberately show the critic as mock, describe Advisor and Lead as two serial calls to one provider, and keep live Codex text-only.

Accomplishments that we're proud of

  • The complete automated suite passes 309/309 tests.
  • Static checks, CLI smoke, app smoke, and standalone verification pass.
  • A final-clone evidence run completed in 16.2 seconds with exit code 0. The accepted clean recording run, after adding the explicit live Lead header, completed in 17.3 seconds with exit code 0.
  • In that run, the live Advisor generated a non-scripted Yes recommendation, the critic was visibly marked [MOCK SEAT], and the live Codex Lead returned all four convergence fields.
  • The live command rejects failed or single-source rounds instead of silently claiming success.
  • The human approval boundary remains visible and testable.

What we learned

Trust comes from explicit boundaries, not just model capability. Labels such as live, mock, and human-approved are part of the product architecture. Real end-to-end testing also matters: it found orchestration and cleanup defects that isolated tests missed. Finally, one carefully constrained live integration can be more credible than a broad demo that suggests providers or actions are connected when they are not.

What's next

Next we would replace the mock critic with a second independently verified live provider, add stronger provenance for every contribution, and evaluate longer multi-round sessions. We would also connect real tools only through the existing proposal, schema, risk, audit, and approval pipeline. Browser providers, production MCP stdio, cross-restart provider-thread restoration, and autonomous actions remain future work—not current claims.

Built With

Share this project:

Updates