Inside Cure8

Cure8 is the knowledge layer underneath our agent work. It takes what an agent or a person has learned and turns it into something a future agent can load cleanly and on demand -- without the noise, redundancy, and drift that accumulate in uncurated knowledge systems and degrade agent performance over time. It also maintains a structured intelligence registry: a curated feed of current research, litigation, and regulatory developments, and an evidence graph that powers clinical AI signal monitoring at the core of the Cortivus platform. This brief walks through how information moves through the system and why disciplined curation at the point of ingestion produces fundamentally better results than retrieval-time heroics.

The defining constraint is not the size of a model's context window. The binding question is how much of what gets loaded is actually signal rather than noise -- and whether the knowledge base has been kept current or left to drift. Larger windows have not resolved this. They have raised the ceiling for waste. Irrelevant, redundant, and stale content degrades answers regardless of how much room the window has to absorb it. The problem is not capacity. It is curation.

Most memory systems respond to that constraint by dumping everything into a vector store and doing the hard work at retrieval time: chunking, embedding, scoring, reranking, fusion. Cure8 inverts it. The intelligence is spent once, when knowledge is written, distilling each source into a small, high-signal unit. At runtime the agent simply loads the unit it needs. There is no reranking gauntlet on the critical path of every request.

Spend intelligence at write time, once. Keep runtime dumb, fast, and deterministic.

Two sources, one hub

Knowledge does not enter Cure8 through a single pipe. Two independent sources feed the same engine in a hub-and-spoke arrangement. They are not stages in a sequence and neither passes through the other. Each fires on its own cadence and lands at the same hub.

Cure8 is origin-aware: each source retains its own provenance, update cadence, and curation contract independently. Machine-gathered intelligence and human scientific contribution never get flattened into an undifferentiated stream where the source of a claim -- and when it was last verified -- can no longer be determined. That traceability is what makes curated knowledge trustworthy rather than merely plentiful.

The engine: one intelligent step in a deterministic pipeline

Inside the hub, the work splits cleanly into two kinds. The first is bookkeeping, and it is done deterministically. The curator scans its source list, compares modification timestamps, and hashes source content. Anything whose hash is unchanged is skipped entirely. No model is consulted about what is stale or what has changed; that decision reduces to timestamp comparison and hash arithmetic -- reproducible to the bit.

The second kind is genuine compression under judgment, and it is the only place a model is used. For each changed source, exactly one LLM call distills the material into a compressed, high-signal entity -- current, authoritative, and tagged with high-specificity identifiers for deterministic retrieval. Outdated content is replaced outright, not accumulated. An agent loading a Cure8 entity gets the current state of that knowledge, not a layered accumulation of prior versions competing for its attention. One call per changed source, never a swarm. The test is simple: does this step require judgment under uncertainty? If yes, a model handles it. If no, a script does. Most infrastructure work that looks intelligent is really bookkeeping, and Cure8 treats it accordingly.

The output: a book, materialized as a wiki or a database

The curated entity lands in a book: an isolated collection scoped by token volume rather than by topic. Books never reference each other. Cross-book relationships, when they matter, are resolved at runtime by the model and the human, not encoded as a synthetic graph that has to be maintained.

How a book is physically materialized depends on how it will be consumed. A book meant for human reading can be rendered as a browsable wiki. A book meant for agent retrieval is better held as structured records in Cure8's store and served entity-by-entity, so an agent browses a terse index and pulls only the one or two entries it needs. The same curated content supports both materializations -- the choice is made by the consumer, not imposed by the architecture.

Curation in practice: two lanes, one reviewer

The abstract principle of spending intelligence at write time becomes concrete when tracking a fast-moving domain like clinical AI. A scanner agent monitors relevant sources continuously -- litigation filings, published research, industry news, regulatory guidance -- scores each item for relevance, and delivers it to Cure8 as a proposed item. Nothing is published automatically. A relevance score is a starting point for human judgment, not a substitute for it.

A human reviewer opens the Work tab, sees the proposed queue sorted by score, and routes each item to exactly one lane:

The two lanes are mutually exclusive by design. An item approved for the News Feed is a current-events entry. An item approved for The Signal becomes a structured evidence record that updates the effect graph. Conflating the two would mean losing the structure that makes The Signal useful for tracking how clinical evidence around a topic accumulates and shifts over time.

The AI assist in the evidence lane

When a reviewer routes an item to The Signal, Cure8 fires a second LLM call before showing the promotion form. The model reads the item's headline, summary, key findings, and signal concept hints extracted during scanning, then scans the existing effect mode graph for the topic and proposes connections: which modes this item provides evidence for, what direction and magnitude the evidence suggests, and what the most relevant quote is. Where no existing mode matches semantically, it proposes a new one with a draft name and polarity.

The result lands in a pre-filled promotion form. Each proposed connection is labeled MATCHED (the model found an existing mode in the graph) or NEW (a proposed addition to it). The reviewer edits name, polarity, contribution type, and evidence strength for each connection, removes connections that do not hold up under review, and confirms. The model does first-pass pattern matching at scale; the human decides what the evidence actually says and whether it is strong enough to stand in the graph.

The model finds the patterns. The human decides what is true.

Publishing is a separate, explicit step for both lanes. Approved items sit in their respective queues until the reviewer triggers a publish. The News Feed JSON and the Signal effects JSON are written to Cortivus platform endpoints on demand. Separating approval from publication gives the reviewer time to batch, review, and adjust before anything reaches consumers.

Two update contracts

A book's contract determines how new information enters it and how it ages. Two contracts cover the cases that matter.

Why this is different from other memory systems

Most agent memory systems in circulation, whether vector-store RAG, Mem0, Honcho, or the long-context "just stuff it in the window" approach, share a posture: capture broadly, then spend effort at read time deciding what is relevant. They are retrieval-first. Their sophistication lives in chunking strategy, embedding models, rerankers, and decay heuristics, all of which run on the hot path of every query. Cure8 is curation-first, and the difference is not cosmetic. It changes where cost, error, and determinism live.

The honest tradeoff: Cure8 asks for discipline at write time that retrieval-first systems let you skip. You cannot dump a folder and walk away. In exchange, the runtime is cheap and predictable, the store stays small and high-signal, and when something is missing, it is missing in a way you can locate -- because gap detection is deterministic rather than a confidence score. For an operator who would rather invest the effort once, up front, than absorb a small cost on every call, that is the right side of the trade. For a throwaway corpus that no one will curate, a conventional vector store is the lower-effort choice. Naming the tradeoff is the point; an unnamed one becomes invisible debt.

More briefings