Patterns

A pattern is a named synthesis of multiple related decisions into a reusable constraint. When the same approach appears across multiple components, a pattern captures the shared rule once.

When to use patterns

Patterns emerge when you notice repetition in your decisions. If three components all chose Redis for state management with the same connection strategy, the pattern state-in-redis captures that shared constraint: “shared pool via app state, no per-component connections.”

Future components that need state management get this pattern in their context brief automatically.

Recording a pattern

Via MCP (agent workflow)

The record_pattern tool accepts:

{
  "name": "state-in-redis",
  "description": "Shared Redis pool via app state, no per-component connections",
  "decisions": [
    "auth-redis-session-store",
    "rate-limiter-redis-sliding-window",
    "cache-redis-ttl-strategy"
  ],
  "tags": ["infrastructure", "state"]
}

Via the workflow engine

During the advance loop, the pattern_detection step runs keyword and theme analysis across decisions and suggests candidates when several share overlapping concerns — the agent or user then confirms them into a pattern. This step appears in most task sequences (see Workflow Engine).

Pattern requirements

• Minimum two source decisions (must already exist in the graph)
• All referenced decisions must exist — dangling references are rejected
• Pattern name must be unique and valid kebab-case
• Components are inferred from decisions if omitted

Patterns in context briefs

When get_context("rate-limiter") is called, any patterns that include decisions from rate-limiter appear in the PATTERNS section of the brief:

PATTERNS:
- state-in-redis: shared pool via app state, no per-component connections

Patterns provide cross-cutting constraints that individual component decisions cannot capture alone — a future component that needs the same approach gets the rule automatically.