An Enterprise Agent Is Far More Than an LLM with Tools

“An LLM with tools” is the definition of agent that marketing sells. And it is, moreover, false: an LLM with tools that does not know who
it is, what it can do, what it remembers or what it knows, is not an agent. It is a
chatbot with hands. The difference between the two is a set of layers that
today we dismantle one by one.

Introduction

We have built, throughout the series, all the pieces an agent
needs: knowledge, memory, context, reasoning. And on Day 1
we saw a procurement agent that failed because it only had an LLM
connected to documents.

Today we close the circle: what, in reality, is an enterprise agent. And
we do it with a warning: the fashionable definition —“an LLM with
tools”— is incomplete to a level that matters. Because an LLM with
tools can do things, but it cannot operate inside an
organization. And operating inside an organization demands a set of
layers that have nothing to do with the model.

The problem

Let us review the Day 1 procurement agent. Today, three years later,
many companies have “improved” it exactly the same way: they have added
tools. It can read the ERP, draft emails, create order
drafts. And it keeps failing, but now in more expensive ways:

• It creates an order draft to a supplier, but it does not know that supplier
  is in an exclusion process (it has no identity nor policies).
• It executes an action (sends the order) without anyone having approved it (it
  has no human supervision nor permissions).
• Nobody knows why it created that order nor what context it used (it has
  no observability nor traceability).
• And when it makes a mistake, there is no way to measure it or to correct it (it has
  no evaluation).

The pattern: adding tools to an LLM does not turn it into an
enterprise agent. It gives it hands, but it does not give it identity, memory, context,
knowledge, policies, permissions, observability or evaluation. And without
those layers, the hands do things they should not, without anyone knowing.

The concept

An enterprise agent is not an LLM with tools. It is a system with
autonomy oriented to a goal that operates inside the limits of an
organization. And to operate inside those limits it needs a set of
layers. Let us dismantle them:

1. LLM (reasoning engine). The reasoner about language. We saw it in
   Day 14: it reasons about language and generalization, not about rules nor
   arithmetic.
2. Memory. What it remembers: episodic, semantic, procedural
   (days 9, 12). Without memory, it starts from zero in every task.
3. Context. What it brings in each decision, built
   dynamically (days 10, 13). Without context, it chooses from the noise.
4. Knowledge. The stable knowledge of the domain: graph +
   RAG (days 7, 8, 11). Without knowledge, it does not know what is what.
5. Ontology. The model of the domain and its constraints
   (day 4). Without ontology, it cannot verify that it respects the domain.
6. Retrieval. The mechanism to bring the knowledge and the
   context at the moment (day 8, 13).
7. Tools. The APIs and actions the agent can
   execute: read the ERP, create an order, send an email. (What
   marketing calls “the agent”.)
8. Policies. The business and risk rules the agent
   must respect: thresholds, constraints, approval requirements (day 14).
9. Identity. Who the agent is: a unique identifier, with
   a role and a declared scope. An agent without identity is an anonymous
   process that cannot be audited.
10. Permissions. What the agent can do and see, with the
    principle of least privilege: only the data and systems strictly
    necessary for its function.
11. Observability. What the agent does is
    registered: what decisions it made, what context it used, what tools
    it invoked. Without observability, it is a black box.
12. Evaluation. How it is measured that the agent works well:
    metrics of reliability, of business, of security. And how it is corrected
    when it does not.

Twelve layers. The LLM is one of them. The other eleven are what turns an
“LLM with tools” into an agent that can operate inside an
organization. And the practical distinction is:

• Chatbot: answers questions within a script. (LLM + retrieval.)
• RPA: executes fixed rules (“if X, do Y”). (Tools + policies, without
  reasoning.)
• Agent: understands a goal, decides what steps to take, what tools
  to use and when to ask for human help, operating within identity, permissions,
  policies and observability. (The twelve layers.)

The jump from chatbot to agent is not adding an LLM: it is adding the eleven
layers that are missing. And those layers are, precisely, the cognitive infrastructure that
we have been describing throughout the series.

Architecture

In the series diagram, the agent is the top layer, and the twelve
layers are its anatomy:

              ENTERPRISE AGENT
   ┌─────────────────────────────────────────┐
   │ LLM · Memory · Context · Knowledge      │
   │ Ontology · Retrieval · Tools            │
   │ Policies · Identity · Permissions       │
   │ Observability · Evaluation              │
   └─────────────────────────────────────────┘
                 ↓
   COGNITIVE INFRASTRUCTURE
   (Knowledge + Memory + Context + Reasoning)
                 ↓
   KNOWLEDGE & DATA SYSTEMS
                 ↓
   ENTERPRISE SYSTEMS

The agent is not the cognitive infrastructure: it uses it. The
cognitive infrastructure is the layer that provides knowledge, memory, context and
reasoning; the agent is the layer that orchestrates them to pursue a
goal and act. And the governance (identity, permissions, observability,
evaluation) is what allows that orchestration to be secure and auditable.

Use case

The Day 1 procurement agent, now with the twelve layers. We break down
the same decision of then — validating and approving an order — but with the
complete anatomy:

1. Problem. Validate a proposed order against the framework
   contract in force and the purchasing policies, and propose the approval.
2. Decision. Approve, reject or escalate the order.
3. Knowledge needed (Knowledge + Ontology). The framework
   contract in force; the purchasing constraints; the approval
   thresholds; the identity of the supplier.
4. Memory (Memory). The previous conversations with the supplier; the
   last review of the contract; the delivery incident of the last
   quarter.
5. Context (Context). Who makes the request (and their permissions); the date
   (which contract is in force); the stage of the process; the level of risk.
6. Retrieval (Retrieval). Bring the contract in force, the
   discount policy and the memory of the supplier at the moment of the decision.
7. Tools (Tools). Read the order in the ERP; create the
   approval request; escalate to the buyer.
8. Policies (Policies). “Discount > 15 % requires the
   director’s approval”; “supplier X is in an exclusion process”.
9. Identity (Identity). The agent is “Procurement Agent v2”, with
   the role of junior buyer and a declared scope.
10. Permissions (Permissions). It can read orders and contracts of its area;
    it cannot approve discounts > 15 %; it cannot see suppliers of other
    areas.
11. Observability (Observability). Each decision is registered: which
    order, which contract, which policy applied, which context, which action.
12. Evaluation (Evaluation). Metric: % of orders validated without error;
    rate of correct escalations; and periodic review of the decisions
    to detect deviations.

And the decision, with the twelve layers: the agent reads the order (tools), brings the
contract in force and the policy (retrieval + context), verifies that the
discount (12 %) is within the threshold of the junior buyer (policies +
reasoning, day 14), checks that the supplier is not in exclusion
(knowledge + identity), creates the approval request (tools), and registers
everything (observability). If the discount had been 18 %, the agent would
have escalated it to the director (policies + permissions), with the
justification (registry).

The difference with Day 1 is total: the same LLM, but now with identity,
permissions, policies, memory, context and observability. And now the decision
can be audited from start to finish.

Trade-offs

• Cost. The twelve layers are twelve subsystems. An agent with identity,
  permissions, observability and evaluation is more expensive to build and operate
  than an “LLM with tools”.
• Complexity. The integration of the twelve layers is an
  architecture project. And the governance (identity, permissions) demands coordinating with
  security and compliance, not only with the AI team.
• Latency. Each layer adds steps. An agent with
  policy verification and registry is slower than a chatbot. In risk domains,
  that latency is what buys the security.
• Maintenance. The policies, the permissions and the tools change.
  The agent has to be updated or it starts to operate with obsolete rules.
• Attack surface. An agent with permissions and tools is an
  attack surface. The principle of least privilege (permissions) and
  human supervision are the main defenses.
• Honest limitation: the twelve layers do not make the agent
  infallible. They make its failures visible, auditable and
  bounded. An agent with observability that fails warns; one without it
  fails in silence.

Implication for the company

For the CTO, the twelve-layer anatomy is the checklist of an
enterprise agent: if it is missing identity, permissions, observability or evaluation,
it is not an agent, it is a chatbot with hands. And those layers are not optional:
they are what allows deploying the agent in production.

For the CISO (security) and compliance, the implication is the most important:
an agent without identity or permissions is an anonymous process that acts on
the company’s systems. Identity and the principle of least privilege
are what turn an agent into a responsible actor, and they are what a
regulator (or an auditor) is going to demand.

For top management, the message is one of maturity: the jump from chatbot to
agent is not a matter of model, it is a matter of infrastructure. And
that infrastructure is, literally, the one we have been describing
for twenty days.

Conclusion

An enterprise agent is not an LLM with tools: it is a system with twelve
layers (LLM, memory, context, knowledge, ontology, retrieval,
tools, policies, identity, permissions, observability, evaluation)
that allow it to operate within the limits of an organization. The LLM is
the engine; the other eleven layers are the chassis, the steering wheel and the seatbelt.
And that set is, precisely, the cognitive infrastructure.

We have described the agent. But the agent does not exist alone: it builds on
a layer that supports it, and that layer finally deserves a name. Tomorrow we give it
one, and with it we close the construction: What is an Enterprise
Cognitive Infrastructure?

Next article

Tomorrow: What Is an Enterprise Cognitive Infrastructure?. The
pillar article of the series: the canonical definition, the components, what problems
it solves (and which ones it does not), and how it integrates into an existing enterprise
architecture.

Sources

• Working definition of the ICE: see series, Day 1.
• The chatbot / RPA / agent distinction and the layer-by-layer anatomy are
  coherent with the content of Cirtra, “How to Implement AI Agents in the
  Enterprise” (2026), and with the literature of agentic AI.