Skip to content
Pyrana
For engineers and architects
cortIQ
Context engineering
Provenance

Workflows aren't enough: why knowledge is the moat

Orchestration is mostly solved. What is not solved is an agent that knows what the business knows and can prove where each claim came from. Here is what a context unit has to carry, how retrieval should account for it, and what to ask of any context layer.

Eric Tarnowski
September 9, 2026
8 min read

You have the orchestration. Temporal or LangGraph, retries, a DAG that fans out and joins, an agent that resumes after a crash. And it still tells the controller that the capitalization threshold is 5,000 USD, because the chunk it retrieved came from the 2024 handbook, and nothing in the system knew that policy moved to 2,500 USD in March.

The workflow ran perfectly. The knowledge was wrong, and nobody could say why.

Orchestration is solved, more or less

I wrote last year that orchestration on its own does not get you an application (https://pyrana.ai/resources/orchestration-not-enough-agentic-applications). Since then the substrate has only gotten better. Temporal's OpenAI Agents SDK integration went GA in March 2026, running the agent loop as a workflow and each agent invocation as an activity (Temporal, "Production-ready agents with the OpenAI Agents SDK + Temporal"). If your agent dies mid-task and starts over, that is a choice.

What remains unsolved is quieter. An agent that knows what the business knows, at the granularity the business changes it, and can show where each claim came from. That is the part that compounds, because every application you build on top of it starts with the same memory.

RAG gives agents amnesia with citations

Standard retrieval-augmented generation has four structural problems, and none of them is fixed by a better embedding model.

The chunk is the wrong unit. Chunks are sized for the embedder, and a 512-token chunk of a finance policy holds a dozen claims. One of them is stale. The citation points at the chunk, so the citation is technically correct and practically useless.

There is no provenance chain. "Document X, chunk 14" tells you where the text sat. It does not tell you the document version, which extraction produced the claim, or whether a newer document replaced it.

Retrieval is session-blind. Turn three retrieves the same chunk as turn one, and the useful thing on page 40 never makes it in.

Nothing learns. When the answer is wrong, the correction lives in a Slack thread. The vector store is exactly as confident tomorrow.

The industry has a name for the discipline that addresses this. In June 2025 Tobi Lütke called context engineering "the art of providing all the context for the task to be plausibly solvable by the LLM," and Andrej Karpathy sharpened it to "the delicate art and science of filling the context window with just the right information for the next step" (The Context Graph, "Context Engineering in 2026"). Anthropic's engineering team formalized it that September as "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference," with the rule that context "must be treated as a finite resource with diminishing marginal returns" and the recommendation to load data just in time through lightweight identifiers rather than front-loading everything (Anthropic, September 29, 2025).

I agree with all of that. I would add one thing the definitions leave implicit: you cannot curate what has no identity. Context engineering needs a unit of knowledge with a stable name, evidence attached, and an account of what happened to it on every run.

What a unit of knowledge has to carry

Whatever you build or buy, the unit should have these properties.

It is atomic. One claim, stated so it can be true or false on its own. "Purchases under 2,500 USD are expensed in the period incurred" is a claim. A paragraph about capitalization policy is a container.

It carries verbatim evidence with offsets. The exact quote that supports the claim, with character offsets into a specific version of a specific source. Paraphrase is not evidence.

It has a provenance chain. Source and version, the chunk it came from, and the extraction lens that produced it, so a reviewer can walk from claim to text in one click.

It has a content identity. A hash over the immutable surface of the unit, so two stores can refer to the same claim by the same name and a citation is an exact reference rather than a title match.

It has lineage. A unit can supersede another. Retrieval should prefer the successor, and the predecessor should remain addressable for anyone auditing an answer given last quarter.

It has a governance class. Regulated policy is not the same as a sales note, and the system should be unable to retire the first on the same signal that retires the second.

Some units are always on. A scoped floor of policy context that every relevant run gets regardless of similarity score.

And every run keeps the accounting: what was retrieved, what actually entered the prompt, what the model cited, and anything the model cited that it was never given.

How cortIQ does it

cortIQ (formerly the Context Engine) is the layer under every Agentic App on Pyrana. Documents and system data pass through chunking, parallel lens extraction, validation, and deduplication, and come out as Context Units. A CxU holds the claim, its supporting contexts with verbatim quotes and source offsets, a knowledge type, a classification, keywords, parameters, an evidence strength, provenance, and separate lifecycle metadata.

# illustrative Context Unit
cxu: cxu:1220a7ff…f843
claim: "Purchases under 2,500 USD are expensed in the period incurred."
knowledge_type: policy
classification: regulated
evidence_strength: 0.94
supporting_contexts:
  - source: fin-policy-2026.pdf@v3   chunk: 41   offset: [1180, 1263]
    quote: "Purchases under $2,500 are to be expensed in the period incurred."
replaces_cxu_hash: cxu:8e02…19d1     # the 5,000 USD rule from the 2024 handbook
keywords: [capitalization, threshold, expense]

The identity is a SHA-256 over a canonical eight-field surface: claim, classification, evidence_strength, keywords, knowledge_type, parameters, replaces_cxu_hash, and supporting_contexts. The recipe applies Unicode normalization, whitespace trimming, recursive key sorting, and sorted keywords and supporting contexts, so equal surfaces hash equal across stores. It does not claim that two paraphrases of the same idea hash the same; that is a different problem. Status, quality scores, access, review, promotion, and challenge state are mutable and stored apart from the immutable core, so a review does not change the unit's name.

Postgres is the source of truth. Neo4j holds relationships and traversal. Qdrant holds vectors. Retrieval runs templated Cypher, edge-filtered Cypher, generated Text2Cypher, vector search, full-text search, and named-relationship traversal, then fuses candidates with reciprocal-rank fusion. Relationship-level Q-values can influence rank and a cross-encoder rescores query and claim pairs. Low-confidence results escalate to deeper graph traversal. Rank-0 units, the policy floor, are always included within their scope.

On the Pyrana side, an agent calls context_search. The request carries the run identity, dimensions, limits, rank-0 posture, and the unit identifiers already retrieved in this run, so cortIQ suppresses duplicates across turns. The agent suspends while a durable activity carries the request over Redis Streams; the response lands as deterministic Markdown in the run's file system and a slim result resumes the agent.

Then the accounting. For every run Pyrana derives three tiers: retrieved (cortIQ returned it), injected (it entered the prompt), cited (the model named it as support). The invariant is retrieved ⊇ injected ⊇ cited. If the model cites an identifier it was never given, that goes into cited_unknown rather than being quietly added to the known set. A typical run on the close App looks like retrieved 12, injected 6, cited 2, cited_unknown 0. Citation-required finish validation can be switched on where an App needs it.

To be precise about what this proves: which units were in front of the model and which it named. It does not prove entailment, and it does not prove the model's reasoning depended on the cited unit. It does give you a mechanically checkable provenance trail, which is what an auditor asks for.

The accounting is also what makes learning honest. "Retrieved but never injected" is evidence about ranking. "Injected and cited, and the answer was wrong" is much stronger evidence about the knowledge itself. cortIQ keeps a relationship-specific Q-value for the first kind of signal and a separate Bayesian quality score for the second, and governance classification bounds both: a regulated unit cannot be retired automatically because usage signals were weak. Repeated retrieval failures aggregate into knowledge-gap signals that propose ingestion work rather than inventing an answer.

Status, honestly: extraction, the graph, retrieval, the hash, and the retrieved, injected, cited accounting are live. The feedback publisher that carries a run's outcome back to the exact unit and relationship, and the update rule that ships with it, are near-term. Today the loop is closed by people reading the accounting. The next step is closing it in software.

The other context layers, fairly

Several good companies are working on adjacent problems.

Contextual AI sells a unified context layer and a grounded language model trained to stay faithful to retrieved text, with inline attributions and sentence-level citations into source documents (VentureBeat, January 27, 2026; Contextual AI, March 4, 2025). That is real progress on faithfulness. The citation points into a document; I have not seen a published claim-level identity, a supersedes chain, or an injected-versus-cited account.

Glean's knowledge graph is permissions-aware and connects content, people, and activity across the SaaS estate (Futurum, April 3, 2026; Glean documentation). For search over what your company has written, it is the right shape. Its unit is the document and the person, not the atomic claim with evidence.

Pinecone Nexus, in public preview since July 2026, has subject-matter experts design blueprints and compiles distributed knowledge into a structured layer that agents query, moving token spend "out of the per-query retrieval loop and into a one-time curation step" (InfoQ, July 18, 2026). This is the nearest in spirit to what we do. The questions I would ask are what the compiled unit is, whether it carries verbatim evidence and lineage, and what happens to it when an answer turns out wrong.

Celonis's Context Model is "a dynamic, real-time digital twin of operations" built from process and event data (Celonis, May 12, 2026). Where the knowledge is in the event log, that is a strong foundation. The capitalization policy is not in the event log.

Each of these solves the problem it set out to solve. The gap I keep seeing is the same one: a unit with identity and evidence, an account of what the model was given, and a learning rule that regulation can veto.

A design checklist for a context layer

Before you build one, or before you sign for one, get written answers to these.

  1. What is the unit, and does it have a content identity you can cite across systems?
  2. Does each unit carry verbatim evidence with offsets into a versioned source?
  3. Can a unit supersede another, and does retrieval prefer the successor while keeping the predecessor addressable?
  4. Is there an always-on floor for policy context, and is it scoped?
  5. Per run, can you produce retrieved, injected, cited, and unknown, and is the containment invariant checked?
  6. Is authorization applied before results are returned, so an unauthorized unit is absent rather than redacted?
  7. What signal retires a unit, and which class of unit is immune to that signal?
  8. Where does a knowledge gap go when retrieval keeps failing?

If the answer to question 5 is "we log retrievals," the layer cannot tell you why the controller got the wrong threshold. Jamey's blueprint for Context Units goes deeper on the schema itself (https://pyrana.ai/resources/context-units-blueprint-architecture). Start there, then ask your vendor question 5.

Sources

Continue the Conversation

Building production-grade agentic AI requires context, orchestration, and human-in-the-loop design. We'd love to show you how Pyrana delivers it end to end.

Request a Demo