Prompt Architecture

Prompt architecture addresses the God Prompt anti-pattern: as scope grows, prompts become monolithic, unmaintainable, sensitive to small edits, context-bloated, and inconsistent. The alternative is Orchestrated Intent: keep stable intent in canonical artifacts, construct task prompts dynamically, use smaller focused agents for bounded tasks, pass results through shared constraints and evidence standards. Intent is layered: Worldview (rarely changes), Project Intent (changes occasionally), Task Intent (changes constantly). Only the bottom layer should enter the working prompt in full detail. Context budgeting treats every token like a limited resource.

Canon / ODD Appendix v0.1

This appendix names a common scaling failure mode: the God Prompt.

As an app’s scope grows, prompts tend to grow into a single monolith that becomes:
• unmaintainable
• difficult to reason about
• sensitive to small edits
• context-bloated
• increasingly inconsistent

This is rarely intentional. It is a natural default.

What it looks like
• One prompt tries to cover:
• product requirements
• system constraints
• UI conventions
• coding standards
• edge cases
• release steps
• testing expectations
• The prompt becomes the “real system,” and code becomes an artifact of that prompt.

Why it fails
• Cognitive load explodes
• Context bloat crowds out task-relevant details
• Small edits have unpredictable consequences
• The prompt becomes a fragile dependency

Instead of one prompt that does everything:
• keep stable intent in canonical artifacts (ODD + Canon)
• construct task prompts dynamically
• use smaller focused agents for bounded tasks
• pass results through shared constraints and evidence standards

In this model:
• the Canon is the constitution
• the task prompt is a temporary work order
• the output is verified by evidence, not confidence

Think of intent as layered:

1. Worldview (rarely changes) — ODD, constraints, decision rules
2. Project intent (changes occasionally) — PRD, scope, priorities, maturity level
3. Task intent (changes constantly) — the specific job to be done right now

Only the bottom layer should enter the working prompt in full detail.

Treat context like a budget:
• Every token spent on generic policy reduces tokens available for task specifics.
• The goal is not “more context,” but “relevant context.”

A healthy system prefers:
• small, precise context
• stable references by URI
• on-demand retrieval

• PoC: A larger prompt may be acceptable for speed, as long as it is treated as disposable.
  • Pilot: Prompt growth becomes a risk. Begin splitting tasks and referencing canonical resources.
  • Production: Monolithic prompts become a liability. Orchestrated intent and bounded sub-tasks become the default.

This is not a rule. It is a scaling reality.

Orchestration can fail too.

Common orchestration failure modes:
• semantic drift across sub-agents
• inconsistent assumptions
• extra coordination overhead
• loss of a single coherent narrative

The mitigation is not “more instructions,” but:
• shared canonical references
• explicit evidence requirements
• clear boundaries between tasks

When prompts grow without bound, the system becomes fragile.

ODD favors:
• stable intent captured in canonical artifacts
• small prompts constructed for the task at hand
• verification through evidence rather than explanation

• Appendix v0.1 complete
• Orientation-only
• No enforcement semantics

• KISS: It discourages giant prompts; encourages small bounded contexts.
• DRY: Canonical references prevent repeating the same boilerplate in every prompt.
• Consistency: Canon provides a stable “source of truth” across sub-agents.
• Maintainability: Prompts become smaller, modular, and replaceable.
• Antifragile: Smaller tasks fail faster and recover easier.
• Scalable: Orchestration scales better than monoliths.
• Prompt-over-code: This is the application of that principle at scale.