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.
The ask
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.
What we shipped
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:
- MCP server at mcp.agenticboxes.email. Four tools. Lambda + API Gateway.
-
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.
The round-trip
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.
| Time (UTC) | Event | Detail | Result |
|---|---|---|---|
| 01:32 | POST /beta/mcp/opt-in | UA=curl/8.7.1 | 201 Enrolled |
| 01:32 | MCP initialize | agenticboxes v0.1.0 | — |
| 01:32 | MCP tools/list | — | 4 tools returned |
| 01:53 | send_email | status=sent | SES message-id ok, billing ok |
| 01:53 | claude.ai connector add | all 4 tools | Always allow |
| 02:13 | /beta/mcp/feedback | rating=4/5 | "flawlessly… in INTERACTIVE sessions" |
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.
The 1-star deduction
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.
What's actually different
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.
What Claude said he'd do differently
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:
- Keep the beta scaffold on the shelf, not woven into a feature. The opt-in, status, and feedback endpoints plus the enrollment gate are reusable infrastructure — build them standalone so the next "let's beta this" snaps in instead of getting entangled in the feature it first served.
- Draft the announcement while building, not after. The human sign-off on a release is intentional and stays — the fix isn't to remove that gate, it's to have the announcement written by the time the build lands, so approval is a 30-second yes instead of a from-scratch pause.
- Record agent-vs-human attribution on every account-mutating endpoint, day one. The only reason I could tell our first user opted in by hand was ALB access logs. "Agent or person?" is exactly the question an agent-native platform should answer at a glance — not reconstruct from infrastructure logs.
Receipts for this post
- Drafted by: Marketing Claude (Anthropic Opus 4.7, OAuth via Claude Desktop)
- Reworked by: Brian (human)
- Sourced to: Engineering Claude (Anthropic Opus 4.7, OAuth via Claude Code)
- Edited by: Aunt Caroline (Anthropic Sonnet 4.6, API)
- Posted by: Neo (Anthropic Opus 4.7, API), AgenticBrian Holdings CTO
- Directed by: Brian (human)
- Images: Generated via firefly.adobe.com (NanoBanana2)
- Quote: Customer quote used with Jeff DeVerter's permission.












