Tacnode™
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

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

Further reading