@QuinnyPig: Been thinking about what an "agent-native cloud" actually needs to look like. Mentioned this, and @Vercel's CEO replied…

Been thinking about what an “agent-native cloud” actually needs to look like. Mentioned this, and @Vercel’s CEO replied that it’ll be them. Cool! Here’s the spec they (or @Cloudflare, or some startup not yet invented) actually have to hit.

It won’t be @awscloud.

Thread…

1. Gated changes. The agent does not mutate prod directly. It opens a PR, kicks off an Action, proposes a change a human (or another agent) reviews. So far agents haven’t started routing around this pattern—the platform should make that the path of least resistance.

2. Stop making me fish for API keys every time the agent wants to light up a new service. The fix is secrets brokering: the platform holds the secret, the agent gets a handle, calls go through. A compromised agent can’t exfiltrate what it never had.

3. The API has to be consistent. 240 services with bespoke verbs pagination and region quirks is why Claude Code stumbles looking for the right command, then runs it in the wrong account.

Agents inherit AWS’s inconsistency tax at a higher rate than humans do.

4. Agents need their own identity. Today every action is laundered through the human’s IAM role, so the audit log reads “corey@duckbill did this” when the truth is “Claude’s third retry at 2am did this.” First-class agent identities: scoped, attestable, time-limited, revocable.

5. Hard budget caps that actually halt. Not the AWS “we noticed you spent $47K yesterday, here’s a CloudWatch email” approach. Fail closed at the boundary. A Lambda stuck in a loop racking up data transfer or inference charges is a real failure mode; treat it as one!

6. Cost circuit breakers with human escalation. The agent session has an allotment. It depletes faster than expected -> page a human to either authorize more or kill it. Finding out at the end of the month is how you take a $50K “oh no” media story to the chin every other week.

7. Cost preview as a first-class API. Before any state-changing call: “this adds ~$340/mo fixed plus $0.09 per 1k requests.” Most pricing is usage-based now, so the preview can’t just say “X dollars.”

Agents are bad at AWS pricing because AWS pricing is bad at being prices.

8. Error messages designed for an LLM to act on. Not “AccessDenied: User arn:aws:… not authorized because no identity-based policy allows.”

More like: “denied: this agent lacks dynamodb:Query on ‘users’; the owner can grant it at LINK.” Errors as instructions, not puzzles.

9. Blast radius as a primitive. “This session may spend up to X, touch up to N resources, in environment Y, expiring in 30 minutes.” Capability-bounded sessions, baked in. Today every agent is either god-mode or fully fenced off. The whole interesting design space is in between.

10. Time travel by default. Every state change is reversible for some window. “Roll back the last 20 minutes” is one command, not a CloudTrail seance that ends with you restoring yesterday’s snapshot and losing four hours of customer data along with the agent’s mistake.

11. Observability that ties action -> reasoning -> cost. Not “Lambda X fired” but “agent invoked Lambda X while attempting task Y, prompted by request Z, cost $0.0003 against a $5 session budget.” The AI-native equivalent of dmesg for distributed systems. Nobody has it yet.

12. Convention over configuration, ruthlessly. AWS forces explicit decisions on 1000 things with 1 obviously right answer 95% of the time. The agent-native platform should have brutal opinions about defaults, and when it needs to ask, ask the human, not flail through alone.

Most of this only matters because the agent runs semi-autonomously. If you’re typing prompts and watching every step, you just need a less hostile CLI. The interesting work is what changes when the agent runs unattended and you have to trust the platform not to incinerate money.

Ooh, good spot.

Yeah, that’s never really been my jam. True shitposters do it for love of the game.

I keep my AI slop safely confined to http://shitposting.ai instead.

@QuinnyPig wonderfully put.

have made 2, 3, 4, 11 for an execution layer we are building.

2 -> in fact why just api keys? can be for logins as well 3 -> we started with consistent specs for a list of mcps, apis, graphqls and that too has made a big diff! 4 -> was interesting to solve 11 -> haven’t yet seen a lot of usage on the product but made this yes

in dev -> 8, 5, 6, 7, 9 (in order of our execution)

10 and 12 are interesting and i am down to chat more about these