Read a sample

Extract from The Contextual Agentic Enterprise by Hanif Karimi. © 2026 Hanif Karimi. All rights reserved. Shared here as a sample; please link to this page rather than copying it.

In this sample: Introduction · Chapter 9 — Enterprise agent design patterns · Chapter 12 — Agentic Flow Mining

Introduction

Why the enterprise needs a contextual agentic architecture

I did not begin writing this book because enterprises lacked another artificial-intelligence platform, reference diagram or governance checklist. I began writing it because, across more than two decades of architecture, software engineering, delivery leadership, security and transformation work, I repeatedly encountered the same underlying problem:

Enterprises possess enormous amounts of data, knowledge, process history and technical capability, yet struggle to assemble the right context, evidence and authority at the moment a consequential decision must be made.

The technologies changed. Monolithic applications gave way to services, cloud platforms, data lakes, machine-learning systems and, eventually, generative AI. The architectural difficulty remained.

Information was fragmented across systems. Business meaning was embedded in code, documents, meetings and the experience of a small number of specialists. Decisions were recorded without the evidence that justified them. Delivery systems reported activity without reliably connecting it to intended outcomes. Models produced predictions without sufficient operational context. Governance often existed as policy outside the systems expected to enforce it.

Generative AI initially appeared to offer a solution. Large language models could search, summarise, explain and generate content across previously disconnected information. But the introduction of agents changed the architectural problem again.

An assistant that drafts a response is primarily an information system. An agent that selects tools, delegates work, invokes services, modifies records or initiates an operational process becomes part of the enterprise control plane.

That transition is profound.

A conventional application follows paths deliberately encoded by developers. A machine-learning model produces outputs within an inference contract. An agent, however, may interpret an objective, construct a plan, select capabilities, obtain additional context, interact with other agents and alter its behaviour according to intermediate results. The execution path may not be known completely in advance.

The enterprise is therefore no longer governing only software components and human users. It must also govern contextual decisions made through probabilistic reasoning and dynamic execution.

The missing connection

Most enterprises already possess established disciplines for addressing parts of this problem.

Enterprise architecture provides methods for connecting strategy, business capability, information, applications and technology. The TOGAF Standard, for example, remains a proven methodology and framework for developing and using enterprise architecture.

Governance frameworks such as COBIT help organisations govern and manage enterprise information and technology holistically.

ITIL provides practices for managing digital products and services. SAFe and related delivery frameworks organise portfolio, programme and team-level work. Security architectures protect identities, workloads, networks and data. Data-governance disciplines address quality, lineage, ownership and access. Model-risk and responsible-AI practices address fairness, explainability, validation and oversight.

These disciplines remain necessary. CAE does not replace them.

The gap appears at their intersection, particularly during execution.

When an agent prepares or performs a consequential action, the enterprise must determine:

• Which identity is acting, on whose behalf and under what delegated objective?
• Which tenant, jurisdiction, operating environment and point in time apply?
• What information may be accessed for this purpose, and which facts are observed, declared or inferred?
• What evidence supports each material claim, and what uncertainty or conflict remains?
• Which policies, semantic definitions and source versions are effective?
• Which capabilities and actions are permitted, and which require human approval or step-up authentication?
• How is approval bound to the exact proposed action?
• What occurred during execution, did it achieve the intended outcome, and can the decision later be reconstructed or challenged?

These questions cannot be answered reliably by a prompt, a model, a knowledge graph, a workflow engine or an audit log in isolation.

They require an integrated architecture connecting enterprise meaning, runtime context, intelligence, authority, controlled action, evidence and outcomes.

That requirement led to the Contextual Agentic Enterprise.

From assistance to agency

The architectural problem changes when artificial intelligence (AI) moves from generating information to participating in execution.

An AI assistant may retrieve documents, summarise a meeting, explain a policy or draft a response. Its output remains subject to human interpretation before any consequential change occurs. Although confidentiality, grounding and accuracy still matter, the model normally operates outside the enterprise’s transactional control path.

An agent can cross that boundary.

An agent may interpret an objective, assemble context, select tools, construct a plan, delegate work, invoke services, modify records and adjust its next action according to intermediate results. In a multi-agent system, one agent may create evidence or state that another agent consumes. The resulting execution path may be only partially known when the workflow begins.

The enterprise is therefore no longer governing only a model response. It is governing a dynamic participant in its operational environment.

Consider a supplier-risk system. An assistant might summarise evidence indicating that a supplier is likely to miss a delivery date. An agentic system could go further: inspect inventory, trace production dependencies, identify alternative suppliers, calculate financial exposure, prepare an intervention and request approval to change an order. Each step expands the system’s context, authority and potential blast radius.

The difference is not simply greater automation. It is a change in architectural responsibility.

A conventional application executes logic deliberately encoded and tested by developers. A predictive model produces an output through a defined inference contract. An agent may determine which capabilities to invoke and which execution path to follow at runtime. Its behaviour emerges from the interaction of its objective, model, instructions, retrieved context, available tools, accumulated state and external responses.

This introduces several new failure surfaces:

Context can be incomplete or incorrect

An agent may retrieve accurate information that belongs to the wrong customer, process stage, jurisdiction or point in time. It may combine individually valid facts into a conclusion that is invalid for the current situation.

More retrieval does not necessarily solve this problem. The agent requires purpose-bound context containing the correct entities, relationships, effective dates, permissions, policies and evidence.

Reasoning can be mistaken for authority

A model can produce a persuasive recommendation without possessing the organisational authority to approve or perform it. Confidence, fluency and technical access are not substitutes for delegated authority.

An agent that can call an API is technically capable of invoking it. That does not establish that the agent is authorised to perform the corresponding business action.

Tools convert model error into operational consequence

A hallucinated statement is harmful. A hallucinated action parameter submitted to an operational system may be materially worse.

Once agents can issue refunds, modify access, alter production schedules, update customer records or trigger downstream workflows, tool access becomes part of the enterprise security and control architecture. Tools must therefore be exposed as typed, policy-governed capabilities rather than unrestricted technical interfaces.

State creates temporal and coordination risk

Long-running agentic workflows may survive across sessions, human approvals, service interruptions and changing external conditions. Evidence may become stale while the workflow is paused. A policy or ontology may change. An approval may no longer apply to the action eventually presented for execution.

In multi-agent systems, these risks are compounded by handoffs, duplicated work, inconsistent context, stale shared state, delegation chains and feedback loops.

Completion can be confused with success

An agent may complete every assigned step without achieving the intended business outcome. A notification can be sent without resolving the underlying problem. A corrective action can be closed without preventing recurrence. A delivery intervention can be completed while increasing cost or moving risk elsewhere.

Agentic systems must therefore be evaluated at several levels: structural validity, evidence quality, policy conformance, execution behaviour, safety and eventual business effectiveness.

These conditions make agentic AI a distributed-systems, security, knowledge, governance and operating-model problem—not merely a model-selection or prompt-engineering problem.

At runtime, the architecture must bind five things that conventional model interfaces often leave implicit: the acting principal and delegated objective; the purpose-bound context and evidence; the policies and semantic versions in force; the capabilities and approvals available; and the durable state needed to reconstruct execution and assess outcomes.

This is the transition from assistance to agency.

It is also the point at which the Contextual Agentic Enterprise becomes necessary. CAE provides the architecture for connecting adaptive intelligence to enterprise context, evidence, identity, delegated authority, controlled capabilities and measurable outcomes.

Its purpose is not to eliminate model uncertainty. It is to prevent that uncertainty from becoming uncontrolled enterprise action.

When code becomes cheap, design becomes critical

A second change is happening alongside the first, and the two compound. AI coding assistants are lowering the cost of producing working code. They generate handlers, adapters, tests, deployment definitions and whole service implementations in minutes. This alters the economics of delivery. It does not remove the need for software design; it makes design harder to avoid.

When implementation was expensive, the rate at which engineers could write code placed a natural limit on the rate at which complexity entered a system. Generated code removes much of that friction. A team can now create more services, agents, tools and integrations than it can meaningfully understand. Local productivity rises while system-level coherence falls, and the second effect is invisible for longer than the first.

John Ousterhout distinguishes tactical programming, which optimises for finishing the task in front of you, from strategic programming, which invests in designs that stay understandable and adaptable (Ousterhout 2021). Agentic engineering needs the strategic form, and needs it sooner, because the cost of a poor boundary is no longer only maintenance. A generated component in an agentic system may initiate a consequential action.

That is the difference worth holding on to. A locally successful agent is not necessarily a well-designed enterprise component. It may expose a broad interface, acquire more authority than its task requires, duplicate context, conceal side effects, or push failure handling out to every caller. Each of those is survivable in a prototype and none of them is survivable at a hundred agents.

The bottleneck therefore moves. It moves from writing syntax to deciding boundaries: what a component may know, on whose authority it acts, what evidence it must leave behind, and how it behaves when something fails. Those are the questions this book is about, and they are the questions a coding assistant cannot answer for you, because they are not questions about code.

This is why the architecture in these pages is timely rather than merely topical. AI does not remove software engineering from the enterprise. It moves engineering value upward — from producing implementations to designing the conditions under which generated implementations can be trusted to run.

What CAE means

The Contextual Agentic Enterprise, or CAE, is a vendor-neutral enterprise architecture and operating model for governing how people, models, agents and systems assemble context, reason, exercise delegated authority, perform controlled actions and learn from outcomes.

The word contextual is deliberate. Data has limited operational meaning when separated from time, identity, provenance, purpose, policy and relationships.

A temperature reading of 100 degrees is not sufficient for a quality decision. Its meaning depends on the equipment, material, process stage, measurement unit, sensor condition, historical pattern and applicable operating rule.

A forecast that a programme will be delayed is not sufficient for an intervention. The organisation must understand which dependencies, environments, capabilities, assumptions and evidence contributed to the forecast.

A customer complaint is not merely a block of text. It may be connected to a product, serial number, manufacturing batch, supplier lot, service history, procedure version, previous nonconformance and corrective action.

Context transforms isolated information into decision-relevant evidence.

The word agentic is equally important. CAE addresses systems that do more than retrieve or predict. Agents may investigate, plan, challenge, coordinate, recommend and invoke capabilities. This makes identity, delegation, policy enforcement, bounded execution and replay first-class architectural concerns.

The word enterprise establishes the scope. CAE is not a pattern for building a better chatbot. It addresses heterogeneous organisations in which information, decisions and actions cross business units, systems, security domains, jurisdictions and organisational boundaries. The real complexity emerges when agents operate in heterogeneous organisations. Work doesn’t stay neatly inside a single SaaS tool or security domain. An agentic workflow might start in customer success (external domain), cross into legal and compliance (strict security domain), and execute in an ERP system (financial domain).

Where CAE sits alongside existing frameworks

The Contextual Agentic Enterprise does not replace established enterprise architecture, governance, service-management or delivery frameworks. It addresses a different but intersecting architectural concern: how contextual, probabilistic and increasingly autonomous systems participate safely in enterprise decisions and operations.

TOGAF, COBIT, ITIL and SAFe each provide important structures that remain necessary in an agentic enterprise. CAE connects their strategic, governance, service and delivery concerns to the runtime behaviour of models, agents and controlled capabilities. Table I.1 sets out what each contributes and where the Contextual Agentic Enterprise meets it.

Table I.1. Framework, primary contribution and relationship to CAE.

TOGAF and CAE

TOGAF provides a method for developing and governing enterprise architecture. It helps organisations understand their current and target states, align architecture with stakeholder concerns, structure architectural work and connect business, data, application and technology domains.

CAE can be used within that architecture-development process as a domain-specific reference architecture.

TOGAF may identify the need for an enterprise capability such as agent-assisted quality investigation, public-service assessment or delivery intelligence. CAE defines the runtime architecture required to implement that capability responsibly:

• How context is assembled.
• How enterprise meaning is represented.
• How models and agents are integrated.
• How identity and delegation are enforced.
• How actions cross a controlled capability boundary.
• How evidence and outcomes are retained.
• How the system is evaluated and governed after deployment.

TOGAF helps the enterprise decide what architecture is required and how it should evolve. CAE provides a reusable architecture for the contextual and agentic components within that target state.

COBIT and CAE

COBIT addresses the governance and management of enterprise information and technology. It helps organisations establish objectives, decision rights, responsibilities, controls, performance measures and alignment between technology and enterprise value.

CAE does not create an alternative governance system. It makes governance executable at the agentic boundary.

For example, a COBIT-aligned governance system may establish that consequential customer adjustments require accountable ownership, controlled access, risk management and traceable approval. CAE translates those expectations into runtime mechanisms:

• Verified human and workload identity
• Purpose-limited access
• Scoped and expiring delegation
• Policy decision and enforcement points
• Typed operational capabilities
• Approval bound to the exact proposed action
• Evidence-First Decision Records
• Replayable execution trajectories
• Outcome and effectiveness measurement

COBIT defines how enterprise information and technology should be governed and managed. CAE provides the architecture through which that governance constrains models and agents during execution.

ITIL and CAE

ITIL provides best-practice guidance for managing digital products and services across their lifecycle. Its focus on value, outcomes, reliability, governance and continual improvement is highly compatible with CAE.

Agentic systems will increasingly participate in service-management activities. They may classify incidents, investigate changes, identify recurring problems, recommend remediation, prepare service requests or coordinate operational responses.

CAE defines the conditions under which those activities can be trusted.

An incident agent may investigate logs and dependencies but require approval before restarting a production service. A change agent may prepare a deployment but remain unable to bypass separation of duties. A problem-management agent may identify a recurring pattern, but the proposed knowledge or ontology update must pass through governed validation before becoming authoritative.

ITIL structures the product and service lifecycle. CAE governs the contextual intelligence and agentic execution operating inside that lifecycle.

SAFe and CAE

SAFe provides an operating model for scaling Lean and Agile practices across portfolios, value streams, Agile Release Trains and teams. It helps organisations align strategy, funding, product development and delivery around value and flow.

CAE does not provide an alternative portfolio or delivery methodology.

Instead, it governs the intelligent participants increasingly embedded within delivery systems. Agents may analyse dependencies, challenge planning assumptions, identify delivery risk, assemble evidence, generate implementation options or coordinate engineering activities.

Within a SAFe environment, CAE can establish:

• Which portfolio, train, team and product context an agent may access.
• Which delivery evidence supports its recommendations.
• Whether planning assumptions are observed, declared or inferred.
• Which actions require product, architecture, security or release authority.
• How multiple engineering agents coordinate without losing state or accountability.
• How agent activity is evaluated against delivery and business outcomes.
• SAFe organises the people and work required to deliver value. CAE governs how models and agents participate in that system of work.
• CAE as a complementary runtime architecture.

The distinction can be summarised as follows:

• TOGAF shapes the enterprise architecture.
• COBIT governs enterprise information and technology.
• ITIL manages digital products and services.
• SAFe organises portfolio and delivery work.
• CAE governs contextual intelligence and agentic action across their execution boundaries.
• CAE is therefore neither a replacement framework nor an additional management methodology that organisations must adopt in isolation. It is a complementary architecture that can be incorporated into existing enterprise practices.

Its distinctive focus is the controlled connection between:

Business intent → contextual evidence → models and agents → delegated authority → governed action → operational outcome → accountable learning

An organisation can apply TOGAF without deploying autonomous agents. It can use COBIT to govern traditional information technology, ITIL to manage services and SAFe to coordinate delivery. Once models and agents begin interpreting context, selecting capabilities and influencing consequential actions, however, an additional architectural question emerges:

How will the enterprise ensure that adaptive intelligence acts with the correct context, sufficient evidence, valid authority and measurable accountability?

CAE is designed to answer that question.

The CAE Intelligence Fabric

CAE is the overarching architecture and operating model. Its technical capabilities are supplied through the CAE Intelligence Fabric.

The fabric connects:

• Enterprise data and operational systems
• Ontologies and temporal knowledge structures
• Evidence, provenance and authority
• Context assembly and Context Contracts
• Rules, predictive models, optimisation and simulation
• Foundation models and specialist agents
• Identity, delegation and workload credentials
• Policy decision and enforcement points
• Typed capabilities and controlled actions
• Human approval and contestability mechanisms
• Observability, evaluation and replay
• Organisational memory and semantic evolution
• Outcome and effectiveness measurement
• This distinction prevents a common architectural error

CAE is not a software product. The CAE Intelligence Fabric is not necessarily one physical platform. An organisation may implement it through an integrated commercial environment, a hyperscaler ecosystem, open-source components, existing enterprise platforms or a hybrid architecture.

Platforms such as Palantir Foundry and AIP demonstrate that enterprise data, ontology, models, security, agents and operational actions can be brought into a more coherent environment. Microsoft, Databricks, ServiceNow, Salesforce and other ecosystems provide different combinations of these capabilities.

These platforms validate the direction of travel, but none removes the enterprise’s responsibility to define evidence standards, decision rights, delegated authority, semantic governance, interoperability, contestability and outcome accountability.

CAE provides the architectural lens through which those implementation choices can be evaluated.

Models do not possess authority (Reasoning is not authority)

One of the central propositions of this book is that intelligence and authority must remain separate. A model may predict that a supplier will fail. It does not therefore possess the authority to cancel a contract. An agent may identify a likely root cause. It does not automatically possess the authority to close an investigation or initiate a corrective action.

A language model may produce a convincing policy interpretation. The fluency of the explanation does not make that interpretation authoritative.

CAE separates:

• Context assembly — constructing a purpose-bound and permission-filtered view of the relevant situation.
• Reasoning — producing hypotheses, predictions, alternatives or recommendations.
• Authority — determining which principal may approve or perform an action.
• Policy enforcement — evaluating whether the proposed action is permitted under the applicable conditions.
• Execution — invoking a controlled, typed and auditable capability.
• Outcome evaluation — determining whether the action produced the intended result.
• This separation is the architectural foundation for trustworthy enterprise agency.

Evidence before explanation

The second central proposition is that explanation without evidence is insufficient.

A dashboard may visualise a result without revealing how it was produced. A chat transcript may show what an agent said without recording the authoritative evidence it used. A reasoning trace may contain verbose intermediate language without providing a canonical decision record.

CAE therefore adopts an evidence-first approach.

Material claims should be connected to sources, provenance, authority, freshness and uncertainty. Consequential decisions should record the problem, hypotheses, considered alternatives, rejected options, execution constraints, selected action, accountable authority and expected outcome.

The resulting evidence record is not simply an audit trail. It enables:

• Decision reconstruction
• Regulatory and policy assurance
• Human challenge and contestability
• Model and agent evaluation
• Failure analysis
• Organisational learning
• Outcome verification

The goal is not to make probabilistic systems deterministic. It is to contain their uncertainty within deterministic boundaries of identity, policy, capability and evidence.

From action completion to outcome intelligence

Enterprise systems commonly treat activity completion as success. A ticket was closed. A recommendation was accepted. A release was deployed. A corrective action was completed. A notification was sent. None of these facts proves that the intended outcome occurred.

CAE closes this gap by connecting decisions and actions to outcome evidence. The organisation must determine whether the intervention reduced risk, improved service, prevented recurrence, increased quality, protected a customer, accelerated delivery or created measurable value.

This produces an accountable learning loop:

Context → evidence → reasoning → decision → authorised action → execution → outcome → evaluation → governed learning

The loop does not permit a model or agent to rewrite enterprise truth automatically. New observations may generate candidate knowledge, policy or ontology changes, but those changes pass through validation, impact assessment, approval, versioned publication, monitoring and rollback.

The enterprise can therefore learn without surrendering semantic or operational control.

Why this book

This book was written to connect disciplines that are too often discussed separately:

• Enterprise architecture
• Knowledge and semantic engineering
• Data and evidence governance
• Machine learning and generative AI
• Multi-agent systems
• Zero Trust security
• Workflow and process intelligence
• Human accountability
• Reliability and evaluation
• Organisational learning
• Outcome management

It is intended for architects, engineers, technology leaders, governance professionals, product owners, security specialists and transformation practitioners who must move beyond isolated AI demonstrations and design systems that can be trusted in real enterprise conditions.

The chapters progress from enterprise context and knowledge through models, agents, interoperability, Zero Trust, governance, evaluation, memory and operating models. The applied cases then demonstrate how the same CAE foundations can support delivery intelligence, supplier-risk decisions, quality intelligence and public-sector modernisation.

The companion implementation translates the architecture into executable contracts, workflows, evidence records, security controls and negative tests.

The objective is not to prescribe one platform or one universal design.

It is to establish a disciplined answer to a more important question:

How can an enterprise allow people, models and agents to use shared knowledge and take meaningful action without losing control of identity, evidence, authority, accountability or outcomes?

The Contextual Agentic Enterprise is the answer developed throughout this book.

Figure 0.1 presents the Contextual Agentic Enterprise as a closed-loop operating architecture. Business intent is translated into purpose-bound context and evidence. Rules, models and agents contribute intelligence, but proposed actions must cross an explicit authority and control boundary. Approved actions are executed through typed capabilities against authoritative enterprise systems. Their operational and business effects are then evaluated, retained as evidence and used to improve organisational memory and semantic models through governed—not automatic—evolution.

Figure 0.1. The Contextual Agentic Enterprise as a closed-loop operating architecture.

---

Chapter 9 — Enterprise agent design patterns

Patterns are useful when they capture forces and consequences, not merely fashionable diagrams. An enterprise agent pattern should tell an architect why the structure exists, where authority sits, what can fail and what evidence would demonstrate that the pattern works.

This chapter presents a core catalogue. The patterns are composable; they are not a maturity ladder. A simple Router plus deterministic workflow can be superior to a sophisticated multi-agent design when the task is well bounded.

9.1 Strategic design in the age of generated code

Before selecting from this catalogue, it is worth being explicit about what selecting well means, because the economics of the choice have changed. An assistant can produce a working implementation of any pattern in this chapter within an afternoon. What it cannot do is tell you whether the pattern contains complexity or merely relocates it.

Ousterhout’s central measure is the depth of a module: how much capability it provides relative to how much interface it exposes (Ousterhout 2021). A deep module offers substantial function through a narrow, stable contract and hides the implementation its callers should not need to know. A shallow module exposes nearly as much as it does, so using it is no simpler than writing it. The distinction transfers almost directly to agentic architecture, where the interface is the Context Contract, the authority envelope, the capability schema and the evidence the component is obliged to produce.

Seven of his principles map onto the CAE layers closely enough to be worth stating side by side.

Table 9.1. Software-design principle and its CAE application.

Two of those deserve emphasis here because they are the ones teams skip when implementation is cheap.

Design it twice. Do not accept the first plausible architecture, whether a person or a model proposed it. Develop at least two materially different designs and compare their authority surfaces, failure modes, evidence paths, coupling, operational cost and reversibility. The point is not to delay implementation. It is to stop rapid implementation from hardening an inferior design before anyone has examined the alternative.

Define errors out of existence. The strongest control is not one that detects a bad action but one that makes the bad action unrepresentable. A capability that cannot express a payment above its declared ceiling needs no check for payments above its ceiling. This is the same argument as the commit boundary, made one level down, in the type system.

A note on tests, because the two claims are easily confused. Test-first development can improve feedback and correctness, and the companion code in Chapter 25 depends on negative and invariant tests to demonstrate that its controls hold. But tests do not substitute for architectural design. A system can pass every local test and still have weak boundaries, excessive coupling, ambiguous authority and poor evolvability, because those properties are not expressed in any single unit of behaviour. In agentic systems the governing architecture and its invariants should be designed before the implementation loop is optimised — and then, as Chapter 25 shows, asserted by tests.

The chapter continues with the eleven pattern-selection dimensions and the full pattern catalogue; Appendix A gives every pattern as a one-page card.

---

Chapter 12 — Agentic Flow Mining (AFM)

Process intelligence for digital actors

A process diagram describes how work is intended to move. An event log records how work actually moved. The gap between these views is where process mining became valuable. Instead of relying only on interviews, workshops or static process diagrams, analysts use operational event data to discover recurrent paths, quantify deviations, locate bottlenecks and compare observed behaviour with a reference model.

Agentic systems create the same gap, but with new complexity.

A single enterprise request may trigger retrieval, context construction, model reasoning, tool calls, policy decisions, Agent-to-Agent delegation, human approval, retries, compensation and final commitment into a system of record. The resulting execution is not a simple request-response trace. It is a trajectory formed by interacting humans, agents, foundation models, tools, policies, workflows and enterprise systems.

Traditional observability remains essential, but it is insufficient. CPU utilisation, latency, error rate, token count and model-call volume can show whether infrastructure is healthy. They cannot by themselves show whether an agent used the required evidence, respected authority, followed the allowed path, avoided cross-tenant influence or produced a measurable business outcome.

This chapter proposes Agentic Flow Mining (AFM) as the discipline of discovering, analysing, validating and improving the real execution flows of AI agents, tools, humans, policies and systems of record. AFM extends process mining and observability to probabilistic, multi-agent, authority-bearing digital actors.

AFM addresses the agentic observability gap: infrastructure telemetry can see calls and latency but not always business meaning; LLM evaluation can judge outputs but often misses authority, evidence, sequence and system-of-record constraints. AFM bridges those worlds by mining agent trajectories and checking them against enterprise invariants.

The goal is not to force agents into one rigid path. The goal is controlled freedom: allow probabilistic systems to adapt where adaptation is valuable, while making critical boundaries — identity, authority, evidence, policy, state transition, approval and outcome — observable and enforceable.

12.1 Introducing Agentic Flow Mining

In this book, Agentic Flow Mining is an author-defined framework. Its intellectual lineage includes process mining, conformance checking, object-centric event data, distributed tracing, agent evaluation, Zero Trust security and multi-agent systems. It was developed independently of the closest published proposal in the research literature, which appeared shortly before this book’s research freeze; Section 12.3 sets out that relationship, what the two share and where they diverge.

The practical objective is straightforward: use runtime evidence to discover, test and continuously improve the real execution behaviour of agents, deterministic services, humans and enterprise capabilities.

AFM is not a replacement for observability. It depends on observability. It is also not merely an agent dashboard. A dashboard can show that an agent called five tools. AFM asks whether those five tool calls formed an acceptable enterprise process.

AFM treats the agent trajectory as a first-class object. A trajectory includes the sequence of model calls, retrieval events, context construction steps, tool proposals, policy checks, approvals, handoffs, errors, retries, state transitions, commitments and outcome signals that occurred during a task.

This matters because an agent can produce an acceptable final answer through an unacceptable path. It may skip a required evidence source, attempt a prohibited tool, enter an expensive loop, delegate through an unauthorised peer, or reach a correct answer only because the model guessed around a broken retrieval pipeline. Conversely, an agent may escalate to a human and appear to fail autonomous completion, while actually behaving exactly as designed for a high-risk case.

AFM therefore shifts the unit of evaluation from “Did the final answer look good?” to “Did the execution flow remain inside the permitted enterprise envelope, use adequate evidence, consume resources efficiently and improve a measurable outcome?”

12.2 How AFM differs from observability, process mining and trajectory evaluation

Table 12.1. Discipline, primary question, limitation for agentic systems and AFM extension.

This synthesis is why the term Agentic Flow Mining is useful. Observability is necessary but too passive. Process mining is relevant but historically anchored in more deterministic workflows. Trajectory evaluation is valuable but usually case-level. AFM combines them into an enterprise architecture discipline for digital actors.

The chapter continues with the scientific and industry validation of AFM, the move from process mining to agentic process intelligence, and how to implement it.