Inspiration
General-purpose AI can draft a plan quickly, but real work often fails because one important perspective never enters the room: the care-label check in laundry, dependency timing in a release, accessibility in a design, or judge access in a hackathon entry. I wanted expertise to be selective, operational, visible, and human-controlled instead of a gallery of decorative personas and not another hidden autonomous workflow.
What it does
Sidekicks is a local-first planning workspace built around user-authored specialist playbooks. A Sidekick can represent any operational perspective: engineering, scheduling, laundry care, dance rehearsal, poetry editing, security review, or something the user invents. Each playbook defines when it applies, what it contributes, the questions it asks, the recommendations it permits, typed guardrails, and the checks a plan must cover.
A visiting AI uses exactly six typed WebMCP tools to read live workspace state, match only the useful Sidekicks, consult their decision contracts, evaluate a candidate plan, stage a visible proposal, and commit it only after explicit human approval. Every vote, issue, repair, tool call, and version transition remains visible and attributable.
The guided demo makes that transaction concrete. Engineer and Scheduler independently find seven blockers in a plausible three-step plan: an overlong build step, missing verification and dependency checks, overlapping work, a locked school-pickup conflict, and a dependency starting before its prerequisite can finish. The agent applies concrete deterministic repairs and both Sidekicks approve. It can stage the repaired proposal, but staging creates no tasks. A premature commit returns APPROVAL_REQUIRED. Only a visible human action unlocks one atomic commit that creates all three tasks and advances the workspace once. Rejected and stale proposals cannot commit.
Why WebMCP
Sidekicks is a strong fit for WebMCP because the integration exposes the product's native decision protocol rather than a thin CRUD wrapper: which expertise matters, what each specialist needs to know, why a plan fails, how it can be repaired, what is staged, and which boundary still belongs to a person.
Before WebMCP, a browser agent could read pixels or click controls, but it had no typed contract for selective expertise, attributed disagreement, deterministic repair, or approval-gated mutation. With WebMCP, the person and the visiting agent operate through the same transaction service while the site keeps every important decision visible.
How I built it
Sidekicks uses React, TypeScript, Vinext/Vite, browser-local persistence, and the imperative WebMCP API. Pure domain functions handle matching, consultation, temporal and dependency evaluation, playbook-bound constraints and checklists, repair generation, and stable proposal hashing. Strict JSON Schemas are backed by independent runtime validation from unknown input. One transaction service powers both the human controls and all six WebMCP handlers.
The first four tools are read-only: get_workspace_state, match_sidekicks_to_task, consult_sidekick, and evaluate_task_plan. stage_task_plan and commit_task_plan are write tools. All six share lifecycle cleanup, concise envelopes, validation, and a live activity trace.
There is no backend account system, external model API, or hidden server-side workspace state. The visiting browser agent is the model; Sidekicks supplies the decision protocol. The hosted worker serves the application shell, and the normal human workspace remains usable in browsers without WebMCP.
Challenges I ran into
The first challenge was proving that a Sidekick changes execution instead of merely adding profile text. I made every structured field observable in matching, consultation, votes, issues, or repairs.
The second challenge was preserving a real human boundary. Evaluation and staging are separate. Staging is inert. Approval is visible metadata rather than a model capability. Normal workspace edits make a proposal stale, and commit performs one atomic versioned write only when the proposal is current and human-approved.
Accomplishments I'm proud of
- A genuinely empty ordinary first run with no fake fallback profiles or tasks.
- Arbitrary human-created specialist playbooks rather than a fixed persona gallery.
- Exactly six auditable WebMCP tools with strict schemas and graceful unsupported-browser behavior.
- A complete rejection, repair, staging, approval, and atomic-commit story that judges can reproduce.
- Stable APPROVAL_REQUIRED and STALE_PROPOSAL failures that leave business state unchanged.
- A live agent trace and bounded activity ledger for every read, write, failure, and version transition.
- Light and dark themes stored separately from workspace and WebMCP state.
- 37 deterministic tests plus passing type checking, linting, and production build.
What I learned
WebMCP becomes compelling when a website exposes more than data access or CRUD. The strongest tools reveal the product's own decision protocol: what context matters, who should weigh in, why a proposal fails, how it can be repaired, and which action must remain human.
What's next
Potential next steps include shareable playbook packs, encrypted workspace sync, richer constraint types, and opt-in model-assisted playbook drafting. The core will remain browser-agent-native, inspectable, and human-gated.
AI build disclosure
I used OpenAI Codex for product scoping, interaction design, implementation, automated testing, accessibility and security review, deployment, browser-based demo orchestration, and submission drafting. Read-only Codex specialist agents challenged the build against judging criteria and release risks. The demo narration was generated with OpenAI's Marin voice.
Built With
- openai-codex
- openai-sites
- react
- typescript
- vinext
- vite
- vitest
- webmcp