12-Factor Agents: Patterns of reliable LLM applications — Dex Horthy, HumanLayer

Agent frameworks can help teams produce an exciting prototype quickly, but the final stretch toward production reliability often exposes abstractions that obscure how prompts are assembled, tools are supplied, and execution actually works. Dex Horthy describes reaching an apparent quality ceiling of roughly 70–80 percent before finding himself buried in framework internals. His underlying argument is that builders need enough ownership of the system to inspect and improve the mechanisms that determine its behavior. 0:15

That ownership starts with deciding whether an agent is necessary at all. Horthy recalls trying to make a DevOps agent execute a Makefile correctly, only to discover that repeated prompt revisions eventually amounted to spelling out an exact sequence of build steps. Once the task had become fully specified and predictable, an ordinary Bash script would have been the simpler solution. In his conversations with more than 100 founders, builders, and engineers, he found that effective production agents were often mostly conventional software with carefully selected LLM-powered components. 1:11

The resulting 12-factor perspective is not a demand for greenfield rewrites or a rejection of frameworks. Horthy presents it as a collection of modular patterns that teams can incorporate into existing applications, and as a wish list for frameworks that preserve development speed without hiding the details required for high reliability. The practical challenge is to apply established software-engineering discipline to the parts of an application that depend on a model. 2:06

Horthy identifies a foundational model capability: converting natural-language input into structured JSON. The important distinction is that producing a structured representation and acting on it are separate operations. A model can suggest the next action, while deterministic application code decides how that action is interpreted, dispatched, executed, and incorporated into the rest of the workflow. 3:08

This distinction motivates his deliberately provocative criticism of treating tool use as a mysterious autonomous capability. His objection is not to giving agents access to external systems; it is to abstractions that conceal the ordinary mechanism underneath. The model emits JSON, deterministic code handles the requested operation through familiar constructs such as loops or switch statements, and the application may feed the result back into the model. Understanding that division makes execution easier to reason about and change. 4:09

A basic agent loop receives an event, builds a prompt, selects an action, records the result, and repeats until the model indicates that the task is complete. Horthy argues that this naive design becomes less dependable as workflows lengthen and context accumulates. Owning the control flow allows developers to introduce deliberate exits, branching, summarization, and model-based judgment instead of accepting an opaque loop that continually expands its own context. 5:00

For Horthy, prompt ownership is essential because improving an agent ultimately requires controlling the tokens presented to the model. Prompt-generation abstractions can provide useful starting points, but teams seeking higher quality may need to inspect and refine individual prompt details directly. He does not claim there is one universally correct prompt; instead, he emphasizes the ability to try alternatives, adjust meaningful parameters, and evaluate which choices produce better results. 8:36

The same principle applies to context engineering. Rather than assuming that a standard message format is the only valid representation, developers can model conversation history, application events, retrieved information, memory, and current state in whatever structure best communicates the next decision. Horthy argues that the density and clarity of that representation influence output quality, and that merely accepting very large context windows does not remove the need to limit and curate what the model receives. 5:53

Errors deserve the same selective treatment. Feeding an unsuccessful API call and its associated error back to the model can support recovery, but repeatedly appending failures may cause the workflow to spiral, lose useful context, or become stuck. Horthy recommends clearing obsolete errors after a valid action appears, summarizing failures when appropriate, and avoiding unnecessary material such as entire stack traces. The goal is to communicate the information needed for a better next step, not to preserve every intermediate artifact indiscriminately. 10:27

Reliable applications also distinguish execution state from business state. Execution state includes details such as the current step, the next step, and retry counts, while business state includes user-visible messages, displayed data, and pending approvals. By owning that state, an application can expose an agent through a REST API or MCP server, persist its context when a long-running operation begins, and later reload the saved state using an identifier supplied with the operation’s result. The workflow can then resume without requiring the model itself to maintain durable state. 6:52

Horthy argues that interactions with people should be treated as an intentional part of agent design rather than an awkward exception. Instead of forcing every response into a binary choice between a tool call and a message, developers can give the model distinct ways to indicate that it has finished, needs clarification, or must involve another person. Framing that initial intent in natural language can make the decision more legible while enabling human participation in a larger workflow. 11:19

Human involvement becomes more practical when agents operate through channels that users already inhabit. Horthy points to email, Slack, Discord, and SMS as alternatives to requiring people to juggle multiple separate chat-style interfaces. His broader recommendation is to meet users where they already work and to make approvals, clarifications, and collaboration part of the application’s ordinary execution path. 11:19

The architectural counterpart is the small, focused agent: a short agent loop embedded within a mostly deterministic workflow. Horthy describes micro-agents with roughly three to ten steps, allowing conventional software to handle predictable orchestration while a model resolves a bounded decision. At HumanLayer, a deployment bot operates inside a predominantly deterministic CI/CD pipeline; after a GitHub pull request has been merged and development tests are passing, the model proposes deployment actions that can be reviewed by a human. 12:07

In the deployment example, the model initially proposes deploying the front end, but a human can redirect it to deploy the back end first. Once that action is approved and completed, the agent returns to the remaining front-end deployment; afterward, deterministic code resumes responsibility for production end-to-end testing, with a separate rollback agent available when necessary. The pattern preserves human judgment, keeps agent responsibilities bounded, and makes the transition between model-driven decisions and conventional software explicit. 12:59

Horthy allows that increasingly capable models may eventually take responsibility for larger sections of an endpoint, pipeline, or application. His proposed progression starts with a mostly deterministic system, introduces LLM-powered decisions where they add value, and expands their scope as they become able to handle more complex work. Greater model capability does not eliminate the need to engineer for quality; it changes where the boundary between deterministic code and model-directed behavior can reasonably sit. 12:59

A useful target is work near the boundary of what a model can accomplish reliably. Horthy argues that a team can create something meaningfully better by engineering the surrounding system so that a difficult task succeeds dependably even when the model would not solve it correctly every time on its own. That reliability comes from controlling prompts, context, state, execution, and human involvement rather than expecting a single abstraction to make uncertainty disappear. 13:51

His preferred relationship with frameworks is therefore closer to owned scaffolding than to an inaccessible wrapper. He describes work on a create 12-factor agent approach inspired by the idea of generating code that developers can inspect and own. In his view, supporting tools should remove peripheral operational difficulties while leaving builders free to concentrate on the genuinely challenging AI-specific work: refining prompts, shaping context, designing control flow, and enabling effective collaboration between agents and people. 14:38