How is shared context different from a shared database?

A single OLTP database is shared storage, but it rarely holds the context decisions need — the derived signals, aggregates, and semantic representations that get pushed out to caches, feature stores, and indexes precisely because the primary database can't serve them at decision speed. Sharing re-fragments at that layer. Shared context means the derived and semantic layer itself is the common read surface, with snapshot semantics across everything it serves — not just the raw rows.

Doesn't a shared layer become a bottleneck?

That is the historical reason state was copied per-service, and it's a fair engineering constraint: a shared context layer must serve concurrent reads at cache-like latency while ingesting high-velocity writes, or teams will rationally re-introduce private copies. The architectural point stands regardless of implementation: divergence between copies is structural, so systems that need coherent concurrent decisions must either share a snapshot or accept and price the incoherence.

Is shared context the same as shared memory for AI agents?

It's the generalization. Agent "shared memory" usually means agents reading and writing a common store so they can coordinate. Shared context adds the coherence requirement: concurrent agents don't just access the same store, they observe the same version of state — including derived signals — so two agents reasoning about the same entity at the same moment don't plan against different realities. Without that property, shared memory reproduces the same divergence problem services have.

Glossary

Context Vocabulary

What Is Shared Context?

Shared context is the property that every service and agent in a decision system reads from one context layer under a single, internally coherent snapshot — so all concurrent readers see the same version of state at the same moment. It is the alternative to the default architecture in which each service maintains its own cache, projection, or feature pipeline, each sitting at a different propagation stage and each holding a slightly different version of reality.

Updated Aug 24, 2026

What is shared context?

Shared context is one of the three capabilities that define a Context Lake in Tacnode's vocabulary, alongside live context and semantic context. Its job is to end inconsistent reads: the incoherence that arises when a decision's inputs are scattered across systems that cannot be read under one snapshot.

The contrast is architectural. In a composed stack, "sharing" state means copying it — each service subscribes to the event stream and maintains a private materialization. The copies are individually reasonable and collectively incoherent: the fraud service's view is three seconds behind the stream, the authorization service's is one second behind, and nothing in either service can observe the divergence. Shared context replaces the copies with a common read surface: events are ingested once, and every reader — human query, service call, agent tool-call — is answered against the same internally coherent snapshot. The canonical treatment is the shared context pillar.

What shared context changes

The shift is from narrowing divergence to eliminating the divergence class:

One ingestion path replaces N per-service pipelines, so there is a single propagation stage instead of N different ones.
Snapshot semantics span readers — two services querying the same entity concurrently receive answers from the same version of state, which is the definition of decision coherence.
The unobservable failure disappears — cross-service incoherence can't be monitored per-service, because each copy looks healthy locally; with one read surface there are no copies to disagree.

What shared context does not claim: it does not put the layer in the write path of external systems of record. Ingestion from upstream systems remains asynchronous — the guarantee is that all readers share one view of ingested state, not that the view is synchronous with upstream commits.

Why shared context matters

Concurrency is what turns private copies from an inefficiency into a correctness problem. One stale cache produces occasional stale reads; five services with independently lagging views of the same account produce contradictory simultaneous decisions — one arm approving what another arm just blocked, combined approvals exceeding a shared limit, fraud probes racing the services at their different lag stages. That failure pattern is dissected in context under concurrency. As AI agents multiply the number of concurrent readers and the speed at which they act, the cost of unshared context scales with them.

FAQ

Related terms

Context Lake

A Context Lake is real-time, multi-modal context infrastructure that gives AI agents and decision systems fresh, internally coherent context at decision time.

Context Gap

A context gap is the difference between the state of the world an automated decision acts on and the actual state at the moment the decision commits.

Decision Coherence

Decision coherence is the property that concurrent automated decisions act on the same version of shared state, instead of contradicting each other.

Cache Coherence

Cache coherence keeps multiple copies of shared data consistent across CPU caches or distributed services, so every reader sees the same value after a write.

Live Context

Live context is decision context kept close to current: reads hit the latest committed data, and derived state refreshes incrementally, typically every few seconds.

Semantic Context

Semantic context is the meaning-bearing layer of decision context — aggregations, vector similarity, LLM-derived signals — computed from the same events.

What is shared context?

What shared context changes

Why shared context matters

FAQ

Related terms

Further reading