Most people who show up to Starchild want to vibe trade. They have a thesis, maybe a signal, and they want an AI agent to act on it. Some start simple: a trigger, a notification, done. Others end up somewhere they didn’t expect, multi-agent systems with conditional logic and coordination requirements they couldn’t have described a week ago.
That’s the jump that the Starchild team is working to make possible. Someone goes from “watch this ticker” to “run five agents that talk to each other and never miss a market open” without a formal architecture review in between.
Agent compute doesn’t look like app compute
Trading agents are modular. A monitoring agent. An execution agent. A review agent. Each one does something different, and each one spends most of its life doing nothing, waiting for conditions that might not come for hours or even days.
But when markets move, every agent needs to wake up and act. Immediately. 24/7.
Running all of that as a single always-on deployment is how you end up paying for a fleet that’s 95% idle. Fly Machines let agents suspend between tasks and resume on demand. This is how Starchild is delivering availability to its users, without them paying for uptime they’re not using. As workflows grow from one agent to ten, costs track actual usage, not some theoretical peak.
Fly also handles network isolation across all those machines. Agents that need to reach external services can. Everything else stays locked down.
Small team, lots of agents
Starchild doesn’t have a DevOps team. The simplicity of Fly’s networking, load balancing, and monitoring meant they didn’t need to build one. The team stays on product instead of fighting infrastructure every time someone invents a new kind of trading bot.
For a platform where the whole point is “anyone can build a trading agent,” that’s the right foundation.