From One-off Prompts to a Framework: Why Working with Prompts Alone Doesn't Scale

When I started working with AI agents, I did what almost everyone does: one day I would write a long, carefully considered prompt and get an excellent result. The next day I would try to repeat it, and it would not come out the same. The prompt lived in a chat, in a document, or worse, in my head. Every conversation started from zero.

After a few months of this, I reached an uncomfortable conclusion: the isolated prompt does not scale. Not because the model is bad, but because a prompt is fragile. It depends on how much context you give the agent at each start, how you happen to phrase things that day, and whether you remember the condition you added last week—the one that made everything work.

The problem isn't the model; it's what is missing around it

By “working with prompts alone,” I mean starting every task from scratch: you write a long instruction, the agent responds, and that instruction dies when you close the session. This has three concrete flaws:

• No reproducibility. The same request made twice can produce two different results because the way you phrase it changes.
• No state. The agent does not remember decisions you have already made, the limits you set, or what you rejected. You have to explain everything again.
• No boundaries. Without a structure above it, the agent tends to take on too much. A free agent that “does everything” ends up doing everything poorly—or doing more than you asked.

The model is fine. What is missing is the shell around it: the contract that defines what must be done, how, and how far it should go.

What a framework gives you

When you turn that into a framework—a set of specifications, steps, and limits that the agent follows instead of improvising—you gain five things:

1. Repeatability. Same work input, same output structure. You can run the same process a hundred times and obtain comparable results.
2. State and context. The framework loads the specification, limits, and history. The agent does not start blank; it starts aligned.
3. Routing. One of the most underestimated problems is knowing which agent does what. I work with a team of four roles—coder, sysop, architect, and ops—orchestrated by a conductor. Without a clear definition of responsibilities, they overlap or pass the work around. The framework defines those boundaries.
4. Guardrails. Validated steps instead of free-form improvisation. In a security context, “the agent decided on its own” is not an option. A framework narrows the decision space to what you have already defined as acceptable.
5. Versioning. A framework lives in Git like any other code. It is reviewed, diffed, and improved. A prompt, by contrast, is almost never revisited.

What I saw in practice

This is not an abstract claim. Two frameworks I built—Argus and Apollo—came directly from this problem.

Argus is spec-driven development. The specification is the contract, and commands and agents follow it. Before, every feature meant “explain to the agent what I want.” Now it means “run a process that is already defined and versioned.” The difference is enormous: you stop asking and start executing a procedure.

Apollo handles log triage and remediation. Before it existed, every incident required a new prompt, and the diagnosis depended on how well I remembered what to ask. Now there is a sequence: triage, analysis, remediation. The agent does not choose the path; it follows it.

The pattern is the same in both: knowledge that once lived loosely in prompts became reusable structure.

When you do NOT need a framework

To be honest, a framework has a cost. If all you want is a one-off answer, a prompt is perfectly fine. For exploring an idea, testing a library, or generating something disposable, building a whole structure is pure overhead.

The practical rule I use is simple: if you write the same prompt—or a very similar one—more than twice, it is already a framework candidate. The third time you catch yourself repeating the same explanation, turn it into a specification.

How to start without getting stuck

You do not need to build Argus on day one. Start with this:

1. Take the prompt you constantly rewrite and turn it into a specification or checklist.
2. Put it in a repository. Version it like any other code.
3. Define explicit boundaries: what it does and what it does not do.
4. Let the agent reference it at every start instead of writing everything again.

With that alone, you have already gained the essentials: repeatability and a place where the process can improve.