Memory

Builder has a two-tier memory system that persists knowledge across builds. Agents query memory before generating output — so each build benefits from everything learned in previous builds.

Two-tier architecture

Tier	Store	Scope	Persists
Session	Redis	Current build only	Until build ends
Long-term	PostgreSQL	All builds, all projects	Permanently

What agents remember

Memory type	Example
Naming conventions	"This project uses snake_case for all database columns"
Stack decisions	"This team always uses FastAPI + PostgreSQL, never Django + MySQL"
Schema patterns	"Products table always includes soft delete with deleted_at"
Error resolutions	"JWT decode error in middleware — fixed by passing algorithms list explicitly"
Quality patterns	"Adding @pytest.mark.asyncio fixed all async test failures in this stack"
Rejection feedback	"User rejected Django twice — avoid suggesting it"

Effect on build quality

After 3–5 builds on related projects, Builder stops making the same architectural mistakes and reuses patterns that scored highly on the CTQ scorecard. Subsequent builds of similar projects are measurably faster and produce higher CTQ scores.

Memory API

# Store a memory explicitly (agents do this automatically)
POST /api/memory/memories
{
  "content": "This project uses UUID primary keys, not integer sequences",
  "project": "my-api",
  "tags": ["database", "schema"]
}

# List memories for a project
GET /api/memory/memories?project=my-api&limit=20

# Semantic search over memory
GET /api/memory/memories/search?q=database+conventions&project=my-api

# Most recently accessed memories (used by agents to warm context)
GET /api/memory/memories/recent

# Delete a memory
DELETE /api/memory/memories/{memory_id}

Memory and HITL

When you reject or modify a checkpoint, that feedback is stored as a long-term memory. The next build in the same project automatically avoids the rejected pattern — without you having to repeat the feedback.