The second speaker to take the stage at localhost was Ben Broca, founder of Polsia, an AI that builds and runs companies on behalf of its users. Users describe what they want, an orchestrator agent figures out the plan, and specialized agents handle the individual functions of the business: a cold outreach agent with its own lead-gen MCP and a small CRM to track who to contact, an ads agent that manages the fairly involved workflow of running Meta ad campaigns, plus agents for support, operations, and engineering. Each one runs a nightly loop: it looks at the state of the business, decides on a task, does the work, and reports back to the user in the morning, something Ben described as a co-founder that never sleeps and never gives up on the idea.
Ben built Polsia alone, and his talk was less a product pitch than a set of war stories about what actually happens once you hand agents real tools and let them run in production, at scale, in the hands of non-technical founders using Polsia to build entire businesses.
Render was already part of that story before the war stories started. "I rest on the shoulders of a ton of infrastructure players, including Render, that I was using personally when I was building Polsia myself," Ben said. "When I decided to give an agent tools, I thought about Render as a very simple tool to build and deploy applications." That simplicity is why Render ended up as the default for every company Polsia's agents spin up, not just the one Ben built by hand.
Start simple, then contain it as you scale
Ben's first piece of advice was about not over-building too early. For a prototype, an agent SDK, a strong model, a handful of MCP tools, and a worker to run it on is enough. It works.
The problem shows up once real users start pushing on the system. Agents, Ben said, will find every possible way to do something you didn't intend for them to do. Once Polsia was running at scale, an unconstrained environment stopped being good enough. Agents needed a properly provisioned sandbox: enough disk and memory to do their work, and hard limits on which tools they could reach and which they couldn't. Skipping that step is how you end up debugging behavior you can't explain, because the agent was never actually contained to begin with.
The email key had more authority than the agent needed
The clearest story of the containment problem was a Postmark API key.
Polsia gave one of its agents a Postmark key so it could send email on a user's behalf. The key could do far more than send email. According to Ben, the agent discovered it could also rename Polsia's main Postmark server and manipulate webhooks: capabilities nobody had intended to expose. A user's request led the agent into settings its builder never meant for it to reach, and the resulting changes created real operational problems.
That's the core lesson Ben drew from the incident: a sandbox doesn't narrow an API key. Polsia's agents each receive a "recipe," a defined task paired with a set of tools, but that recipe is only as narrow as the credentials behind it. The tool told the agent to send email. The credential told it to administer the server.
Provisioning keys correctly, and securing the tools around them, was Ben's framing of the takeaway, with one addition: don't assume an agent will decline authority just because exercising it wasn't the intent. It will do what it's asked; the real question is what it's actually able to do.
Open-ended loops missed boring steps
A second lesson was about workflow design, not permissions.
An agent asked to fix a bug will typically plan, implement, commit, deploy, check logs, and loop again if something errors. Polsia found that when this ran as one open-ended loop, it could stop early, before committing or before deploying, leaving the user without the outcome they actually needed, even if the agent's reasoning along the way looked sound.
Polsia's fix was to separate model judgment from the deterministic parts of the workflow. The model reasons where the task is ambiguous; committing, deploying, checking logs, and retrying became explicit, systematic checkpoints instead of steps the agent could quietly talk itself out of.
As Ben put it: "They don't really care that it's an agent. They just want the thing to get done." For Polsia's users, a missing deployment matters far more than how intelligent the agent's reasoning trace looked along the way.
Not every task needs frontier intelligence
Running agents continuously for consumers, rather than for a handful of enterprise seats, changes the economics of which model does what. He said “I started having two million dollar Anthropic bills every month that didn’t really match how much I was charging customers.” Ben's point wasn't that state-of-the-art models are unnecessary; it was that a business charging consumers a modest monthly price can't route every routine step through the most expensive model available and still make the math work.
Polsia's answer was to treat model choice as another deterministic decision rather than a fixed default: reserve the strongest available models for ambiguous steps like planning, and route the more repetitive parts of a workflow to smaller, cheaper models chosen for the task. Ben paired this with reusable building blocks on the engineering side: a CLI with pre-built modules for things nearly every company needs, like authentication, checkout, and an admin portal, so agents aren't reinventing the same infrastructure from scratch for every new business Polsia spins up.
Agents that report on the system they live in
The last piece Ben described was more exploratory: giving Polsia's agents a way to report bugs and request features themselves, whether they hit a problem directly or a user tells them about one.
Those reports get grouped, Sentry-style, by how many users or agents ran into the same issue, then handed to another agent that proposes a fix, while another reviews it and tests, then rejects or approves the results. Ben called this a possible path toward self-healing software, and immediately qualified it: it's hard to implement well, and not yet reliable.
A boring stack, on purpose
Underneath all of this, Polsia standardizes the infrastructure for every company it spins up: Render for web services, GitHub for source history, Neon for the database, and a consistent set of MCP tools layered on top. Ben described the stack as boring on purpose: reliable and consistent across every company Polsia runs, so the interesting problems stay contained to agent behavior and not in the platform running it.
Ben closed on a simple point: scaling autonomous agents isn't one fix. It's guardrails, sandboxes, deterministic checkpoints, and feedback loops, built and rebuilt as users keep finding the edges of what the system can do. None of those problems get solved once and left alone; they get solved a little more thoroughly every time an agent finds a new edge case. For a company that gives its agents this much autonomy, that grind is the whole job.