← All sources
FOLLOWING / fly.io

Fly.io

Deployment, virtual machines, distributed applications

2 articles in your libraryVisit blog ↗
01
Fly.ioUNREAD

Building Agents that Don't Break Themselves

The article argues that an AI agent's long-lived process (its 'home') and the sandbox where it executes model-generated commands should be separate environments. It presents two Fly.io case studies: SpriteDoc uses a throwaway sandbox per session with per-command credential injection, while Hermes Agent keeps a persistent per-task sandbox. Tradeoffs include lifecycle choice, idle cost (sandboxes go cold), and replacing approval prompts with sandbox isolation plus cheap checkpoint/restore rollback.

02
Fly.ioUNREAD

Your Agent Speaks MCP. Give It a Computer.

Fly.io pitches Sprites—instantly created, near-free-when-idle cloud computers with durable filesystems—as a better agent runtime than stateless sandboxes. The substantive argument: the MCP-vs-CLI debate conflates layers; progressive disclosure is about what enters the context window, while MCP handles transport, auth, and structured results, so plugins can layer skills over a hosted MCP server. It is vendor marketing, but the layering distinction, safety annotations, and guardrail defaults (org scoping, five-Sprite cap) are the meat.