From Knowledge to Action: When AI Starts Running the Company

An agent that recommends is useful. An agent that acts is another thing:
it changes the operational world of the company. And the jump from “recommending” to
“operating” is where trust is played, and where governance stops being
a document to become the mechanism that allows the agent to act without
breaking anything.

Introduction

Yesterday we defined the Enterprise Cognitive Infrastructure as the layer that
turns knowledge into capacity for decision and action. Today we touch
the second half of that phrase: action.

Because there is a line that separates an AI project from an
operational capability, and it is in a verb: to act. An agent that answers questions and
recommends actions is a support system. An agent that executes actions
— creates the order, blocks the transaction, schedules the intervention, opens the
report — is a system that operates the company. And that jump is the one
we dismantle today.

The problem

An industrial company has deployed a maintenance agent that, until
now, recommends: “check the coupling of B-7”, “reserve
part R-55”, “notify management”. And the technical team has started to
complain in a very concrete way:

• “The agent recommends well, but then a technician has to translate each
  recommendation into a work order, request the part in the
  warehouse system and open the notification. The agent does 50 % and we do
  the other 50 % manually.”
• “The recommendation arrives at 23:00. Nobody executes it until 7:00. The
  intervention window is gone.”
• “Sometimes two technicians execute the same recommendation, because there is no way
  of knowing that it has already been done.”

The pattern: knowledge reaches the recommendation, but not the
action. And between the recommendation and the action there is a manual gap that
annuls a large part of the value of the agent, introduces transcription errors and
makes the response arrive late.

The problem is not that the agent does not know what to do. It is that it cannot do
what it knows, because it does not have tools, permissions nor a
supervision mechanism that allows it to act safely.

The concept

The complete chain that an enterprise agent has to traverse to operate
the company is:

KNOW → UNDERSTAND → REASON → DECIDE → ACT
(knows)  (understands)  (reasons)  (decides)  (acts)

The first four verbs we have covered: KNOW (knowledge, day 11),
UNDERSTAND (semantics + ontology, days 3-4), REASON (day 14), DECIDE
(reasoning + context + memory, days 9-14). Today it is the fifth’s turn: ACT.

And ACT is not “call an API”. It is a mechanism with five components:

1. Tools. The concrete actions the agent can
   execute: create a work order, reserve a part, open a
   report, block a transaction, send a notification. Each tool is
   an atomic action, with a defined interface and a verifiable result.

2. Workflows. The sequences of tools that solve
   a complex task: “reserve part + create order + notify +
   register”. The workflow is what turns loose actions into a
   process.

3. APIs (integrations). The connections with the source systems
   (ERP, warehouse, SCADA, CRM) through which the tools execute the actions.
   The agent does not “touch” the systems directly: it does it through
   integrations with defined permissions.

4. Permissions. What actions the agent can execute, on what objects,
   with what scope. The principle of least privilege: only the actions
   necessary for its function. A maintenance agent cannot create
   commercial orders.

5. Human-in-the-loop (HITL, human supervision). The mechanism by which
   an action is executed, approved or escalated, according to its level of risk:
   – Low-risk action (register a note): the agent executes it.
   – Medium-risk action (reserve part): the agent proposes it and a
   human approves it.
   – High-risk action (block a production line): the agent
   prepares everything, but a human decides.
   – Escalation: if the agent detects that it is outside its
   operational range, it escalates to a human without executing.

HITL is not a limitation of the agent: it is the trust mechanism that
allows the agent to act. And it is the one that raises the level of autonomy
over time: an agent that starts by approving everything, and that with time
executes more low-risk actions alone, because the
human approval rate has proven to be high and sustained.

The central rule: the agent acts within a perimeter of permissions and
supervision, and the level of autonomy is earned with evidence, not
configured.

Architecture

In the series diagram, action is the top layer of the ICE, where
knowledge is turned into operations:

              AGENTS
                 ↓
        KNOW → UNDERSTAND → REASON → DECIDE
                 ↓
                 ACT
   ┌─────────────────────────────────┐
   │ Tools · Workflows · APIs        │
   │ + Permissions + HITL            │
   └─────────────────────────────────┘
                 ↓
        ENTERPRISE SYSTEMS
   (ERP, warehouse, SCADA, CRM, ...)

The action layer is the frontier between the ICE and the operational world. And it is
where the governance (tomorrow) becomes more tangible: each action executed
leaves a trace, and that trace is what allows auditing what the agent did and
why.

Use case

The industrial company, with its maintenance agent, now with the action
layer. We break down the same event of Day 16, but to the end:

1. Problem. The agent recommends well, but the recommendation is not
   executed (manual gap, delay, duplication).
2. Decision. Close the gap: that the agent executes the low-risk
   actions, proposes the medium-risk ones and prepares the high-risk ones, within
   a perimeter of permissions and supervision.
3. Knowledge needed. The diagnosis (coupling of B-7), the
   procedure P-114, the part R-55, the intervention window.
4. Actions (Tools). Create work order; reserve part R-55;
   notify management (for exceeding threshold U); register the decision.
5. Workflows. “Diagnosis confirmed → reserve R-55 + create order +
   notify + register”.
6. APIs. Warehouse (reserve part), CMMS (work order),
   notification system (report to management).
7. Permissions. The agent can reserve parts of its area, create
   work orders and notify; it cannot block lines nor approve
   purchases.
8. HITL. Reserve R-55 (medium risk) → the agent proposes and the technician
   approves on the mobile; create the order (low risk) → the agent executes it;
   notify management (for threshold U) → the agent executes it and leaves
   the record.
9. Execution. The agent reserves R-55 (approved by the technician in 4
   minutes, not at 7:00), creates the work order, notifies management
   and registers everything. The intervention window is respected.
10. Infrastructure. The action layer (tools + workflows + APIs +
    permissions + HITL) on top of the ICE (knowledge + memory + context +
    reasoning). Knowledge now reaches the action.

Trade-offs

• Cost. Each tool, each API, each workflow is integration work.
  The action layer is as expensive as the knowledge one, because it touches all
  the source systems.
• Complexity. A workflow that reserves a part, creates an order and
  notifies has states, errors and retries. It is
  integration engineering, not a prompt.
• Security. Giving an agent permissions to execute actions is giving
  attack surface. The principle of least privilege and HITL are the
  defenses. An agent with broad permissions is a risk.
• Reversibility. Not every action is reversible (blocking a line,
  sending an email to a customer). Irreversible actions demand more
  supervision. The HITL design must weigh reversibility.
• Latency. Adding HITL adds time to the action. For emergency
  actions, the perimeter has to allow a certain autonomy; for
  risk actions, the wait is the price of security.
• Trust. HITL generates trust, but also friction. If the
  agent proposes a hundred things and the human approves a hundred, the human gets fatigued and
  approves without looking. The design has to balance autonomy and supervision
  so that the supervision is attentive, not ritual.
• Honest limitation: the action layer executes what the ICE has
  decided. If the decision is bad (due to bad knowledge or an
  incomplete context), the action executes a bad decision fast. Action
  amplifies the quality of the decision; it does not correct it.

Implication for the company

For the CIO, the action layer is what turns the agent from a
support system into an operational capability: the value of the agent is no longer in what
it says, but in what it does. And it is the layer that most touches the
existing systems, because it has to be integrated with all of them.

For operations, the implication is the most tangible: the manual gap between
“recommendation” and “action” disappears, the response arrives on time, and there is no
duplication. And the technician passes from executor to supervisor: it approves instead
of transcribing.

For the CISO and compliance, the action layer is where the permissions and HITL
become operational, and where each action leaves an auditable trace. It is the
most exposed frontier of the agent, and the one that most demands governance.

For top management, the message is one of maturity: an agent that acts is an
agent that assumes operational responsibility. And operational responsibility
is managed with permissions, supervision and traceability — not with trust.

Conclusion

The jump from “recommending” to “acting” is the one that turns the agent from a
support system into an operational capability. And that jump demands five
components: tools, workflows, APIs, permissions and human supervision. The
agent acts within a perimeter, and the level of autonomy is earned with
evidence.

Today the agent acts. But when an agent acts, the question
everyone is going to ask appears, and it is the correct question: how do we know why
it decided to do what it did? Tomorrow we answer it: the cognitive
infrastructure also needs governance.

Next article

Tomorrow: Cognitive Infrastructure Also Needs Governance.
We will see provenance, lineage, ownership, freshness, confidence, temporal
validity, permissions, auditability and human supervision — and the question that
joins them: how do we know why an agent made a decision?

Sources

• Working definition of the ICE: see series, Day 16.
• The pattern of progressive autonomy with HITL (approve everything → incremental
  autonomy with evidence) is coherent with the content of Cirtra, “How
  to Implement AI Agents in the Enterprise” (2026), which recommends maintaining
  human supervision until the approval rate exceeds 95 % in a
  sustained way.