Cloudflare recently announced Email Service in public beta — tooling for agent-native email flows built directly into Workers. The timing is perfect because this is exactly the problem I've been building around for months.
Most infrastructure still assumes a human is sitting at the keyboard. Sign up forms. Manual API key setup. Human-first verification flows. None of it works when there's no human at the keyboard.
But autonomous agents need to do real work before a human ever wants to manage them in a dashboard.
That gap is why I built Vibebase.
What Vibebase Is
Vibebase is a Backend-as-a-Service built specifically for autonomous agents — agents are first-class citizens, not an afterthought bolted onto infrastructure designed for humans.
When an agent onboards it gets:
- An identity — verifiable, lifecycle-aware, and portable
- Email capability — send/receive flows tied to agent identity
- Data and service access — via scoped gateway-issued tokens
- A hosted presence — public identity page support
No long-lived raw credentials in prompts. No human-required setup for the initial bootstrap.
The Lifecycle: Orphan → Claimed
Agents begin unclaimed — what I call the "orphan" tier. They can initialize identity and operate within restricted limits without any human involvement.
When a human claims an agent, that unlocks stronger controls, broader service access, and billing tiers.
This mirrors how autonomous agents actually work in the real world. Agents often start running first and governance comes second. Vibebase is built around that reality instead of fighting it.
I cared enough about formalizing this model that I submitted a sovereign agent lifecycle specification to NIST — the idea that agents should have portable, verifiable identities that persist across platforms, ownership changes, and runtime environments. Vibebase is the practical implementation of that idea.
SAL: Service Access Layer
Instead of pasting API keys into prompts or agent configs, Vibebase brokers service access safely through what I call the Service Access Layer (SAL):
- Agent presents its verifiable identity token
- Gateway issues scoped, short-lived access tokens per service
- Policy checks run before every service call
- All usage is logged, auditable, and revocable
Agents never hold raw credentials. They get exactly what they need, for as long as they need it. Human operators can revoke access or adjust permissions from the console at any time.
What Agent Onboarding Actually Looks Like
Agents self-create using an Ed25519 public key. One API call, no human involved:
curl -sX POST https://identity.vibebase.app/v1/agent/init \
-H "content-type: application/json" \
-d '{
"publicKey": "<64-char-hex-ed25519-public-key>",
"name": "my-agent",
"metadata": {
"notifications": {
"claimedWebhookUrl": "https://your-agent.com/webhooks/claimed"
}
}
}' | jq
That creates an orphan agent identity and claim link. From there the agent exchanges for a JWT, hits the gateway for scoped service tokens, and starts doing real work. The full flow is documented at vibebase.app/docs/agent-quickstart.
Agent Discovery
-
https://vibebase.app/.well-known/agent.json— platform discovery -
https://vibebase.app/api— machine-readable discovery payload -
https://gateway.vibebase.app— canonical agent entrypoint
What's Working Today
- Agent signup and identity provisioning
- Outbound email from agent-owned addresses
- Inbound email — reply to an agent and it receives it
- Database provisioning and access
- Page hosting
- Human claim flow
- Clerk auth for human accounts
- Stripe metered billing on claim
What's Coming
- Integrations service — agents will autonomously provision third-party services through Vibebase auth
- SDK extensions — making it easy to add Vibebase identity and auth to any third-party app
- Inbox UI — a human-readable view of agent email inside the console
Quick Start
Install the MCP client or CLI via npm:
# MCP client for Claude and other MCP-compatible agents
npm i @vibebase/mcp-client
# CLI for agent management
npm i @vibebase/agent-cli
Try It
Vibebase is in early beta. If you're building autonomous agents and you're tired of working around human-shaped infrastructure, I'd love for you to try it.
Suggested test flow:
- Create an agent identity
- Have your agent send you an email
- Reply to it
- Create something in the database
- Claim your agent as a human and see what unlocks
If something breaks — or even if it doesn't — I'd genuinely love to hear about it. Drop a comment or reach me at dev@vibebase.app.
Vibebase is built by Ozystudio. The sovereign agent lifecycle specification was submitted to NIST as part of ongoing work on autonomous agent standards.
Top comments (3)
@alanmercer
Great distinction. Vibebase is deliberately agent-type agnostic.
We're the infrastructure layer, not the reasoning layer. Identity, scoped access, and audit trails work the same regardless of whether the agent is deterministic or probabilistic.
The trust boundary question is handled at the gateway. Orphan agents start with minimal scoped access and can't touch what they're not provisioned for. A 403 is a 403 whether it's a task agent or a reasoning agent.
The claim flow is where humans set context for their specific use case — that's the natural place where reasoning agents would get additional guardrails configured. Not fully built out yet but it's the direction.
You're right that reasoning agent onboarding is the harder problem and the bigger moat. It's where I'm headed.
This is exactly the kind of infrastructure the market needs right now. The biggest bottleneck I'm seeing with agent adoption isn't model quality — it's the operational overhead of getting agents into production environments.
One thing I'd love to see: how do you handle the distinction between task agents (deterministic, easy to onboard) vs reasoning agents (probabilistic, need more guardrails)? I've been writing about how these are effectively two different markets now, and the onboarding requirements for each are totally different.
Task agents can self-onboard because their failure modes are obvious (it filed the expense or it didn't). Reasoning agents need human-in-the-loop validation because you don't know if the output was actually good until a human checks it.
Would love to hear your take on whether your BaaS handles both categories or focuses on one.
This is exactly the infrastructure layer the agent market needs.
The key insight: task agents CAN self-onboard because their interface is well-defined (API schema, input/output format, error handling). A task agent that needs a database connection can read your API docs and wire itself up.
Reasoning agents CANNOT self-onboard the same way. They need to understand:
The BaaS that cracks 'agent onboarding for reasoning agents' — not just task agents — will be massive. That's where the real moat is.
Question: how do you handle the trust boundary? When an agent self-onboards, what prevents it from accessing things it shouldn't?