Disp8ch: Where AI Teams Finish the Work

Inspiration

AI assistants are good at producing answers, but real work usually breaks after the answer. A product meeting ends, decisions disappear into a transcript, action items lose their owners, implementation happens somewhere else, and nobody can prove why a release was approved.

Disp8ch closes that handoff. It is an open-source, local-first AI work delivery system that turns a conversation or brief into accountable work, independent evidence, and an operator-approved result without hiding the process.

What it does

A team can capture a consent-gated live session, turn the transcript into timestamp-cited decisions and requirements, and hand that brief into a supervised mission. A planner defines the acceptance contract, an implementer completes the bounded work, and an independent reviewer checks persisted evidence. If a required check fails, the system permits a bounded repair pass instead of silently calling the task complete.

The result is an Outcome Receipt that keeps the original requirement, accountable roles, exact model assignments, evidence, cost, review, and release state together. Files Projects can then answer from the real repository, open the cited source range, preview the built result, and publish only after validation and explicit operator confirmation. An outcome-first Work Trail connects the meeting, owners, workflow, proof, source, approval, and public result for the next revision.

What existed before Build Week

Disp8ch entered the Submission Period as a working project built and tested over two months with GPT-5.5. That foundation already connected WebChat, visual Workflows, Boards, Hierarchy, Council, Data Sources, Memory, Skills, Design Studio, channels, approvals, and Activity.

What I built during Build Week with Codex and GPT-5.6

The Build Week extension added the missing end-to-end delivery layer:

• consent-gated Live Sessions and timestamp-cited Delivery Briefs;
• configurable planner, implementer, and independent reviewer roles;
• acceptance contracts, bounded repair, executable proof, and Outcome Receipts;
• source-grounded Files Projects with exact line highlighting and change impact;
• validation- and confirmation-gated preview, publishing, and feedback-to-revision;
• outcome-first Cross-Tab Work Trails that preserve the complete chain of evidence.

Codex with GPT-5.6 inspected the existing architecture, implemented and refactored these changes, diagnosed live-model and cross-tab failures, improved the UI and demo narrative, hardened dependencies, and ran the Windows-native release process. Inside Disp8ch, GPT-5.6 can also use the operator's authenticated Codex session for planning and independent review while a faster or lower-cost configured model performs implementation. If only one model is available, the same model can fill all three roles while the role boundaries and evidence contract remain visible.

I made the product decisions: the meeting-to-result problem, safety boundaries, model policy, acceptance criteria, UI direction, test cases, and final release decisions. External publishing, mutations, credentials, and untrusted feedback remain explicitly confirmation-gated.

How I built it

Disp8ch uses Next.js, React, TypeScript, Node.js, SQLite, Tailwind CSS, WebSockets, and Electron. Playwright drives browser and cross-tab validation. The Fieldnote demo artifact was planned and persisted through Design Studio and uses a contained Three.js visualization. The model layer supports OpenAI/Codex, DeepSeek, OpenRouter, and local OpenAI-compatible runtimes such as Ollama, LM Studio, llama.cpp, vLLM, and SGLang.

The final story was tested from a clean, isolated Windows database with real DeepSeek V4 Flash calls and GPT-5.6 through Codex OAuth for the supervised planner and reviewer. The release aggregate passed 71 of 71 suites. The final npm and pnpm audits report zero known advisories, including zero critical advisories.

Challenges

The hardest part was adding a complete delivery loop without duplicating the existing Workflow, Hierarchy, Council, Files, Design, or Activity responsibilities. The new system had to reuse their real objects and deep links instead of creating a separate demo-only path.

Other challenges included separating model claims from persisted evidence, keeping single-model and multi-model setups simple, making publication safe for local files and secrets, preserving local-first behavior, and testing browser, database, model, and desktop behavior natively on Windows.

What I learned

Agent orchestration becomes useful when completion has a testable meaning. Role labels alone are not enough: requirements need citations, reviewers need independent evidence, repair needs a bound, and the operator needs one durable receipt. I also learned that the clearest demo is not a tour of tabs. It is one visible outcome whose decision, owners, source, proof, and release remain connected.

The result

In the demo, one product discussion becomes an owned delivery brief, a supervised mission, a source-grounded release decision, and a verified Fieldnote public build. Four required gates pass, the accessibility check scores 96, zero critical issues remain, and private meeting data stays local. The operator can see the usable outcome first and inspect every step underneath it.

Meet. Decide. Deliver. Verify.

Built With

• codex
• gpt-5.6
• next.js
• node.js
• openai
• react
• remotion
• tailwind-css
• typescript
• vercel