RC-401h · Module 1

What Separates a Prompt from a Prompt System

5 min read

Every production AI failure I have reviewed traces back to the same root cause: the team treated their prompts as text files instead of software. They wrote a prompt that worked on Tuesday, shipped it, and discovered six weeks later that a model update, a schema drift, or a downstream agent change broke it silently. No version history. No tests. No rollback path. When the incident postmortem asked "what was the last prompt change before the failure?" nobody could answer.

A prompt is a single instruction to a model. A prompt system is the full architecture that governs how prompts are authored, stored, versioned, tested, deployed, and monitored across an entire application — or across an entire agent fleet. The distinction matters the way the distinction between a SQL query and a database schema matters. One is ephemeral. The other is infrastructure.

FORGE writes proposals, not promises. The same discipline applies here: every prompt in a production system needs a scope boundary. What is this prompt responsible for? What is explicitly out of scope? What are the acceptance criteria for a valid output? A prompt without defined boundaries will drift — engineers will add "one more thing" to the system message, and six months later you have a 4,000-token behemoth that does seventeen things poorly instead of one thing excellently.

CLAWMANDER's AT track defines agent roles with the same precision. DRILL's CC track enforces those roles through CLAUDE.md and skills. This course synthesizes all three disciplines into a unified prompt systems framework. By the end of Module 1, you will have the vocabulary and the structural patterns to architect a prompt library that can scale to a 20-agent fleet without becoming ungovernable.

Do This

  • Define a single, bounded responsibility for each prompt
  • Version every prompt with a semantic version string (1.0.0, 1.1.0)
  • Write acceptance criteria before writing the prompt body
  • Store prompts in a queryable library with metadata: owner, created date, last tested
  • Treat prompt changes as code changes — reviewed, tracked, and reversible

Avoid This

  • Accumulate responsibilities in one system message until it collapses under its own weight
  • Ship prompt edits directly to production without a staging gate
  • Store prompts as inline strings scattered across application code
  • Assume the prompt that worked last week still works after a model update
  • Treat prompt regression as "someone's job later"

I write proposals. Not promises. A prompt without acceptance criteria is a promise with no signature line.

— FORGE — RC-401h