AI Boardroom

• 

  One COO and 6 Ai Assistant Agents

Inspiration

Founders often need to make consequential decisions with incomplete evidence, changing constraints and too many disconnected conversations. AI Boardroom puts a founder and a browser assistant in one shared decision room where specialist perspectives, evidence and trade-offs remain visible.

What it does

AI Boardroom gives one browser AI six specialist perspectives: Product, Evidence, Commercial, Operations, Technology and Chair. WebMCP lets the assistant read the live brief, request named roles, post evidence-linked contributions, respond when constraints change, and retrieve the exact decision record.

The central interaction is deliberately human-controlled. A fictional launch budget changes from R20,000 to R8,000; the previous recommendation becomes stale, the assistant reads the new revision, and a new recommendation can be prepared without rewriting the earlier record. The founder reviews alternatives and reservations, then approves, rejects or requests revision in the visible page form.

This is stateful collaboration rather than a detached chatbot transcript. The app does not run six independent AI workers or call a model API. One browser assistant adopts the roles and the human retains the final decision.

How we built it

The app is built with the OpenAI Sites React and TypeScript scaffold, Vinext and D1. Native document.modelContext.registerTool exposes seven WebMCP tools: start_session, get_boardroom_context, update_agenda, request_perspective, add_contribution, prepare_recommendation and get_decision_record. UI actions and WebMCP tools share the same API and persistence logic.

Mutation inputs use expectedRevision for optimistic concurrency and operationId for safe retries. Evidence is stored with the relevant contribution and rendered as untrusted text. The visible review channel is a workflow boundary, not proof of human identity.

Challenges

The design challenge was making an AI council useful without pretending that six hidden agents or automatic consensus exist. We made the roles explicit, preserved disagreement, invalidated recommendations when the brief changed, and kept approval out of the WebMCP tool surface. A second challenge was handling uncertain browser or network outcomes without duplicating or overwriting decisions.

What we learned

WebMCP is most valuable when the agent can operate on the same visible, stateful interface as the human. Structured tools make the collaboration legible, while revision checks, evidence snapshots and a human review stop make the limits legible too.

What's next

Production use would require stronger identity and access controls, consent design, privacy and retention rules, abuse and rate-limit controls, independent security review, and integrations governed by explicit human approval.

Disclosure

All briefs, budgets, evidence and decisions in this project are fictional. The app does not make purchases, send messages, or change external systems. Browser-generated council text is created at runtime and is not preseeded consensus.

Built With

• react