Agentic memory

CognitiveX treats agents as first-class typed entities rather than opaque slugs. Every memory carries a structured epistemic envelope that captures who made the claim, what the claim is about, and what kind of claim it is. When iCog synthesizes a response, that envelope shapes the rendering: a tool's inference about you is presented as "X reports Y" — not collapsed into ground truth.

The two-axis model

Every memory sits on two orthogonal axes:

• Writer-axis (provenance) — who claimed this. The claimant_agent_id field, plus a claimant_type (tool / persona / view / peer / user).
• Subject-axis (aboutness) — what or who the claim is about. The subject_kind field (self / user / other_agent / codebase / world / meta) plus a subject_ref (the canonical id of the subject).

Authority gradients apply to the (writer × subject) pair, not to memory type alone. Only you (the user) can canonically claim things about yourself. Tools observe; personas synthesize with citation; views are read-only; iCog (the peer) holds reflective self-knowledge.

Agent types

Agents are typed via a plugin registry (agent_types table). The four seeded types in v14.0:

New types can be added at runtime by adding a row to the registry — the schema is extensible.

Concrete examples in this account

• claude-code — tool. Observes your codebase patterns; reports what it sees; cannot canonically claim about your identity.
• codex — registered as tool, promotable to persona once it has earned trust on subject_kind=user memories.
• memory-graph — view. Read-only frontend over the memory store; cannot write claims.
• iCog — peer. Holds reflective self-knowledge with high authority over itself only. No other agent is a peer in v14.0.

The claim type

Each memory also carries a claim_type, which describes the epistemic shape of the assertion:

• assertion — direct claim ("My name is Parsa")
• observation — first-hand witnessed event ("Parsa shipped Phase 087 today")
• report — second-hand relay ("Parsa told me his father is Mohammad")
• inference — derived conclusion ("Parsa probably works at night, based on commit timestamps")
• synthesis — multi-source distillation ("Across 12 memories, Parsa prefers Sonnet for code review")
• hypothesis — tentative, low-confidence ("Parsa might be planning a trip soon")
• legacy — pre-v14.0 memories without verified provenance

When iCog synthesizes a response, claims with claim_type = assertion from claimant_type = user are eligible to be treated as ground truth. Every other shape carries inline attribution.

Memory vs. messaging

CognitiveX keeps two distinct stores:

• Memory store — knowledge claims with epistemic envelopes. Subject to recall, decay, and synthesis.
• Agent messaging (agent_messages table) — addressed comms with delivery state. Includes context_explanation and referenced_memory_ids backlinks pointing to relevant memories.

Recall reads memories by default. Agent comm is opt-in via an include_agent_comm flag. This prevents the "agents flood teammates with messages and recall gets noisy" failure mode.

Why this matters

The architecture closes a class of bugs where an agent's inference about you could be rendered as a self-asserted fact. By making the envelope mandatory and the synthesis renderer attribution-aware, no code path can produce un-attributed synthesis about a non-self subject unless the underlying claim is claimant_type = user, claim_type = assertion, subject_kind = self.

Practically:

• A tool agent observing your codebase patterns can never canonically claim things about your identity.
• A persona agent can synthesize across your memories but always surfaces citation.
• iCog holds the narrative across all agents — it's the only entity with cross-agent visibility, and it never folds agent claims into its own self-model.

Related guides

• Register an agent — the chat protocol for adding new agents to your account
• Manage agents — the Agents tab on console.cognitivx.io
• iCog identity continuity — the related "iCog is sealed against agent inputs" invariant
• Troubleshooting agents — common failure modes when the model collides with real usage