Ten days we have dismantled what an agent needs. Tomorrow it starts to
be built. And the first piece is the one that holds everything up: the knowledge
layer. It is not a repository. It is the deliberate integration of data,
semantics, ontology, entities, relationships and knowledge, with an owner,
metrics and a maintenance process.
Introduction
We have finished the first question of the series — what does an agent need? — and
the answer was long: data with meaning, resolved entities,
relationships, retrievable knowledge, typed memory and situated context.
Now the second question begins, and with it the register of the
series changes: how is the infrastructure that provides it built,
piece by piece?
And the first piece is the biggest: the knowledge layer. Everything
we have seen so far (semantics, ontology, entity resolution,
relationships, knowledge graph, RAG) are pieces of this layer. Today we
set them down together for the first time, as an architecture with a name, and not
as a collection of loose projects.
The problem
A manufacturing company has done, in three years, “everything that is said
there is to do”: a data lake, a data mart, a data glossary, a RAG
over the technical documentation, and a couple of attempts at a knowledge graph that
did not take hold. It has, in principle, all the pieces. And yet, when
it wants to deploy an agent for the engineering and quality area, it discovers
that the pieces do not touch each other:
- The RAG knows the manuals, but it does not know which manual applies to which
product, because that relationship is in another database. - The data mart has the production data, but with field names
that do not match the glossary. - The “knowledge graph” built in 2024 modeled the organization, not the
products, and nobody has touched it since. - The glossary is a 2022 Excel sheet that nobody has updated.
The problem is not the lack of pieces: it is that there is no knowledge
layer that integrates them with a common semantics, a domain model and
a maintenance process. There are five data projects, each one
half-working, and together they do not work.
The concept
The knowledge layer (knowledge architecture) is the architecture that
integrates, on top of the existing data systems, the pieces an agent
needs in order to understand the domain. It builds on what we have defined in the
first half of the series:
KNOWLEDGE LAYER
= DATA (source)
+ SEMANTICS (common meaning)
+ ONTOLOGY (domain model, constraints)
+ ENTITIES (entity resolution, canonical identity)
+ RELATIONSHIPS / KNOWLEDGE GRAPH (facts and connections)
+ KNOWLEDGE IN PROSE (RAG: manuals, policies, reports)
But integrated not as five projects, but as a layer with:
- One source of truth per concept. Each concept (a product, a
customer, a contract) has a declared canonical source. Not five
versions the agent has to “choose” from. - A domain ontology that joins them. The ontology (day 4) defines the
types of entity and relationship; the sources of truth populate them. - Entity resolution across sources. The canonical identity (day 5)
connects the records of different sources into the same entity. - A graph that materializes the relationships. The KG (day 7) is where
the concrete relationships become queryable. - A RAG for what is not structurable. The manuals, policies and
reports that do not enter the graph are indexed for the RAG (day 8), with
metadata that connects them to the graph (which product they apply to, which version,
which currency). - An owner and metrics. Someone is responsible for the layer being
correct and up to date, and there are metrics that measure it (coverage,
freshness, contradiction rate).
The knowledge layer does not replace the data lake nor the data mart: it builds
on top of them. The difference is one of purpose: the data lake exists to
analyze; the knowledge layer exists so that a system (an agent)
can understand the domain and act on it. That difference of purpose
is the one that explains why traditional data projects do not build it
by default.
Architecture
In the series diagram, the knowledge layer is the central block of
the cognitive infrastructure:
AGENTS
↓
REASONING
↓
┌───────────┴───────────┐
↓ ↓
CONTEXT MEMORY
└───────────┬───────────┘
↓
KNOWLEDGE ← TODAY: the knowledge layer
(graph + RAG + semantics
+ ontology + entities)
↓
DATA / ENTERPRISE SYSTEMS
The knowledge layer is the frontier between “the data the company
has” and “what the agent can comprehend”. It is the biggest piece in the
diagram, and the one that takes the longest to build, because it is the one that requires
business decisions (which concepts, which canonical sources, which rules) and
not only engineering ones.
Use case
The manufacturing company, with its engineering and quality agent.
We break it down:
- Problem. A lot of components enters quality control and the
team needs to know, quickly: which specification applies, which
deviations have been historically accepted for that type, and whether there is
any open non-conformity affecting the lot. Today it takes hours
to consult five systems. - Decision. Accept or reject the lot, and with which corrective actions.
- Knowledge needed. The component’s specification in force; the
acceptable tolerances; the history of accepted deviations for that
type; the open non-conformities affecting it. - Data. Specifications (gdoc), production data (ERP/MES),
quality history (quality system), non-conformities (management
system). - Relationships. Component → specification in force; specification →
tolerances; component → historical deviations; non-conformity →
affects → lot; lot → production lines. - Context. The lot is for a customer with a strict quality clause;
there is a certification review in progress; the quality technician is on
sick leave (a deputy with less context decides). - Memory. A similar lot last quarter was accepted with a
specific deviation and the justification; the non-conformity NC-2026-041
affects this type of component and is open. - Reasoning. Apply the specification in force to the lot; cross with
the historically accepted deviations (was this deviation already
accepted?); cross with the open NC-2026-041 (does it affect?); apply the
customer’s clause. - Action. Reject the lot due to the open non-conformity, with the
justification and the proposed corrective actions; notify the
supplier. - Infrastructure. The knowledge layer integrating specifications
- production + quality + non-conformities, with the ontology of the
quality domain, the entity resolution across systems and the graph of
relationships, plus the RAG for the specifications in prose. Without the layer
integrated, each query is a trip through five systems.
- production + quality + non-conformities, with the ontology of the
Trade-offs
- Cost. A well-built knowledge layer is a months-long project,
with business experts involved. It is not a sprint. - Complexity. The integration of five sources with a common semantics
is the 80 % of the work; the graph and the RAG are the 20 % visible. Underestimating
the integration is the most common error. - Sequencing. The whole layer is not built in one go. You start from
the domain that the first agent needs (in the case, quality), you
integrate it well, and you expand. The temptation to “model everything” is the one
that kills knowledge graph projects. - Maintenance. The layer has to be updated: new specifications,
tolerance changes, closure of non-conformities. Without a
maintenance process and an owner, it rots in a year and gives false confidence. - Source quality. The layer amplifies the quality of the sources: if the
ERP has dubious data, the layer inherits it. Source governance is
part of the design (day 18). - Honest limitation: the knowledge layer represents the
explicitable and structurable knowledge. The inspector’s experience who “knows”
that a deviation is acceptable because “it looks good” does not enter the layer
until it is made explicit. The layer improves the explicit; it does not replace it.
Implication for the company
For the CDO, the knowledge layer is the project that orders the five
loose data projects into an architecture with purpose. And it is a
project with an owner: without a person responsible for the layer, it is five owners who
are not owners of the integration.
For the AI team, the lesson is one of sequence: you do not start from the
agent or from the graph. You start from the knowledge layer of the first
domain, well integrated. The agent comes after, and it comes well, because it
builds on something that is correct.
For top management, the message is one of investment: the knowledge layer
is the investment that all the subsequent agents are going to share. Each
agent built on top of it costs less and is more reliable. It is
the difference between building an agent from scratch each time and building a
platform the agents use.
Conclusion
The knowledge layer is the deliberate integration of data, semantics,
ontology, entities, relationships and knowledge in prose, with declared
sources of truth, a domain model, a graph, a RAG and an owner. It is the
biggest piece of the cognitive infrastructure and the one that takes the longest, because
it requires business decisions, not only engineering ones.
Today the knowledge layer is built. But an agent does not
only need the stable knowledge of the company: it needs to remember what
happens in operation, day after day. And that is memory, which today we saw as
a concept and which tomorrow we are going to design as an architecture.
Next article
Tomorrow: Designing an Organization’s Memory for Its AI Agents. We will see how memory, knowledge base, RAG, knowledge graph
and events combine into a memory architecture the agent uses day to day, and what
it means to retain, consolidate and expire knowledge.
Sources
- Working definition of the ICE: see series, Day 1.
- Knowledge architecture as integration of ontology, graph and
RAG is the approach described in the literature on agentic knowledge systems
and in the content of Cirtra on Agentic Knowledge Systems.
