What I learned from building a product for agents

I’ve been messing around with OpenClaw for the last few weeks. It’s been hit or miss, but what has been really interesting is getting my OpenClaw agent, Wren, setup with tooling.

Agents don’t have the same needs as humans when it comes to tools. Humans want dashboards, onboarding flows, nice UIs, and notifications. Agents care about APIs, documentation, speed, and execution.

While refining my OpenClaw set up, I kept running into this annoying issue while making thumbnails for my amazing YouTube channel (plz sub, thank you).

My OpenClaw agent could easily create the thumbnails (Nano Banana, GPT-Image), but it could only save them locally on its machine, which I couldn’t easily access. I wanted my agent to be able to create the image, host it somewhere and send me the link. I solved the first version of this by adding file support to a custom OpenClaw dashboard I built in Converge.

What I really wanted was a simple tool where my agent could host files whenever it needed to. Something like S3, R2, or Dropbox, but built specifically for agents.

So I set out to build exactly that.

99.99% of software products built today were built for humans. Dashboards, notifications, APIs, CLIs, etc. were all built with the idea that a pair of human hands was on the other side.

As AI agents become more powerful and autonomous, more usage will be agent-based. And agents can generate orders of magnitude more activity than people ever could. Think about how quickly Claude or GPT can write code, run tasks, and call APIs.

So the question becomes:

How do we design software when the primary user is an agent?

Non-negotiable.

Agents work best when documentation exists at a single URL in a structured format (usually Markdown). Think something like a Skills.md file that contains everything the agent needs to know.

Scattered documentation across multiple pages is friction.

Agents need to be able to:

• create accounts

• create workspaces

• generate API keys

• start using the service

All without a human touching a dashboard.

You can still enforce limits for unauthenticated agents to prevent abuse, but basic onboarding must be API-driven.

Jared Friedman@snowmaker

Even the best developer tools mostly still don't let you sign up for an account via API. This is a big miss in the claude code age because it means that claude can't sign up on its own. Putting all your account management functions in your API should be tablestakes now.

8:10 AM · Feb 27, 2026 · 394K Views

245 Replies · 116 Reposts · 1.99K Likes

Agents can make requests extremely quickly.

A burst of API calls isn’t necessarily malicious, it may just be the agent doing its thing. Rate limiting strategies need to reflect that.

Agents retry operations constantly. APIs need to support safe retries and idempotent operations.

Agents don’t parse prose error messages well.

Errors should be structured, predictable, and programmatically interpretable.

This came up in a recent 20VC podcast discussion about the sandbox company E2B.

They initially got sandbox startup time down to about 400ms, which is essentially instantaneous to a human.

But they kept optimizing it down to 80ms, because agents noticed the difference.

Why? Because an agent might spin up hundreds of sandboxes in a workflow. Small latency improvements compound quickly at that scale.

This is a fundamentally different usage pattern than human workflows.

One underrated benefit of building for agents is that you can reach your users at any time.

You can ask your own agent to read the documentation, attempt onboarding, and report where it gets stuck.

Yes, agents tend to “yes-man” you a bit, but with the right prompts you can get surprisingly useful feedback still.

It creates an incredibly tight iteration loop:

1. update docs

2. run the agent again

3. see where it fails

4. fix it

I had two main principles in mind when building Agentstorage:

1. Agents should be able to sign up and start using the service without a human.

2. The documentation should be clear enough that my OpenClaw agent could successfully use it.

I can already hear the people in the back screaming about API abuse and spam. Listen, it might happen, but there are a lot of things you can do to minimize the damage. Here’s what I landed on.

Agents can generate API keys and start using the service, but with usage limits in place.

They can access most endpoints, but storage capacity is capped until a human claims the workspace via a link the agent receives.

That single safeguard goes a long way. Agents can get started immediately, but abuse potential stays limited.

Onboarding is simply sharing a Skill file with the agent.

No dashboards required.

The documentation lives in a single Skill.md file.

Every time I made changes to the product, I updated the skill file and shared it with my OpenClaw agent to see whether it could still successfully complete tasks.

That tight feedback loop is one of the best parts of building for agents.

You don’t have to chase humans for usability feedback, the agent is the user.

A few patterns felt especially important:

• Claim-link onboarding: Agents can start on their own and share a claim link with their human later.

• Scoped API keys: Keys are scoped by prefix and operation to limit blast radius.

• Link-first outputs: Artifacts should immediately produce a shareable link.

• Append as a first-class primitive: Agents write logs and traces constantly. Append operations should be native — not simulated via download/edit/reupload cycles.

• Simple signed link API: One call, predictable response, controlled expiry.

• Webhook-first integrations: Polling loops are inefficient for agents.

• Safe pre-claim defaults: Limits exist before full activation so early usage isn’t dangerous.

While building Agentstorage I experimented with existing tools. Partly because I originally planned to just use something off-the-shelf, and partly as competitive research.

I went the furthest with Cloudflare R2.

I benchmarked the first-run setup process to compare friction from an agent-first perspective.

1. Install Wrangler CLI

2. Browser OAuth login

3. Run bucket create command

4. Blocked by enablement gate

5. Switch to dashboard to enable R2

6. Add billing method / credit card

7. Rerun create bucket

8. Browser consent prompt

9. Approve

10. Upload file and retrieve link

Total time: ~30 minutes, multiple browser interactions, and a credit card requirement.

Even if I gave my agent a credit card, navigating the Cloudflare dashboard would still be extremely difficult.

1. Send skill file to agent with file to upload

2. Receive link back

That’s it.

We’re still very early in the agent economy world, which means there is a lot of opportunity. Large companies will eventually adapt. They’ll add CLIs, restructure documentation, and make APIs more agent-friendly. But I still believe there is a distinct advantage to build for agents specifically, as your main user, from day 1.