Mental model

CCD-Suite is built on a single deliberate pattern: every agent run sees a four-namespace context plus the knowledge graph. Once you internalize this, the rest of the product makes sense.

The four namespaces

When an agent boots, the platform assembles four blocks of context and renders them into the system prompt. The agent always has access to all four; they never go away mid-run.

┌──────────────────┐
│  MEMORY          │  What happened. Episodes from past runs +
│                  │  semantic facts promoted from them.
├──────────────────┤
│  SKILLS          │  How to do things. Playbooks the orchestrator
│                  │  pulled in for this kind of task.
├──────────────────┤
│  TASKS           │  What's pending. Confirmation-gated actions
│                  │  not yet approved by the user.
├──────────────────┤
│  USER            │  Who's asking. Profile, preferences, the
│                  │  tenant context an agent always has.
└──────────────────┘

Each namespace is just a Markdown block in the prompt. The file projector writes them as actual files when self-host is configured for it — so what you see in the prompt and what an operator can edit on disk are literally the same thing.

Why four

Because conflating them produces bad behavior.

• Memory only — agent recalls every prior conversation, but has no way of knowing how it's supposed to handle the current request. Re-invents process every run.
• Skills only — agent has the playbook but no recall of what the user actually wants or what's happened before. Generic responses.
• No tasks — agent might re-execute an action that's still awaiting your approval. Double-sending emails, double-creating deals.
• No user — agent doesn't know your timezone, your role, your organization. Every reply is generic.

Four blocks, distinct purposes, clean separation. The orchestrator reasons over all four; subagents inherit them.

The knowledge graph

The fifth context — the foundation under the four namespaces — is the knowledge graph. It's a Postgres-backed graph of:

• Nodes — entities with embeddings: contacts, deals, accounts, campaigns, documents, conversations, anything.
• Edges — typed relationships between nodes (works_at, replied_to, belongs_to_campaign, etc.).
• Citations — every claim an agent makes links back to the nodes it pulled from. Click any number in the UI to see the source.

The agent doesn't query the graph directly. It calls graph_semantic_search (a Postgres RPC) which combines vector similarity, pg_trgm fuzzy text, and graph-walk filters into one ranked result set. See Knowledge graph for the full mechanics.

What this means in practice

Every surface in the app is a slice through the same pattern.

Same context model, different framing. That's why the orchestrator behaves consistently across surfaces — it's literally the same code path with different initial prompts.

Read next

• Memory — how episodic + semantic memory work and the promotion pipeline that keeps memory bounded.
• Skills — where playbooks come from and how the orchestrator decides which ones to pull.
• Knowledge graph — the data substrate everything else sits on.