Why We Don't Need a Prompt Framework
Why We Don't Need a Prompt Framework
Everyone writes prompts in markdown now. And honestly, markdown is great. It's readable, it diffs cleanly, anyone on the team can open the file and understand what it does.
But a new wave of prompt management tools is emerging — frameworks that wrap markdown with template engines, JSX components, and YAML frontmatter. The pitch is compelling: your prompts have variables, conditionals, and dependencies. They deserve real tooling.
We agree with the diagnosis. We just arrived at a different treatment.
The Problem Is Real
If you're building agents, you've hit these walls:
- You need a variable. Now you're string-concatenating.
- You need a conditional. The system prompt changes based on user tier. Now the prompt is split across three files with if-statements in your application code.
- You need to reuse instructions across prompts. Copy-paste. Four copies drifting apart.
Markdown gives you readability. It doesn't give you composability, logic, or type safety.
But It's Not a Content Problem
Here's where we diverge from the prompt-framework crowd: this isn't a content problem. It's an architecture problem.
Your prompts aren't static documents with a few template variables. In any serious agent system, a prompt is the output of a pipeline — assembled at runtime from identity, context, memory, capabilities, and policy.
Treating prompts as "markdown files with better templating" is solving the wrong layer.
What We Built Instead
In AitherOS, prompts are assembled by a 12-stage context pipeline. There is no single "prompt file" for any agent. Instead:
Identity is defined in YAML. Each of our 29 agent personas has a declarative identity file — name, capabilities, personality traits, tool access. Change the identity, every prompt that agent produces reflects it.
Context is built at runtime. The ContextPipeline assembles layers in order: axioms, identity, rules, capabilities, active context, memories, and affect state. What goes into the prompt depends on who's asking, what they're asking about, and what the system currently knows.
Conditionals are pipeline logic, not template logic. A free-tier user hits different capability gates than an admin. An effort-2 task gets a lightweight context; an effort-8 task gets the full reasoning stack. This isn't {{#if paid}} in a markdown file — it's architectural routing.
Reuse is structural. The soul system lets us overlay personality and behavioral guidelines between the identity and rules layers. Change the tone guidelines in one soul file, every agent that loads it gets the update. Sound familiar? Same goal as shared components, achieved through composition at the pipeline level.
Variables are just... context. Memory graph hits, capability tokens, active conversations, system state — these flow into the prompt because the pipeline queries for them, not because someone typed ${user.name}.
The Auto-Generated Markdown
Here's the irony: we do produce markdown. Our CLAUDE.md, .cursorrules, and copilot-instructions.md files are all auto-generated from the same source of truth — config YAMLs and the Python pipeline.
The markdown is a derived artifact. It's the build output, not the source code. IDE tools consume it. Humans read it for orientation. But no one edits it as the primary authoring surface.
When Prompt Frameworks Make Sense
To be clear — tools like AgentMark solve a real problem for a specific audience:
- Teams with 5–20 relatively static prompts
- Variation is mostly content-level (tone, language, user tier)
- The people writing prompts aren't the people writing application code
- You want PR-reviewable prompt changes without touching Python/TypeScript
If that's you, a .prompt.mdx file with JSX conditionals and shared components is a genuine improvement over string concatenation.
When They Don't
If your prompts are assembled from runtime state — memory, active context, capability tokens, system health, conversation history — then a template file can't express what you need. You're not filling in blanks. You're running a pipeline.
The moment your prompt depends on:
- What the agent currently knows (memory graph)
- What the agent is allowed to do (capability engine)
- How hard the task is (effort scaling)
- Who is asking (caller isolation)
- What personality is loaded (soul system)
...you've outgrown templates. You need a pipeline.
The Takeaway
The prompt management conversation often frames it as: "Markdown is good but needs superpowers."
We'd frame it differently: "Markdown is a rendering format. Your prompt system is a compiler."
The inputs are identity, policy, context, and memory. The output happens to be text that an LLM consumes. The interesting engineering isn't in the output format — it's in the assembly.
Build the pipeline. Let the markdown be a side effect.