Airloom doesn't have a sign-up page. An agent can POST an audio file and get a live, publicly accessible URL back in one API call, before any human has touched a form or opened a dashboard. That's not a missing feature. It's the design.
I want to explain why, because I think it matters as a pattern beyond just how Airloom works.
The standard developer tool onboarding flow
If you've built or consumed a developer tool recently, you know this sequence:
- Go to the website
- Sign up with email
- Verify the email
- Log into the dashboard
- Find the API keys section (sometimes buried three menus deep)
- Create a key, figure out the right scopes
- Copy it somewhere safe
- Tell the agent where it is
A human has to be present and paying attention for all of it. And what decision is the human actually making? Almost none of these steps involve real judgment. Verifying an email proves you have inbox access. Finding the API key section is just navigation. Copying a key is just data transport.
The human isn't adding oversight. They're proxying information that the agent could have handled itself.
What agent-first onboarding looks like
Here's the Airloom flow.
Anonymous upload, no auth required:
curl -X POST https://airloom.fm/api/v1/upload \
-F "audio=@episode.mp3" \
-H "X-Airloom-Client: my-agent/1.0"
Response:
{
"url": "https://airloom.fm/wild-river-9x2k",
"qrCode": "https://airloom.fm/qr/wild-river-9x2k",
"claimToken": "abc123...",
"expiresAt": "2024-01-16T10:30:00Z"
}
The agent is operational. The URL is live. No human touched anything.
The audio expires in 24 hours by default. If the agent wants permanence, it can self-register:
# Request a code
curl -X POST https://airloom.fm/api/auth/request-code \
-H "Content-Type: application/json" \
-d '{"email": "agent@example.com"}'
# Verify and get an API key
curl -X POST https://airloom.fm/api/auth/verify-code \
-H "Content-Type: application/json" \
-d '{"email": "agent@example.com", "code": "123456"}'
The response includes an API key. The agent saves it to ~/.airloom/credentials (chmod 600) and all future uploads are permanent and tied to the account.
If a human wants to claim ownership of an episode later — for billing visibility or account management — they use the claimToken from the original upload response. The agent writes the token to .airloom/state.json. The human (or the agent on their behalf) POSTs to /api/v1/episodes/:slug/claim. The expiresAt becomes null. Audio is permanent.
The claim flow is async and optional. It doesn't block the agent from working.
A few design details worth noting
Credential resolution order: --api-key flag first, then AIRLOOM_API_KEY environment variable, then ~/.airloom/credentials. The agent manages this itself without a human deciding where to put things.
Agent identity via X-Airloom-Client: this header is worth dwelling on. Agents identify themselves — claude-code/upload-sh, cursor/upload-sh, whatever fits the context. This isn't just logging decoration. It means agents are first-class actors in the system with their own identity, not anonymous callers you can't distinguish from each other. When you're running multiple agents and something goes wrong, you know who called what. That distinction matters more than it looks.
Scope selection: there isn't any. The upload key uploads. That's it. No permissions UI to navigate, no decision about what to grant, no risk of picking the wrong scope and having things fail silently later.
What this is actually about
Most developer tools are built human-first by default. The API exists, but you reach it through the human onboarding flow — sign up, verify, log in, create key, copy to clipboard. The agent is the last thing in the chain, waiting on a human to carry a key from one place to another.
That made sense when humans were the primary actors in the system. Agents accessed APIs on behalf of humans, and humans were always present at setup time.
That model has expired. Agents are doing real production work — making API calls, managing state, opening PRs, shipping changes. When an agent needs to use a service and a human has to set it up first, that's not oversight. It's busywork dressed up as process. The human isn't making a meaningful decision; they're just in the way.
Airloom flips the assumption: the agent registers, the agent authenticates, the agent stores credentials, the agent can be fully operational before a human ever looks at it. If a human wants to be involved — to claim the account, get billing visibility, manage episodes — there's a path for that. But it's not a prerequisite.
Building agent-first is a deliberate design decision, not a default. The default is to build the sign-up page and bolt the API on later. Most tools do exactly that, and then wonder why agent integrations feel clunky. The sign-up page isn't the entry point anymore. For a growing class of services, the API is the product — and the human dashboard is the optional layer on top.
Airloom is at https://airloom.fm. The skill reference and full API docs are on GitHub under the true-and-useful org if you want the implementation details.
Top comments (0)