Shared working memory that doesn't go stale.

Your team's decisions live in eight places.

The architecture call in a video transcript. The constraint in a Slack thread. The directive in a DM. The "we already tried that" buried under last quarter's archived ticket. Three people remember three different versions, and the agent helping with the next change has access to none of them. Static docs work for one repo, one author — they break the moment two people edit the same file or an agent writes back without anyone realizing.

One record. Many writers.

Whether the entry comes from a person in the dashboard, a Claude Code agent at end-of-session, or a CI hook via API key, it lands the same way and gets indexed the same way. Items are sliced into claim units; threads are extracted per unit; tags carry narrative continuity across people.

API keys for non-interactive callers (CI hooks, batch scripts). Dashboard chat for humans who'd rather talk than write JSON. MCP clients for everyone else.

Saved views the team authors.

A topic is a prompt-driven, always-current slice of the record. "Decisions in api made in the last 30 days." "Open inquires across all subjects." "Everything tagged #v2-release." The system threads the prompt and pulls every unit whose threads or tags overlap.

Scope narrows further — intent, subject, recency — layered on top. Topics re-materialize on every ingest, so the team's saved views stay current without anyone rebuilding them. The cluster proposer surfaces candidate topics from emergent thread communities; any member accepts the ones worth keeping.

Specs, transcripts, PDFs — alongside the substrate.

Documents live next to your knowledge base as versioned reference files — design specs, meeting transcripts, data dumps, PDFs. They're not ingested; they're linked. When an item is extracted from a source, the document link carries through — so the spec or transcript behind any decision is one hop away from the item that records it.

Any file type. Text and markdown are created and edited in-app; binaries are uploaded. Every edit creates a new revision; full history is preserved. Together with the threaded item graph, documents give your team a queryable record of both what was decided and what it was decided on.

State-check across writers.

When a new claim contradicts an older one, or a decision gets executed, or an inquire's premise dies, Pragmus proposes a resolution — with a per-intent verdict:

Per-unit, not per-item — an item can have some claims contradicted and others still standing. Each proposal lands in the review queue with the evidence that triggered it. Any member confirms or dismisses.

No one writes over anyone else's record. The audit trail keeps who, when, why, and on what evidence.

Every release closes a chapter.

When the team ships, a milestone marks the boundary. Done items archive in bulk; the snapshot of the topic tree is preserved. Quarter-end reviews, post-mortems, "what did we decide in Q2?" — one snapshot away.

Two workstreams. Zero cross-pollination.

Planning cycles, prototype branches, separate client engagements — give each one a sandbox. Items in a sandbox stay isolated from the main graph. Subjects, areas, and contributors are shared; only the items and topics are siloed.

Roles, scopes, share links.

Three roles — viewer (read-only), member (ingest, resolve, highlight, archive), owner (manage contributors, subjects, sandboxes). Member grants can scope writes to specific subjects (write_subjects) and reads to specific areas (read_areas): the data team writes under data and infra only; the compliance reviewer reads policy and audit only.

Share links generate a project-scoped read-only token — paste it into a browser to view the dashboard, or hand it to an MCP client so a guest agent gets read-only access to every read tool. Writes rejected. The audit trail captures who, when, and what the grant looked like at the moment of every write.