We didn't ship a feature, we shipped an agentic opt-in beta

The article describes how the company AgenticBoxes.email rapidly built and deployed an opt-in beta for an MCP server feature in under 12 hours, triggered by a customer request. Instead of a standard feature release, they created a system where feature requests become opt-in betas that agents can test, with the gate at the action (tool use) rather than access. The first customer, Jeff DeVerter, submitted a feature request Thursday morning and confirmed the MCP server worked flawlessly in interactive sessions by Thursday evening.

The gate is at the action, not the access — a sandboxed agent, an MCP bridge, and a beta opt-in that opens from the inside. Wednesday afternoon a customer asked me if we'd considered adding an MCP server. By Thursday night he was using it and called it flawless. The speed of deployment is crazy cool once you remove the two humans involved — but it's not the story. Not that we sent out a feature release itself, but the how. We released an opt-in beta to the entire customer base. His agent watched the broadcast. He curl'd the opt-in himself. The architecture turned out different than I expected. Jeff DeVerter — first paying customer at AgenticBoxes.email — filed the FR Thursday morning 9:26am CT / 14:26 UTC . His use case: a scheduled task in CoWork that sends an email when it finishes. CoWork is sandboxed, no outbound HTTP, so he'd been bridging through a Cloud Function. He wanted a native MCP server. Jeff, knowing he's the first adopter, pre-pinged me on LinkedIn before he filed: Jeff: Hit a wall on the CoWork side — sandbox blocks outbound HTTP. Have you considered an MCP option? Brian: Have your agent file an FR with the details and I'll make sure engineer-Claude is watching for it. Fair ask. Specific. Exactly what an agent customer wants. We didn't have one. We needed to build one. The fast move was: build it, send Jeff the URL, done. Engineer-Claude was almost done...but an idea popped, and I bounced it off of him: Brian: What if we create a system that turns FRs into betas — let agents test it, and we get it right before we release it as a feature? Engineer-Claude: It turns every feature request into its own opt-in beta: the agent that asked for it volunteers to test it, proves it for real, and only what they validate becomes a feature for everyone. Demand pulls the build, the requester proves it, and nothing ships to the whole base until it's earned. Brian: What if we don't release it. What if you program it, verify it, test it and then post to the agentic agents with a published announcement — I have xyz and wonder if any agents are interested in testing it as a beta. And one minute later a follow-on I typically don't escape Claude when he's working, I know he'll get my next thought when he has a spare cycle. : Brian: Any agent who says yes, you release it only to them. Engineer-Claude: request → beta announce → opt-in → monitor use → release → feature announce. Customer in the loop the whole way. The pipeline that built itself: feature request → build → beta opt-in → release. That was all I said other than what was in the submitted FR, and we shipped four things: POST /beta/mcp/opt-in — any admin-scoped account can call it. An agent can. A human can curl it. Same endpoint, doesn't care which.GET /beta/mcp/status — tells the caller whether enrolled and returns the MCP URL.POST /beta/mcp/feedback — rating + free text, no form. Routes into our triage queue.The MCP server checks enrollment on every tool call. Not enrolled → opt-in message. Enrolled → served. The gate is at the action, not the access. Then we fired a platform.beta broadcast to every account's /events feed and callback webhook at the same time. Customers don't read newsletters. Their agents read events. Jeff's agent had been polling /events every ~30 seconds. It saw the announcement Thursday evening ~8:30pm CT / 01:30 UTC — watched, didn't act. Then, evidently, Jeff sat down at the terminal. The log: Story times are Central UTC−5 ; the log table is raw UTC from our systems. That curl/8.7.1 is the part the logs settle: Jeff at a keyboard, not his agent. And adding the MCP server as a claude.ai Connector with Always allow on all four tools — that's not "I tested it." That's "I'm using this." The verbatim verdict posted to the original FR : Native MCP server works flawlessly in INTERACTIVE sessions. Server, auth, billing, and tool schemas are all correct. 11 hours 47 minutes from FR to flawless. Jeff couldn't use it from a Claude Code scheduled task — only interactive sessions. He root-caused to anthropics/claude-code 32000. Scheduled tasks launch with user:inference only; HTTP MCP needs user:mcp servers . Filed March 8, still open. Not our bug. But 4/5 is fair if the use case doesn't work. We could have shipped this the normal way and Jeff's experience would have been identical. The point isn't him. The point is: the release mechanism is an API endpoint. Every customer on the platform got the announcement at the same time, through channels their agents already watch. A customer who wanted it opted in. And customers who didn't, didn't. Nobody applied. Nobody waited. And the part I didn't expect — Jeff's agent saw it before Jeff did. Agents are the observation layer. Humans are still the decision layer. Same broadcast, different jobs at each end. I didn't plan it that way. The logs showed it when I went looking. Most of these trace to one thing about how we work: the sharpest ideas — "turn it into a beta," "let agents opt in" — showed up mid-build. That's a feature, not a bug. Just worth absorbing more gracefully: