Skip to Content
StudioContext DesignContext Priming

Context Priming

Context Priming is the deliberate practice of setting up, building out, and maintaining the static documentation that drives the Studio of Two.

While runtime tools like Context-Pipe and Semantic-Sift manage the low-level, automated data flows, Context Priming defines the foundational knowledge base. It establishes the rules, constraints, and architecture that the Agent must understand before executing any tasks.

The Four Pillars of Context Priming

To build an AI-ready codebase, you must maintain four essential priming documents. These files act as the static “Quality Envelope” for all agent interactions.

1. Agent Instructions (Identity & Constraints)

The core guidelines that define the agent’s personality, workflow, and operational limits. Rather than relying on generic system prompts, we use explicit workspace files like AGENTS.md to define:

  • Roles & Voice: Distinguishing between structural roles (e.g. The Builder) and content roles (e.g. The Content Architect).
  • Operational Guards: Active rules like the Interrogative Shield (which enters read-only mode if a question is detected) or loop-prevention protocols.
  • Precedence Rules: Outlining exactly which instruction set overrides the others when conflicts arise.

2. Design Systems (Syntactic Precision)

AI models excel at generating code but often fail at visual consistency. By priming the agent with a strict design system specification, you eliminate aesthetic guessing:

  • Core Tokens: Documenting exact brand colors, gradients, and interactive hover states (e.g. Indigo-500 for actions, Purple-to-Blue for headers).
  • Geometry & Elevation: Defining container rounding rules (e.g. rounded-2xl for containers, rounded-xl for buttons) and shadow elevations.
  • Assets & Icons: Specifying libraries (e.g. Material UI Rounded) and color opacity conventions. This prevents the agent from introducing random styling files or inline styles.

3. Architecture Specifications (Codebase Blueprints)

A living blueprint file (like ARCHITECTURE.md) ensures the agent writes code that respects the structure of your system:

  • Design Lineage: Explaining the core philosophy behind the codebase (e.g. explaining that a tool is modeled after Unix terminal piping).
  • Folder Boundaries: Mapping out where components, logic, types, and assets reside.
  • Communication Protocols: Explaining how systems interact (e.g. stdin/stdout streams, API routes, state sync).

4. Running State (Backlogs & Changelogs)

An agent needs to know what has been done and what to do next. We track the active running state of the project in real time:

  • Task Roadmaps: Files like task.md document phase-by-step progress, current blockers, and completed milestones.
  • Technical Audits: Keeping an active file listing lint errors, deprecated packages, or architectural debt. This guides the agent to fix root causes rather than patching symptoms.

Priming in Action: The Studio Rule

In the Studio of Two philosophy, we follow a strict rule: Prime the Rules, Stream the Data.

By separating the static rules (Priming) from the dynamic inputs (Pipes and Sifts), we keep the context window dense, cheap, and extremely high-fidelity.