Agents Will Overbuild Your Stack. One YC CTO's Fix Is Radical Simplification.

Every team running AI coding agents has a version of this story. The agent was supposed to be working on a feature. It found Python data science code elsewhere in the repo, decided the application would work better in Python, and started rewriting it. Nobody asked; nobody approved. A sub-agent spun up, assessed the opportunity, and began porting application logic into a language the rest of the codebase didn't use.

The conversation around AI agents and production systems has rightly focused on access control: who gets to touch the database, how to enforce permissions below the model's reasoning, and what happens when agents get write access they shouldn't have. Those are real problems. But there's a second failure mode that shows up earlier and more often, and it doesn't trip any security alerts. Agents don't just break things; they complicate things. They introduce data stores nobody requested, make architectural decisions no human reviewed, and leave you with a stack that's harder to reason about than the one you started with.

Matt DuVall is the Co-Founder and CTO of Numeral, a YC-backed company building sales tax infrastructure for e-commerce. Numeral runs on Aurora Postgres, and DuVall keeps the stack deliberately narrow. That Python rewrite? It happened on his team. "I had an engineer who said the agent was great, but unprompted, went off and started rewriting parts of the application in Python," DuVall says. The agent had read data science code elsewhere in the repo and had a sub-agent conclude it could embed that same code in the application if only it were written in Python. "And it just started going off the rails."

The incident didn't cause downtime. Nothing broke. But it's the kind of architectural drift that continues to compound until someone has to untangle it six months down the line.

Open schema, open season

DuVall's team learned the containment lesson the expensive way. In Numeral's early days, agents had broad access to the full schema through a single database user and a Prisma configuration that exposed everything. The agents did what agents do when the whole surface area is available: they explored.

"One user for everything. 'Here's a Prisma schema, everything in the database,'" DuVall says. "The agents sometimes just go to town. Okay, great, I spent $400 and this is exactly the change I wasn't looking for."

Four hundred dollars in wasted compute isn't catastrophic. But the failure mode it represents is. The agent didn't violate any permissions. It operated within the boundaries it was given and made decisions about the stack that nobody reviewed. At that scale, the cost is just dollars. At a larger company with more agents running autonomously, the cost is architectural complexity that accumulates faster than any team can audit.

The fix wasn't more sophisticated prompting. DuVall scoped database roles so agents could only touch specific parts of the schema. A role called "feature developer," for instance, gets access to certain parts of the user-facing application but can't reach the admin side or other system boundaries. Postgres' column-level security and role-based access made this possible without new tooling. "They made the calls correct for making it safe for all human use," DuVall says, of Postgres' permission model. "Those features naturally ended up being the right set of features you need to make sure the agent goes off and does the right thing."

S3 and Postgres. That's it.

The scoped roles solved the immediate problem. DuVall's broader philosophy goes further: if the agent has fewer things to reach for, it makes fewer bad decisions.

At Numeral, that philosophy is enforced through a strict consolidation rule. Engineers regularly surface new data stores, new AWS services, new off-the-shelf tools. DuVall's default response is the same every time. "My push is always: we have S3 and we have Postgres," he says. "You can actually solve the problem you have with Postgres. It has great geocoding libraries, great materialized views, great row-level security, column-level security. It has all the features you need to guarantee the system properties you're looking for."

The argument isn't that Postgres is the right tool for every job. It's that a consolidated data layer is easier for everyone to reason about, and "everyone" now includes agents. "It's so much easier a mental model for engineers, for agents, for anyone who touches anything technical, to say the data store from end to end is actually just Postgres."

The alternative is what happens without that constraint. DuVall describes the worst-case scenario for teams that let agents pick their own tools: "You could easily wake up to find you're now using Redis, Memcache, Clickhouse, RocksDB, and Postgres to solve user auth." Nobody decided that was the architecture. The agents decided it, one reasonable-looking commit at a time.

Convention does half the work

The consolidation principle extends beyond the data layer. DuVall's team runs on Ruby on Rails, and he's noticed that agents perform measurably better in frameworks that are prescriptive about how things should be built. "There's so much opinionated Rails code out there written by DHH and all the other folks in the community that the agents have a very easy time picking up the right thing to do out of the gate," DuVall says.

The inverse is also true. Without codified conventions, agents overbuild. DuVall has seen models generate entire infrastructure stacks for problems that needed a single table and a few queries. The models aren't wrong in the way a security breach is wrong. They're wrong in the way a junior engineer with no architectural context is wrong: they solve the problem they can see without understanding the system around it.

"You need to codify that thinking somewhere within your repository, or just as context for the agent," DuVall says. "Because without that context, they will right now overbuild."

The sandbox beneath it all

Even with a simplified stack and codified conventions, DuVall doesn't trust the application layer to contain agents. His team runs the entire Numeral infrastructure inside Modal sandboxes during development. "We just spin up a sandbox. It thinks it's in some staging environment, but it's actually inside of a pretty well-contained environment running on Modal. It's not even on AWS."

The approach works until it doesn't. The leakage always comes from the same place: third-party dependencies that can't be faked. "Inevitably you have some third-party API that you talk to, some data store that needs to be accessed only in production," DuVall says. "You have all these snowflake pieces of infrastructure that tend to become load-bearing, and all of a sudden you're no longer within a sandbox."

The sandbox is the physical boundary. The architectural simplification is what makes the boundary hold. Fewer data stores, fewer third-party integrations, and fewer "snowflake" dependencies mean fewer places where the sandbox cracks.

The best database decision is the one you stop making

"I don't really think about Postgres day to day," says DuVall. "It just does all of these things for me, and I get to spend most of my time actually thinking about building stuff that's incremental to the business or net-new features."

That's the payoff of architectural discipline in the agent era. The teams that codify their stack philosophy, enforce it through database-level permissions, and give agents fewer things to reach for will spend their time on features. The teams that don't will spend it unwinding the decisions their agents made for them, one $400 change, one surprise Python rewrite, and one unnecessary data store at a time.