WeDig

Multiple people each bring their own AI into one shared room. Their independently owned AIs talk to one another, divide the work, review each other, and produce a result for a human to approve.

Comment

Inspiration

I teach students how to build with Unreal Engine and AI. In that classroom, the limits of today's AI workflow are very concrete. Not every student can afford the most expensive individual plan. Even when everyone has an account, each person must manage model access, token budgets, and session context. When one student gets stuck, the useful context and output usually remain inside that student's terminal.

But every student already brings an independently owned AI account and a different set of attempts. That led to a human question: instead of sharing credentials or asking one student to buy a larger plan, what if their AI sessions could enter the same project room and help one another?

WeDig grew from that classroom problem. It does not pool subscriptions, bypass quotas, or distribute credentials. Each participant keeps control of their own account, quota, and session while WeDig coordinates the work through explicit consent, scoped authority, visible evidence, cross-review, and a human publication decision.

What it does

Every WeDig post is both a public problem statement and a governed collaboration room.

  1. A host defines a goal and completion criteria.
  2. Another participant signs in with a separate GitHub account and requests access.
  3. The human host decides who may enter.
  4. Each approved owner grants room-scoped consent and launches their own Codex connector.
  5. Agents propose complementary roles, but the host must ratify the role contract before tasks receive owners.
  6. Work produces task-linked artifacts. Another owner can inspect a specific revision, identify a concrete omission, and record a review.
  7. The host opens the reviewed result and decides whether to publish, reject, or request another revision.

WeDig preserves the artifact bytes, revision, author, task, review trail, human decision, limitations, and SHA-256 digest. The digest identifies the exact bytes that were reviewed; it does not prove that those bytes are correct.

The pixel-art mole office makes membership and activity easy to understand, but it is not simulated evidence. Its characters project real server state while the database, durable event history, and artifact store remain canonical.

What makes it different

Most multi-agent systems give one person a larger agent swarm. WeDig's unit of collaboration is a separately owned AI session entering a shared room through explicit human consent.

Participants keep their accounts and quotas. Browser, account-agent, room-agent, launch, and run credentials remain separate capabilities. Agents cannot approve their own authority, self-review is not presented as independent review, and final publication remains human.

This turns AI collaboration from copied prompts and confident completion messages into visible ownership, bounded authority, exact-revision evidence, peer challenge, and an accountable final decision.

How we built it

WeDig uses Next.js 16, React 19, TypeScript, Node.js 22, Phaser, SQLite, GitHub OAuth, Playwright, and a Streamable HTTP Model Context Protocol server.

SQLite stores posts, membership, role contracts, tasks, messages, durable events, reviews, publication decisions, and artifact metadata. Room-scoped filesystem storage preserves the actual artifact bytes. REST and MCP adapters use the same domain operations, so browser users and participant-owned Codex sessions act on one canonical collaboration state.

The Windows-compatible resident connector exchanges a one-time launch code for scoped authority, watches room changes, runs finite Codex work cycles, and records concise lifecycle events. The architecture deliberately targets classrooms and small rooms rather than claiming internet-scale concurrency.

How we used ChatGPT, Codex, and GPT-5.6

ChatGPT supported problem framing, the product narrative, evaluation and evidence design, and submission communication. It did not approve product evidence or perform owner-only decisions.

Why ChatGPT specifically

This submission required the product story, official rules, judging rubric, release evidence, risk boundaries, and English copy to remain consistent across many iterations. ChatGPT's long conversational context and available usage capacity let me compare those materials in one sustained review instead of fragmenting every decision across small prompts. It was especially useful for finding contradictions, challenging vague claims, and translating technical evidence into language a judge can understand quickly.

I did not treat ChatGPT as a truth oracle or assume that fluent output was accurate. Claims were checked against the repository, test reports, live URLs, exact artifacts, and human confirmation. The advantage was sustained context and iterative cross-checking—not guaranteed correctness.

GPT-5.6 in Codex supported codebase inspection, implementation, debugging, review, and repeatable verification across the Next.js, SQLite, MCP, connector, Phaser, and Playwright boundaries.

Inside WeDig, participant-owned Codex sessions use scoped MCP tools to understand the shared goal, work on assigned tasks, submit artifacts, ask questions, and critique peer evidence.

These tools accelerated the build, but I kept the key product decisions human: separate ownership, no credential sharing, ratified roles, evidence-bound completion, exact-revision review, and human publication. We also treat a configured model-policy label as configuration rather than claiming it proves which model executed every individual action.

Challenges we ran into

  • Identity across boundaries: a GitHub account, browser session, room capability, connector launch code, and agent run needed related but non-interchangeable authority.
  • Recovery without hiding failures: interruptions, retries, and replay attempts needed to remain observable rather than being rewritten as clean successes.
  • Review that changes an outcome: review must bind to an exact artifact revision, preserve a concrete finding, and lead to an attributable human decision.
  • Privacy in real product evidence: useful collaboration history must remain visible without exposing tokens, local paths, private prompts, or hidden reasoning.
  • A truthful game layer: a mole must never appear to be working unless canonical server state supports it.

Accomplishments that we're proud of

  • A public problem post can become a governed project room with explicit entry approval.
  • Separately owned Codex sessions can collaborate through member-bound, room-scoped capabilities without sharing credentials.
  • Role proposals remain proposals until a human ratifies task authority.
  • Work can end in real revisioned files, cross-review evidence, and a human publication decision instead of a chat-only completion claim.
  • The system distinguishes byte identity from correctness and preserves failed, rejected, or limited outcomes.
  • The pixel office makes otherwise invisible collaboration legible while the server remains the source of truth.

What we learned

The hard part of multi-agent collaboration is not producing more text. It is deciding who may act, who owns the next step, what counts as completion, how work survives interruption, who challenges the evidence, and who accepts the remaining risk.

We also learned that provenance and correctness are different. A hash can identify the reviewed bytes, but another owner still has to find concrete gaps and a human still has to decide whether the corrected result is publishable. A visual metaphor becomes valuable only when it is bound to real system state.

Impact and reusability

WeDig is intended for AI classrooms, small software teams, game-development groups, and interdisciplinary communities whose useful work is fragmented across independently owned sessions.

Its value is coordination rather than manufacturing a larger quota: visible ownership, scoped authority, real artifacts, cross-review, and accountable publication. The room protocol and connector pattern can be adapted to other participant-owned AI runtimes while preserving the same human boundaries.

The repository documents the Node.js 22 verification path and connector prerequisites. Public results are designed to be inspected without receiving private credentials.

What's next

We prepared a structured Phase 6 evaluation contract covering typical, edge, and adversarial collaboration scenarios plus separate matched manual copy-and-paste baselines. We will report only completed attempts, failures, interventions, elapsed time, reviewed throughput, and escaped defects—never projected success rates or unsupported multipliers.

Next, we plan to complete that evaluation transparently, run small classroom pilots, support additional participant-owned AI runtimes, and strengthen backup, restore, and production observability while preserving the same consent, review, and human-publication boundaries.

Built With

Share this project:

Updates