Prompt as an Architectural Unit
Thinking in building blocks
Paradigm Shift
A prompt isn’t text — it’s a architectural unit with an interface, defined behavior contract, dependencies, and responsibilities.
Traditional View
- • Prompt = text that generates a response
- • Success = a “good” answer
- • Iteration = adjust the wording
- • Scale = copy and paste
Architectural View
- • Prompt = component with a contract
- • Success = predictable behavior
- • Iteration = refine the interface
- • Scale = composition and reuse
Anatomy of a Prompt as a Component
┌─────────────────────────────────────────────────────┐ │ PROMPT COMPONENT: "order_analyzer" │ ├─────────────────────────────────────────────────────┤ │ INTERFACE │ │ ├─ Input: OrderData, CustomerHistory │ │ ├─ Output: AnalysisResult (structured) │ │ └─ Errors: InsufficientData, AmbiguousOrder │ ├─────────────────────────────────────────────────────┤ │ CONTRACT │ │ ├─ Preconditions: order.status == "pending" │ │ ├─ Postconditions: result.confidence > 0.8 │ │ └─ Invariants: no side effects │ ├─────────────────────────────────────────────────────┤ │ DEPENDENCIES │ │ ├─ Requires: product_catalog (context) │ │ ├─ Requires: pricing_rules (context) │ │ └─ Optional: customer_preferences │ ├─────────────────────────────────────────────────────┤ │ IMPLEMENTATION │ │ └─ [prompt template with slots] │ └─────────────────────────────────────────────────────┘
Benefits of Architectural Vision
Mono-Prompt vs. Multi-Prompt Architectures
Deciding on the system structure
Mono-Prompt
A single prompt that handles all the complexity. Full context in one call.
Multi-Prompt
Multiple specialized prompts that communicate. Decomposition of responsibilities.
Decision Matrix
| Criterion | Mono | Multi |
|---|---|---|
| Simple, well-defined task | ✓ | — |
| Multiple dependent steps | — | ✓ |
| Critical latency | ✓ | — |
| Component Reuse | — | ✓ |
| Decision traceability | — | ✓ |
Architectural Layers of LLM Systems
Separation of responsibilities
Layered Architecture
┌─────────────────────────────────────────────────────┐ │ PRESENTATION LAYER │ │ • Interface com usuário │ │ • Formatação de entrada/saída │ │ • Validação de input │ ├─────────────────────────────────────────────────────┤ │ ORCHESTRATION LAYER │ │ • Roteamento de requests │ │ • Composição de prompts │ │ • Gestão de fluxo │ ├─────────────────────────────────────────────────────┤ │ BUSINESS LOGIC LAYER │ │ • Skills especializadas │ │ • Regras de negócio │ │ • Transformações de dados │ ├─────────────────────────────────────────────────────┤ │ CONTEXT LAYER │ │ • Gestão de contexto │ │ • RAG / Retrieval │ │ • Memory management │ ├─────────────────────────────────────────────────────┤ │ MODEL LAYER │ │ • Abstração de LLM │ │ • Fallbacks │ │ • Rate limiting │ └─────────────────────────────────────────────────────┘
Principle: Separation of Concerns
Each layer has a single responsibility. Changes in one layer don't affect others. This allows independent evolution.
Principle: Dependency Inversion
Higher-level layers don't depend on specific implementations. Abstractions let you switch LLMs or data sources.
Behavior Contracts Between Prompts
Guarantees and expectations
Contracts define what a prompt ensures it gets done and what it expects to receive. Without contracts, prompt systems are fragile.
Elements of a Contract
Preconditions
What must be true BEFORE calling the prompt.
input.length < 10000
Postconditions
What will be true AFTER execution.
output.format == "json"
Invariants
What NEVER changes during execution.
no_external_calls
Error Conditions
How failures are signaled.
throws: AmbiguousInput
Example of a Documented Contract
/** * @contract SentimentAnalyzer * * @precondition text.length > 0 && text.length < 5000 * @precondition language in ["pt", "en", "es"] * * @postcondition result.sentiment in ["positive", "negative", "neutral"] * @postcondition result.confidence >= 0.0 && result.confidence <= 1.0 * @postcondition result.reasoning.length > 0 * * @invariant deterministic for same input (temperature=0) * @invariant no PII in output * * @throws EmptyInputError if text is empty * @throws UnsupportedLanguageError if language not supported * @throws LowConfidenceError if confidence < 0.5 */
Recurring Architectural Patterns
Proven solutions
Chain of Responsibility
Chained prompts where each one can solve the issue or pass it along.
Pipeline
Sequential transformations where one’s output is the next one’s input.
Supervisor
A prompt coordinates and validates the work of other prompts.
Reflection
Prompt analyzes and iteratively improves its own output.
When to Use Each Pattern
Analysis of Real Architectures
Production case studies
Case: Technical Support Assistant
USER QUERY
│
▼
┌─────────────────┐
│ INTENT ROUTER │ ← Classifica intenção
└────────┬────────┘
│
┌────┴────┬────────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌──────────┐
│ FAQ │ │TROUBLE│ │ ESCALATE │
│ MATCH │ │ SHOOT │ │ TO HUMAN │
└───┬───┘ └───┬───┘ └────┬─────┘
│ │ │
└────┬────┴──────────┘
▼
┌─────────────────┐
│ FORMATTER │ ← Formata resposta
└────────┬────────┘
▼
┌─────────────────┐
│ SAFETY CHECK │ ← Valida antes de enviar
└─────────────────┘
Case: Code Review System
PR DIFF
│
▼
┌─────────────────────────────────────┐
│ SUPERVISOR │
│ "Coordinate review, aggregate" │
└────────────────┬────────────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│SECURITY│ │ STYLE │ │ LOGIC │
│ CHECK │ │ CHECK │ │ CHECK │
└───┬────┘ └───┬────┘ └───┬────┘
│ │ │
└─────┬─────┴───────────┘
▼
┌─────────────────────────────────────┐
│ AGGREGATOR │
│ "Consolidate, prioritize issues" │
└────────────────┬────────────────────┘
▼
┌─────────────────────────────────────┐
│ FORMATTER │
│ "Format as GitHub PR comment" │
└─────────────────────────────────────┘
Exercise: Analyze the Architecture
For each case study, identify:
- 1. Which architectural pattern was used?
- 2. What are the contracts between components?
- 3. Where are the failure points?
- 4. How would you improve the architecture?