JacqOS versus Knowledge Layers

Knowledge layers are becoming a standard part of the agent stack. Their job is to make durable organizational context available to agents: documents, schemas, business semantics, citations, permissions, freshness rules, and retrieval plans.

That is valuable infrastructure. JacqOS does not try to replace it, and you do not have to choose one or the other. A knowledge layer can be a strong addition to a JacqOS agent system.

JacqOS sits at a different boundary. A knowledge layer helps an agent remember and retrieve what the organization knows over the long term. JacqOS records what entered the agent’s working context, what the system derived from it, and which decisions or effects depended on it.

Put another way: a knowledge layer manages long-term memory. JacqOS lets agents use that memory while making the short-term memory used for decisions observable, replayable, and constrained by your invariants.

What counts as a knowledge layer

Recent examples include:

Pinecone Nexus and KnowQL, which Pinecone positions as a knowledge engine and declarative query interface for agents.
Pinecone Assistant, which packages ingestion, retrieval, query planning, reranking, answer generation, and citations as a managed knowledge service.
Microsoft Fabric IQ, the semantic intelligence layer for Microsoft Fabric, and Microsoft Foundry IQ, a managed knowledge layer for enterprise data.
Google Cloud Knowledge Catalog, which Google describes as an always-on context and governance layer for agents.

The details differ, but the category direction is clear. These systems build a trusted, permission-aware, semantically enriched memory surface for agents. They help answer questions such as:

Which source should this agent query?
What business meaning attaches to this table, document, or entity?
Which facts are current, governed, or permissioned for this user?
Which citations or source references support the retrieved answer?

JacqOS wants those systems to get better. Better long-term knowledge gives the agent better material to work with, and JacqOS gives the rest of the system a record of exactly when and how that material was used.

Use the knowledge layer as a tool

In a JacqOS app, a knowledge layer is often best modeled as a declared external capability that an agent can choose to use.

For example, an LLM-driven support agent might decide that it needs the current refund policy before proposing an action. The agent asks the shell to query the knowledge layer. The shell executes that declared capability, gets back a response with citations and metadata, and records the result as a new observation. From there, JacqOS treats the returned context like any other evidence: mappers extract atoms, rules decide what can be accepted, and any action proposal still has to satisfy your domain invariants.

That means the knowledge layer remains useful at the moment the agent needs it. It is not bolted on outside JacqOS, and it is not hidden inside a prompt. It is part of the same observation/effect loop that makes the rest of the agent system inspectable.

The boundary JacqOS owns

JacqOS starts caring when information from a knowledge layer enters a running agent system.

At that moment, the question changes. It is no longer just “what does the organization know?” It is:

What exact knowledge-layer query was made?
What response came back?
Which citations, permissions, timestamps, and confidence signals came with it?
Which derived facts accepted that response as evidence?
Which proposed actions relied on those facts?
Which invariant allowed, blocked, or escalated the action?

JacqOS answers those questions by routing retrieved knowledge through the same pipeline as every other input:

Observation -> Atoms -> Facts -> Intents -> Effects -> new Observations

The knowledge-layer response becomes an observation. Mappers turn it into structured atoms. Rules may derive facts from those atoms, often through the candidate.* relay if the retrieved content is fallible or needs acceptance. If an agent proposes an action based on those facts, that action still lands in proposal.* and must be ratified before any executable intent.* can fire.

The imported knowledge can inform the decision. It does not become invisible decision state.

Long-term memory versus decision memory

The distinction is easier to see as a table.

Question	Knowledge layer	JacqOS
What does it optimize for?	Durable enterprise context, retrieval, semantic meaning, citations, governance	Runtime evidence, derivation, decision containment, replay, provenance
What kind of memory does it manage?	Long-term organizational memory	Short-term decision memory for the current lineage
What is the main output?	Retrieved, assembled, or structured knowledge	Observations, derived facts, intents, effects, and receipts
How does an agent use it?	As a queryable source of context	As a declared effect/tool whose response re-enters the observation log
Who owns source truth?	The knowledge layer and its governed source systems	The observation log records exactly what the runtime consumed
Who owns action authority?	Usually outside the knowledge layer	JacqOS invariants and decision rules
What do operators inspect?	Sources, citations, permissions, retrieval quality	The query/response observation, derivation path, blocking invariant, and effect receipt

The important point is that the two layers are not competing for the same job. They meet at the point where knowledge becomes evidence in a decision.

How they work together

A typical integration looks like this:

An agent decides it needs external context and derives or requests a knowledge-layer query through a declared capability.
JacqOS executes the query as an effect through the shell.
The query, caller identity, source scope, citations, and response are written back into JacqOS as an observation.
A mapper emits atoms for the returned claims, citations, timestamps, confidence scores, ACL scope, or source identifiers.
The ontology decides which atoms are accepted as facts, which remain candidates, and which require human review or another source.
Any model-suggested action based on those facts goes through the proposal.* relay.
Invariants decide whether the resulting transition is allowed.
Any downstream effect receipt comes back as another observation.

That gives you the benefit of the knowledge layer without losing the decision trail. If an action is later challenged, the review path includes the external knowledge that influenced it, not just the final answer.

What JacqOS does not claim

JacqOS does not prove that an external knowledge layer returned true information. It does not replace source-system governance, access control, metadata quality, or retrieval evaluation. If a knowledge layer retrieves stale policy, JacqOS cannot make that policy fresh by recording it.

What JacqOS can do is make the use of that retrieved policy explicit:

The stale response is visible as an observation.
The accepted facts derived from it carry provenance.
The action that depended on it carries a decision path.
Fixtures can replay the same sequence.
Invariants can block known-bad transitions even when the knowledge is incomplete or misleading.

That boundary matters. A knowledge layer can make context more reliable. JacqOS makes the runtime’s use of that context accountable.

When to use both

Use a knowledge layer when the hard problem is long-term context:

proprietary documents and policies
semantic models and business definitions
governed enterprise search
source selection and citations
retrieval quality over a large corpus

Use JacqOS when the hard problem is runtime authority:

deciding whether retrieved knowledge may become accepted fact
proving which evidence supported a decision
blocking unsafe actions before they touch the world
replaying the decision from the same observations
showing operators why an action was allowed, blocked, or escalated

Most production agent systems need both. The knowledge layer gives the agent a better memory. JacqOS makes the memory used for action visible enough to audit.