An autonomous software factory has a failure mode that never shows up in the demo and never trips an alarm: it quietly costs too much. A system that plans, writes, reviews, and merges code on its own also reads storage on its own, provisions disk on its own, and keeps a NAT gateway busy on its own. Nobody is watching, so the waste compounds until someone opens the AWS console and asks what happened.
We shipped a user-facing reliability pass on Nexus Factory recently (deploys that drain cleanly, publishing under the right identity, a fast diff viewer). That is covered in Hardening the Factory. This post is about the other half of making an agent system production-ready: the economics. Here is the week we spent making the factory cheap to run, with the reasoning behind each move.
1. The NAT Tax Nobody Budgets For
Autonomous agents are chatty with infrastructure. Every artifact write to S3, every state read from DynamoDB, every plan hydration is a round trip. When that traffic leaves the VPC through a NAT gateway, you pay a per-gigabyte processing charge on top of the data transfer. For a workload humans drive, it is a rounding error. For a workload that loops unattended, it becomes a line item.
We routed the agents’ S3 and DynamoDB traffic through VPC gateway endpoints on the agent route table, and added the shared endpoints to the common infrastructure stack. Gateway endpoints are free and keep the traffic on the AWS backbone, so those bytes never touch NAT.
The transferable lesson: before optimizing code, trace where your bytes physically travel. The network path is often the cheapest thing to fix and the easiest to overlook, because it never appears in your application logs.
2. Right-Sizing Is Not Glamorous and Pays Immediately
Two changes in the same spirit.
We cut the default agent work volume from 200 GiB to 40 GiB. The agents were provisioning five times the EBS they ever touched, and you pay for provisioned capacity whether or not you fill it.
We dropped strongly consistent reads on a state-store cleanup scan. A background sweep does not need the latest write; eventual consistency is fine, and consistent reads cost twice the read capacity units. The scan was quietly paying double for a guarantee it did not need.
Neither change is clever. Both come from reading the resource definitions and asking “does this number need to be this big?” The answer, more often than teams expect, is no. That one question, applied across a stack, routinely finds real money.
3. In a System That Loops Forever, Everything Unbounded Eventually Breaks
A human-driven app gets restarted often enough that small leaks never matter. An autonomous system that runs for days will find every unbounded data structure you left behind, and the symptom is not a slow memory climb. It is an out-of-memory kill that takes a running job down with it, which on AWS means paying for the compute twice: once for the work that died, once for the retry.
So we bounded the things that grow:
- → The set of ended agent sessions is capped, instead of growing until the process is OOM-killed
- → Terminal task arenas auto-compact when work merges, reclaiming memory as the run progresses
- → Oversized plans get a dedicated compaction path
- → Aggregate list reads are scoped by record kind, so a query stops fanning out across data it does not need
We also added full-jitter backoff to the runner’s compare-and-swap conflict retries. Without jitter, parallel agents retrying in lockstep create thundering-herd load, which on a metered backend is load you pay for.
The through-line: “works in the demo” and “works at 3am on day nine” are different claims, and the gap between them is almost always an unbounded set, a retry without backoff, or a query that grows with history.
4. Pay the Cold-Start Cost Before the User Waits
Running agents on Amazon Bedrock AgentCore gives us managed, isolated runtime, but promotion was stalling on cold starts. The first invocation of a freshly built runtime paid the full container pull and initialization cost, so the user waited and the system looked slow precisely when it was being evaluated.
We added a warm pre-built runtime pool and shrank the cold-start image, and fixed a class of create-endpoint conflicts by randomizing the client token so a retry after a failed create no longer collides with itself.
The principle is old and still true: if a cost is unavoidable, pay it ahead of time, out of the user’s path. A warm pool is that principle applied to agent runtimes.
Why Cost Is a Correctness Property
It is tempting to treat cost as an afterthought, something to clean up once the system works. For an autonomous system, that is backwards. A factory that runs itself but cannot be left running without a budget surprise is not finished. The spend is not a side effect of the work; it is part of the work.
The exciting version of an autonomous software factory is the one in the demo. The one you can actually deploy is cheap to run, does not surprise you on the bill, and does not fall over when a data structure grows. We spent a week making ours boring on the dimension that matters most to the person who signs for the account.
Nexus Factory is one piece of the broader AllCode Nexus platform, which also includes a usage-metering gateway that prices and reconciles what all of this AI traffic actually costs. If you are mapping where your own team sits on the road to autonomous delivery, start with the AI-DLC maturity model.
Built by AllCode. See the factory live at nexusfactory.allcode.com.