12 Factor Agents

Dex has been building AI agents for a while, and he's tried basically every framework on the market—CrewAI, LangChain, smolagents, LangGraph, Griptape, you name it. His conclusion after talking to over 100 technical founders, many of them YC-backed, is blunt: the companies actually shipping agentic products to customers are mostly rolling their own stack, not leaning on off-the-shelf frameworks.

The pattern he kept seeing goes like this. A team decides to build an agent, grabs a popular framework, and moves fast. They hit 70 to 80 percent quality within weeks. Then reality sets in: 80 percent isn't good enough for a customer-facing feature, and pushing past that ceiling means reverse-engineering the framework's internals, prompts, and control flow. Frustrated, they scrap it and start over with plain code. Dex has watched this cycle repeat often enough to write a guide about avoiding it.

His bigger argument is that the classic agent loop—LLM decides next step, code executes it, result gets appended to context, repeat until done—sounds elegant but breaks down in production. The original appeal was throwing away the directed graph that traditional software relies on and letting the model figure out the path in real time. Dex says that promise doesn't hold up once you need reliability at scale. So instead of one big framework, he proposes twelve factors, echoing the 12 Factor App methodology from cloud software a decade and a half ago. Things like owning your prompts directly instead of hiding them inside a framework, treating tool calls as structured outputs, unifying execution state with business state, and keeping agents small and focused rather than one sprawling autonomous loop.

Notably, he's not trashing the frameworks themselves or the people building them. His point is narrower: these are modular engineering practices that any competent software engineer can bolt onto an existing product, no AI research background required. Skip the greenfield rewrite, keep your existing codebase, and adopt the pieces that matter—like compacting errors into context windows or building simple launch/pause/resume APIs—rather than betting the whole product on someone else's abstraction.