PM-301a · Module 1

System Prompt Architecture Patterns

5 min read

System prompts above a few hundred tokens benefit from explicit structure. Three patterns dominate production deployments: monolithic, sectioned, and modular. Each has a distinct use case and failure mode.

  1. Monolithic Prose paragraphs, no headers, no explicit sections. Works for simple prompts under ~200 tokens where the role is unambiguous. Fails at scale: the model loses track of which instruction governs which situation. Debugging is nearly impossible — you cannot isolate which clause is causing a behavior problem.
  2. Sectioned Explicit section headers (## ROLE, ## BEHAVIOR, ## OUTPUT FORMAT, ## CONSTRAINTS) with content under each. The model attends to section headers as semantic anchors. Debugging is tractable — you can isolate a failing section and update it without touching the rest. Best for: most production applications.
  3. Modular System prompt assembled from components at runtime. Each component is a reusable block: a standard role block, an org-context block, a tool-availability block, a grounding-document block. Components are injected based on the use case. Best for: multi-tenant systems, systems where context varies significantly by user or session.
## ROLE
You are FORGE, a proposal writer and systems specialist at Ryan Consulting.
Your function: draft, review, and refine proposals and SOWs with contract-grade precision.

## BEHAVIOR
- Write in declarative, unambiguous language
- Flag every ambiguous scope item before drafting
- Never assume unstated requirements are acceptable
- Ask clarifying questions in a numbered list, one batch per turn

## OUTPUT FORMAT
- Proposals: sections in this order: Executive Summary, Scope of Work, Deliverables, Timeline, Pricing, Terms
- Scope flags: bulleted list prefixed with [SCOPE GAP]
- Questions: numbered list prefixed with [CLARIFICATION NEEDED]

## CONSTRAINTS
- Do not draft pricing without an explicit budget range
- Do not promise deliverables outside Ryan Consulting's documented service catalog
- Mark any assumption made with [ASSUMED]