Agents are rapidly evolving from simple assistants into autonomous actors embedded in real workflows. The question on everyone’s mind is (or should be) “how to manage an ecosystem of hundreds or thousands of agents”. But the challenge isn’t necessarily just about scale, rather it is actually about coordination.

Shared workspaces, a new Agentic Mesh architecture primitive, provides the shared workspace, memory, structure, and security needed to make that coordination possible across huge agent ecosystems.

The closest real-world analogy to shared workspaces is Slack which is a communications platform that provides messaging, collaboration, and information sharing within teams and organizations. But Slack, used by people, works at “people-speed”. Shared workspaces are like Slack for agents that operate in real-time at “agent-speed”, with orders of magnitude faster decision making, interactions, and collaboration.

This article introduces Agentic Mesh shared workspaces and explains how they support enterprise-grade agent collaboration at-scale, and at agent-speed:

• Definition of an Agentic Mesh shared workspace

• Shared workspace agent classes

• How shared workspaces work

• Protocol standardization with super contexts

Agentic Mesh Shared Workspaces: Slack for Agents

Slack changed how people collaborate by organizing conversations into channels, making communication more fluid, transparent, and context rich. It replaced the latency and formality of email with real-time, ongoing threads of interaction.

But Slack, like most tools used by people, operates at “people-speed.” Conversations unfold sequentially, responses are constrained by attention spans and working hours, and meaning depends on social cues and nuance.

In contrast, Agentic Mesh shared workspaces are designed to support agent-to-agent collaboration entirely at agent-speed. They extend the core ideas behind Slack—shared space, message channels, persistent state—but remove the human bottlenecks.

Agents don’t need time to think, sleep, or check context. Agents in a shared workspace are ambient, operating in a “headless” way not bound to a user interface. Rather they seamlessly collaborate using a shared communication fabric - they can read, respond, reason, and adapt continuously and in parallel. In a shared workspace, thousands of agents can interact in real time, coordinating activities, execute tasks and share results without waiting for human input or comprehension.

While Slack helps people stay in sync through threads, mentions, and status updates, Agentic Mesh shared workspaces enable agents to dynamically manage shared goals, task hierarchies, and memory based upon shared conversations. An agent doesn’t just drop a message into a channel—it references a secure shared workspace that holds evolving state, past decisions, and active dependencies. Shared workspaces act less like chatrooms and more like a communication fabric where agents interact, collaborate, and do work.

So, let’s think about the implications. What if agents – not bound to a user interface – could collaborate and securely share information at agent-speed, not people-speed? Imagine a world where agents not only interpret context but build on it—refining plans and coordinating execution in milliseconds. As the capabilities of LLMs that power agents get exponentially better and cheaper simultaneously, we are rapidly moving into a world of virtually unlimited, low-cost intelligence that can operate around the clock.

What kinds of work could be reimagined, what kinds of decisions could be made differently or faster, and what kinds of ecosystems could emerge? The shift to agent-speed coordination and collaboration isn’t just about efficiency; It is about coordination and collaboration; It is about agility and speed; But it is really about unlocking entirely new opportunities.

Agentic Mesh’s Shared Workspace: Sharing Agent Context and Conversations

Here is the problem today: most agents today function in isolation, limited by the immediate inputs provided by users – ChatGPT, for example, has people interact directly with a single LLM using a single UX. While this model is OK for simpler interactions, it falls short in scenarios requiring longer-term coordination, distributed work, or multi-step task execution. Without access to a persistent and shared context, agents cannot easily build on one another’s work, resolve interdependencies, or develop collective situational awareness. As a result, collaboration amongst agents remains challenging, fragmented, and brittle.

This architectural limitation is becoming increasingly visible as organizations move beyond isolated agent use cases and begin orchestrating larger, more capable multi-agent ecosystems. What’s clear is that there is an emerging need for a shared memory and coordination layer that can span this diversity and enable coherent multi-agent collaboration. This requirement has given rise to a new agent architectural primitive: Agentic Mesh “shared workspaces”.

Figure 1, Agentic Mesh: Shared Workspace

A shared workspace acts as a secure, structured, and persistent shared workspace for agents. It captures and makes available to all participating agents the entire stream of interactions—structured messages, event signals, goals, tasks, intermediate outputs, and outcomes. And it enforces consistency through shared schemas and higher-order semantic protocols (more on that later in the document), ensuring that meaning is preserved across different agents, workflows, and lifecycles. In effect, this makes a shared workspace the agent communication and coordination fabric that supports both real-time and asynchronous collaboration at scale.

An Agentic Mesh shared workspace becomes a semantic layer that encodes the operational logic of the agent ecosystem. It records every interaction – who initiated what, in response to which event, under what conditions – allowing a shared workspace to provide a new level of explainability (what happened in the past) and forward-looking planning (what an agent can do in the future, and how it can do it). Rather than each agent interpreting the interactions in isolation, a shared workspace provides a common conversation history that allows all agents to align their decisions, contribute to shared objectives, and detect inconsistencies or conflicts early in the process.

Since Agentic Mesh shared workspaces come about because of scale, so scalability, of course, is a first-class design goal. Shared workspaces are engineered to support not just dozens, but hundreds or thousands of collaborating agents (what I call agent fleets). Agents in a fleet access a shared workspace in parallel, issuing both ad hoc queries and persistent subscriptions. Pull-based and event-driven workflows coexist, with agents subscribing to conversation threads, hearing all interactions in a conversation, progress markers, or anomaly signals relevant to their tasks.

What distinguishes a shared workspace is its capacity to capture not just isolated messages, but complete chains of interactions and conversations. When agents share entire conversations—including queries, responses, plans, adjustments, and outcomes—they expose the thought process behind decisions. In effect, a shared workspace transforms loosely coupled agents into an ecosystem capable of shared intelligence.

This architecture is fundamentally different from retrieval-augmented generation (RAG) or point-to-point memory modules, or even microservices of the past. RAG systems inject static documents into prompts at inference time, but they do not preserve conversational structure, lineage, or cross-agent semantics. APIs support microservices without the thinking or reasoning that agents have. A shared workspace, by contrast, is not a prompt repository—it is a governed, real-time conversation history that captures everything: agent-to-agent interactions, tool invocations, errors, re-plans, results, and even the results of RAG queries themselves. Literally, it is the system of record for agent behavior.

Interestingly, as agents contribute to a shared workspace over time, their shared conversation – their knowledge base – deepens and improves. Every new insight, interaction, or plan adds to a historical record that future agents can leverage. So, practically, the returns are actually compounding as more agents mean richer memory, better decisions, and more efficient collaboration.

Agentic Mesh Shared Workspace Agent Classes

Agentic Mesh shared workspaces support structured collaboration at scale through a clear division of agent responsibilities. At the core of this design are several primary agent classes – observer agents, task-oriented agents, and goal-oriented agents – each fulfilling a distinct operational role. These agents collectively establish a sensing-deciding-acting loop that enables intelligent, distributed execution across complex workflows.

Figure 2, Agentic Mesh: Shared Workspace Agent Classes

Agentic Mesh observer agents serve as the sensors between the external world and the agent ecosystem. Their function is not merely to ingest data, but to transform external inputs—logs, telemetry, market signals, news, alerts—into structured, semantically meaningful events. By processing information at the edge of the ecosystem, observers shield other agents from unnecessary volume and noise, reducing downstream compute and cognitive load.

This preprocessing involves more than basic filtering. Observer agents enrich incoming data streams with contextual metadata, score severity or novelty, use their LLMs for sophisticated reasoning and insight, and even detect shifts in behavior over time. Event windowing and aggregation—performed across time intervals or logical groupings—yield higher-order constructs such as trend indicators or anomaly patterns. These are then written into a shared workspace for use by downstream agents, ensuring consistency, relevance, and traceability.

To support horizontal scale and reduce data duplication, observers are often organized into hierarchies. Local observers operate near high-volume data sources, performing real-time triage. Regional observers synthesize those local signals, extracting thematic or geographic patterns. At the top, global observers integrate across domains, offering a macro-level view of activity across the ecosystem. This layered architecture mirrors principles found in distributed systems—local autonomy combined with global coherence.

Agentic Mesh task-oriented agents are the execution engines within Agentic Mesh. Triggered by goal agents or rule-based policies, they are responsible for performing well-defined actions such as invoking tools, querying databases (or RAG systems), transforming inputs, and submitting outputs.

Task agents write their results—including intermediate outputs, errors, and completion markers—back into a shared workspace. And the results, in-turn, are made available to other agents. This persistent trace allows other agents to reason about system state without requiring direct inter-agent communication. For task-oriented agents, a shared workspace becomes the execution log and state coordination bus for distributed task execution.

Agentic Mesh goal-oriented agents operate at the highest level of abstraction. Their purpose is to coordinate, adapt, and manage long-running, multi-step outcomes – to fulfill goals (as their name implies). These agents construct execution plans by sequencing task-level steps, determining which agents to invoke, and under what triggering conditions. As conditions evolve—whether due to updated observations, partial failures, or changing priorities—goal agents dynamically re-evaluate plans, cancel tasks, or introduce new subtasks. Their decision-making is continuous and stateful.

Because Agent Mesh’s shared workspace encodes a rich history of task execution and observational signals, goal agents can make informed decisions about dependencies, completion status, or blockers. They can identify when progress is stalled, detect divergence from expected paths, and initiate remediation or escalation strategies—all grounded in the full historical and contextual record provided by a shared workspace.

Together, these three classes form a tightly coupled loop: observer agents monitor and interpret external conditions; task-oriented agents create and execute structured plans; and goal-oriented agents coordinate system-wide objectives in response to dynamic context. This modular role specialization, reinforced by the shared memory plane of a shared workspace, is what makes large-scale agent collaboration tractable, testable, and extensible. Much like human organizations evolve roles and teams to handle complexity, agent ecosystems depend on these architectural roles to remain coherent and resilient at scale.

Figure 3, Shared Workspaces in the Enterprise

Agentic Mesh Shared Workspace Orchestration

As multi-agent systems grow from a handful of cooperative agents to fleets operating across functional, geographic, and organizational domains, the mechanics of communication within a shared workspace must evolve to match the complexity and scale of the ecosystem. A shared workspace, by design, is an open workspace that agents can read from and write to, however, without structure and constraints, this openness quickly becomes unsustainable.

In a naive implementation, every agent would be allowed to read every message published to a shared workspace. Each message, whether a status update, a plan revision, or an external signal, would be visible to all agents. If each agent then responds with its own message, and those messages trigger further agent responses, the shared workspace can quickly devolve into a feedback loop of exponential message growth.

To address this, shared workspaces introduce orchestration agents. These orchestrators act as intelligent intermediaries, with visibility into the full set of registered agents, their capabilities, metadata, purpose statements, policy scopes, and conversation history. When a message is published to a shared workspace, the orchestrator reviews it and determines whether it requires agent action—and if so, which agent or subset of agents are best positioned to respond. This targeted routing prevents message flooding and ensures that agent attention is directed where it is most effective. Orchestrators essentially shape the flow of work by aligning messages with agent roles.

Message visibility is further constrained through agent-level access controls, implemented as read filters—white-lists and black-lists—that define which agents can consume messages from which sources. An agent may be configured to accept messages only from trusted peer agents, specific orchestrators, or domain-specific observers. Messages from unauthorized or irrelevant sources are ignored entirely. This mechanism not only limits noise but enforces domain boundaries, privacy scopes, and operational roles within the broader system.

The same mechanics can be composed into layered orchestration. For instance, if an orchestrator identifies a message as a “system” instruction—such as one to start, stop, or reconfigure agents—it routes it to an administrative control agent rather than to a task executor. That administrative agent may operate with elevated permissions and be part of a control plane with access to lifecycle operations. This layered structure allows orchestration logic to distinguish between operational flow (e.g., task execution) and infrastructure flow (e.g., fleet management), using the same underlying message handling rules.

These routing and filtering primitives are powerful enough to form the basis of full communication protocols within a shared workspace. For example, a “compliance review” protocol could involve observer agents tagging risky transactions, an orchestrator routing those to compliance reviewers, and reviewers triggering automated or human escalation depending on severity—all coordinated via structured message flows. Each role operates on its designated subset of messages, and all interactions are logged with provenance, creating a traceable, enforceable workflow without central control logic hardcoded into agents.

So, clearly, communication within a shared workspace is not a free-for-all. In fact, it is a rather disciplined, structured mechanism for managing attention, preserving clarity, and scaling coordination across vast and heterogeneous agent ecosystems. Through orchestrators, message filtering, and role-aware routing, a shared workspace becomes a high-integrity collaboration fabric—capable of supporting both emergent interactions and tightly-governed process automation, all from a single architectural foundation.

Agentic Mesh Shared Workspace and Protocol Standardization

I think the most consequential – and I am sure probably least expected benefit of a shared workspace – is it provides the building blocks for protocol definition and enforcement. A multi-agent ecosystem requires agents to operate with shared expectations about meaning, state, and intent. Shared workspaces address this by serving as not just a coordination fabric but also a semantic layer that ensures agent interactions are interpretable, traceable, and interoperable at scale.

By requiring all agents operating within a given shared workspace to use consistent schemas, it creates the conditions under which structured protocols can be identified. Agents collaborating in a specific shared workspace not only exchange data but do so according to a shared conceptual and semantic model.

So, this does not imply a rigid or global standard. Each shared workspace instance can support its own protocol, tailored to the domain logic, agent types, and operational constraints of its local ecosystem. This architectural flexibility allows for protocol specialization without sacrificing semantic coherence.

In highly regulated domains, protocols embedded within shared workspaces can encode sophisticated semantic models: for example, emissions tracking frameworks in energy, trade lifecycle protocols in capital markets, or jurisdiction-specific compliance workflows in financial crime detection. Because the interaction logic is mediated by a shared workspace—not hardwired into individual agents—protocols can evolve safely. New fields, states, or patterns can be introduced, versioned, and gradually adopted without breaking in-flight collaboration.

Shared workspaces also accommodate the geographic and jurisdictional diversity that large ecosystems must work in. Protocols can incorporate regulatory overlays that dynamically alter behavior based on location, entity type, or data classification. An agent operating within a shared workspace may apply different logging requirements or escalation paths when functioning in the EU versus Canada and adapt its data retention and encryption logic based on residency policies. These behaviors are governed declaratively through a shared workspace’s policy and schema infrastructure, rather than coded manually into every agent instance.

So, shared workspaces really do more than persist conversations and coordinate actions—they create the conditions for semantic interoperability across scale, time, and specialization. They serve as the scaffolding on which interaction protocols can be built, stabilized, and governed. As agent ecosystems grow in complexity, scale, and autonomy, this protocol layer becomes not just helpful but essential. It is what allows collaboration to shift from emergent behavior to deliberate system design, and what ensures that agent communication remains transparent, consistent, and governable in even the most demanding environments.

Agentic Mesh Shared Workspace Protocol

The following is an example of a tiered orchestration protocol inspired by the privilege rings of the Linux kernel which shows how to govern how agents may interact via a shared workspace.

Figure 4, Agentic Mesh: Shared Workspace Protocols

In Linux, Ring 0 is reserved for kernel operations, while user-level processes operate in higher rings with reduced privileges. This same concept can be applied to shared workspace systems.

At Ring 0, we define Kernel Agents responsible for core system operations: starting or stopping agents, managing system-wide configuration, and updating runtime policies. All messages are received first by kernel agents which determine if requests require system-level action. It alone has access to modify the registry of active agents, much like init or systemd in Linux.

All other non-system-level messages would be routed to Ring 1, where we they are intercepted by Orchestrator Agents which have full visibility into agent metadata and message flow. These agents serve as message routers, determining which agents should receive which messages based on purpose, scope, and priority. They rely on declared agent roles, metadata, and message classifications to make routing decisions. Orchestration agents identify the destination for a message and route to destination agents in to Ring 2.

At Ring 2, Goal-Oriented Agents manage multi-step goals or processes. These agents do not perform individual tasks but instead decompose higher-level intents into task plans and assign them to appropriate worker agents. Once worker agents have been identified, messages are routed to Ring 3.

Ring 3 hosts the Task-Oriented Agents, the execution layer of the system. These agents perform bounded, deterministic actions like calling APIs, generating reports, or transforming datasets. They operate with the least privilege—only reading what they need, writing task results, and adhering to strict access controls.

Ring 4 operates somewhat autonomously and hosts long-running Observer Agents, which continuously monitor external systems—logs, sensors, APIs—and summarize new events for the system. They don’t make decisions or act beyond aggregating and analyzing events and reporting results.

By combining these declarations with message routing and role-based access control, the system creates a governed, programmable, and scalable coordination layer—just as the Linux kernel enables user processes to interact safely with hardware and system calls. Where Linux uses syscalls, userspace, and daemons to enforce abstraction boundaries, the shared workspace ecosystem uses orchestration tiers, access protocols, and semantic schemas to manage agents at scale.

This ring-based orchestration protocol example provides both control and flexibility. Kernel agents safeguard the system’s integrity, orchestrators maintain signal routing and workload distribution, coordinators manage goal logic, and task agents execute work—all in a consistent, protocol-governed environment. While the examples above are illustrative, they show how Linux-inspired system design principles can inform a new kind of agent operating model—one not for people or processes, but for intelligent agents collaborating in structured, persistent, shared environments.

Conclusion

Call me biased, but I think shared workspace is a foundational shift in how agent ecosystems coordinate, reason, and scale. It enables structured memory and shared understanding across observer, task, and goal-oriented agents, anchoring collaboration in a common workspace rather than brittle point-to-point messages. We explored how shared workspaces enforce protocol-level consistency, support fine-grained security and governance, and enable robust abstractions for multi-agent planning and execution. From operational responsiveness to strategic forecasting, and from modular composability to institutional memory, a shared workspace redefines what it means for agents to work together effectively.

Agentic Mesh’s shared workspace seems more than a technical enabler. It unlocks new models for dynamic collaboration, long-lived autonomy, and cross-domain intelligence. With the right design, organizations can build ecosystems where agents don’t just assist, but participate—contributing to collective goals, adapting to new contexts, and improving over time. In doing so, a shared workspace becomes not just a coordination layer, but a catalyst for scalable, intelligent systems capable of solving increasingly complex, interconnected problems.

***

Feel free to reach out and connect with the author Eric Broda on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Thanks for reading AgenticMesh Substack! Subscribe for free to receive new posts and support my work.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

Introduction

Prompt engineering used to be a big deal. Then context engineering. But even this is a subset of the broader topic of agent memory management. In enterprise settings, memory is the full system by which an agent acquires facts, receives task-scoped context, carries state through execution, exchanges state with other agents, records what happened, and improves future work. The quality of that memory system often determines whether the agent behaves like a useful worker or an unreliable demo.

A useful frame comes from operating system design. A CPU cannot hold all of a program’s data in registers at once, so the OS maintains a working set — the subset of memory pages currently needed for execution — resident in RAM, while the rest remains on disk and is paged in on demand. Agent memory works on the same principle. The active context window is the register file: fast, small, and ephemeral. The task-scoped context package is the working set: curated, bounded, and loaded before execution begins. Long-term enterprise data is the disk: persistent, authoritative, and accessed on demand. The engineering problem in both cases is the same — deciding what needs to be resident, when, and at what cost.

Figure 1, Virtual Memory (Computer) vs Agent Memory

This article defines eight distinct forms of enterprise agent memory, explains how each is used at runtime, and describes the write path, lifecycle, and governance requirements that make a memory architecture production-worthy. These forms are: static memory, long-term enterprise memory, semantic memory, working memory, short-term memory, shared memory, episodic memory, and procedural memory.

They should not be collapsed. An organization’s systems of record are not the same thing as distilled business meaning. A replayable event history is not the same thing as a reusable operating procedure. A context package assembled for one task is not the same thing as the active context window during execution. Keeping these layers separate makes agent behavior easier to govern, reconstruct, and audit.

Figure 2, Agent Memory Types

Static Memory — The LLM

Static memory is the general knowledge and reasoning capability embedded in the model through pretraining. It includes language understanding, broad world knowledge, basic task-execution patterns, and multi-step reasoning. It is static because it does not update during task execution. The model does not permanently learn from each invocation. Every call begins from the same parameter state unless the model itself is retrained.

This is why static memory provides broad competence but cannot supply current enterprise facts. The model will not know the customer’s contract, the organization’s latest control procedure, or the correct interpretation of a local business term unless those facts are delivered at runtime through other memory layers.

Example: A retail agent receives a customer complaint written in colloquial language with missing punctuation and several unrelated details. It identifies the product, the claimed defect, the desired resolution, and the level of urgency — entirely from static memory. That interpretation becomes useful only when combined with order history, return policy, and inventory data from the layers below.

Long-Term Enterprise Memory — Systems of Record

Long-term enterprise memory is the organization’s persistent operational data: relational databases, document repositories, contract stores, knowledge bases, policy documents, source code, regulatory filings, and support histories. This layer is external to the model. It is where the actual state of the business lives.

Agents access this layer through tool calls, retrieval pipelines, or APIs into systems of record. The process definition determines what subset of enterprise memory the agent may access — and that boundary matters. Enterprise data access is an authorization problem and a data minimization problem. In regulated industries it is also a compliance problem. The memory architecture needs explicit controls over scope, source, and permitted use.

Example: A healthcare prior authorization agent retrieves the patient’s coverage plan, the clinical guidelines for the requested procedure, the prescribing physician’s credentials, and the insurer’s medical necessity criteria. None of those facts are in the model. They are persistent records that must be fetched under strict access controls and used as the factual basis for the determination.

Semantic Memory — Distilled Business Meaning

Raw records often lack the semantic structure needed for reliable reasoning. A database column named “exposure” in one system may correspond to “approved commitment” in another, and neither name reveals how the concept is used in a current credit decision. Semantic memory is the layer that resolves this: it contains stable concepts, definitions, taxonomies, relationships, policy interpretations, domain rules, and institutional abstractions that translate raw data into business meaning.

The structure is similar in intent to a personal knowledge tool like Obsidian. In Obsidian, notes are linked bidirectionally, concepts are connected explicitly, and the graph view makes relationships between ideas navigable rather than buried. An enterprise semantic memory layer does the same thing at a different scale: linked concepts and domain terms, explicit relationships between business entities, and navigable context that tells the agent not just what a data field contains but what it means. The differences are access controls, provenance tracking, versioning, and formal approval.

In a mature architecture, semantic memory is served through concept cards, policy cards, ontologies, data catalogs, and business glossaries. It reduces the probability that the agent retrieves technically relevant material but reasons over it incorrectly — a failure mode that is common and hard to diagnose from output alone.

Example: A credit adjudication agent pulls financial data from three systems. One labels a field “exposure,” a second uses “approved commitment,” and a third uses a legacy local term tied to an older workflow. Semantic memory tells the agent how these concepts relate, which one governs the current decision, and where the exceptions apply.

Working Memory — Task-Scoped Context

Working memory is the curated context package prepared for a specific task at a specific moment. It contains selected enterprise facts, semantic guidance, policy constraints, task instructions, and any supporting evidence the agent needs to begin. It is assembled before execution, not improvised by the agent during execution.

In enterprise architectures, this assembly should be handled by a governed pipeline — a context service or knowledge fabric — rather than by leaving retrieval strategy to each individual agent. The assembled package should be bounded, reconstructable, and auditable. If the agent makes a bad decision, the organization should be able to inspect exactly what information was delivered and in what form.

Working memory is distinct from short-term memory. Working memory is the input — the curated package. Short-term memory is the active context window once execution is underway.

Example: A pharmaceutical regulatory submission agent is tasked with reviewing a drug application against current FDA guidance. The context service assembles the applicable regulatory framework, the product’s clinical trial summaries, the relevant prior correspondence with the agency, and the internal review checklist. It excludes superseded guidance versions, unrelated product files, and internal marketing documents. The agent begins from a scoped packet rather than an open search against the full document repository.

Short-Term Memory — The Live Context Window

Short-term memory is the agent’s active context window during a single execution. It holds the system prompt, working-memory package, tool results, intermediate outputs, active notes, and any new human input received while the task is underway. It is ephemeral: it exists only for the duration of execution unless portions are summarized or persisted elsewhere.

The context window is constrained by token limits, latency costs, and competition between instructions, tool outputs, and retrieved data. As execution proceeds, tool results and intermediate reasoning accumulate. When the window fills, the system must trim, summarize, compress, or externalize state.

Example: A logistics agent resolving a shipment exception begins with the original order, retrieves customs documentation, pulls the carrier’s delay report, and receives an updated delivery window from the freight partner. All of that accumulates in the live context window while execution continues. When the task completes, that state disappears unless key outputs are written to the event stream or a case note.

Shared Memory — Inter-Agent Process State

In a multi-agent process, agents should not depend on direct pairwise handoffs. They should publish outputs into a controlled shared substrate — the communications fabric — where downstream tasks consume results according to process rules. This produces loose coupling and clearer observability. It also makes replay and audit straightforward because the state transitions are recorded in a single place rather than embedded in bilateral agent calls.

Shared memory is scoped to the process instance. One upstream output may fan out to multiple downstream agents. The process manager controls sequencing, dependencies, and access boundaries. Shared memory should not cross process-instance boundaries unless cross-instance access is explicitly designed and governed.

Example: In a manufacturing quality control flow, one agent inspects sensor readings from a production line and publishes a structured defect record to the shared fabric. A second agent classifies the defect against product specifications. A third determines whether the batch should be quarantined or released. Each reads from the shared process state rather than calling the others directly, and the full decision chain is reconstructable from the fabric’s event log.

Episodic Memory — Execution History

Episodic memory is the durable record of what happened across executions over time: task histories, decision sequences, tool calls, retries, failures, escalations, and outcomes. It supports audit, operational diagnosis, and compliance review. It also supports retrieval of prior similar cases to guide current execution.

These two uses have different quality requirements. For audit and diagnosis, completeness matters most — every step should be traceable. For experience retrieval, relevance and outcome quality matter most — a retrieved prior case that was handled incorrectly is worse than no retrieval at all. Retrieval from episodic memory needs filtering by outcome quality, not just task similarity.

Example: An IT operations agent handling infrastructure incidents finds that a specific class of memory leak in a containerized service recurs after deployments on Tuesday evenings. The episodic record surfaces the pattern across twelve prior incidents: same service, same deployment window, same remediation path. Future incidents in that window can be routed directly to the proven resolution sequence rather than treated as novel.

Procedural Memory — Reusable Execution Methods

Procedural memory is the remembered method for performing a class of tasks: playbooks, standard execution sequences, escalation rules, and reusable subtask patterns that persist across runs. An agent system that rediscovers the correct execution approach on every run is wasting resources and introducing variance.

Procedures should not form implicitly. A production architecture needs a defined path by which candidate procedures are observed, evaluated, approved, versioned, and promoted into durable use. An unreviewed habit promoted silently from a few successful runs is a hidden behavior change, not a governance mechanism.

Example: A procurement agent processing vendor onboarding learns that applications move fastest when sanctions screening is completed before legal review begins, and that incomplete tax documentation should trigger a structured information request rather than a hold. Once that sequence is verified across enough cases, it is promoted into procedural memory and applied consistently — rather than rediscovered on each new application.

The (Memory) Write Path

A complete architecture needs more than a read path. It needs a write path. Facts, corrections, case notes, summaries, and candidate procedures are produced during every execution. The write path determines what gets preserved, in what form, and in which store.

The write path should distinguish three stages: raw observation, candidate memory object, and approved durable memory. Not every tool result should become memory. Not every successful run should produce a procedure. Candidate memory should be extracted, typed, validated, deduplicated, attributed to a source, and only then promoted into the appropriate store. Some items belong in episodic history only. Some should become semantic annotations. Some should update a procedure. Some should be discarded.

The store that receives everything becomes unreliable faster than the store that receives nothing.

Lifecycle — Retention, Compression, and Expiry

Memory has a lifecycle, and that lifecycle must be engineered explicitly.

Short-term memory must be trimmed during execution. Working memory must be bounded before dispatch. Shared memory should expire with the process unless retained for a defined purpose. Episodic memory may require archival tiers as volume grows. Semantic memory needs periodic review and refresh. Procedural memory requires version control and retirement when it no longer matches current controls.

Figure 3, Agent Memory Types

Forgetting in this case is a design requirement. The system should define what is retained, for how long, at what fidelity, and under whose authority. Memory objects that are stale, superseded, or no longer permitted to persist should be deleted or archived on a defined schedule. A memory architecture without lifecycle controls becomes slower, more expensive to operate, and harder to audit.

Quality, Conflict, and Governance

Memory can be wrong. Enterprise systems routinely contain duplicate records, contradictory interpretations, stale notes, outdated procedures, and local conventions that were never formally approved. A production memory architecture must account for this.

Source precedence, freshness rules, provenance, confidence, approval status, and override logic should all be explicit. If a human annotation conflicts with formal policy, the system needs a defined resolution path — not an implicit one. If a stored procedure no longer matches current controls, it must be versioned out or revoked.

Governance applies separately to read access and write authority. Who may retrieve a memory object is one question. Who may create, approve, modify, or retire it is another. Durable memory objects should carry lineage, timestamps, ownership, and status. In regulated environments, that metadata is an operating requirement. Without it, an organization can show what the agent saw but cannot demonstrate whether the memory itself was valid, current, or authorized for use at that point in time.

Conclusion

Enterprise agent memory is a layered system, not a single store. Each layer has a distinct function, and collapsing them produces systems that are harder to govern, harder to audit, and harder to improve.

What distinguishes a production deployment from a demo is not the model. It is the memory architecture around it — whether facts are sourced and scoped correctly, whether context is assembled and bounded before dispatch, whether execution state is governed and auditable, and whether the system improves over time without silently accumulating bad habits. Those properties are determined by memory architecture, not model capability.

***

Feel free to reach out and connect with the author Eric Broda on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout my new book, “Agentic Mesh”, with O’Reilly, and on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

Introduction

Last year, we built an agent-enabled document ingestion pipeline — it accepts unstructured input (documents), extracts structured data, and routes it downstream for processing. Getting a credible demo ready took eight weeks using a combination of coding agents and experienced developers. This was 9 months ago, and the coding agents were not all that great. We recently rebuilt the same demo from scratch in one week. Larger scope, lots more features, greater fidelity. The coding agent, now guided by experienced developers, handled scaffolding, API wiring, and UI assembly at a speed that would have been difficult to believe a year earlier.

The next step: the pipeline required enterprise-grade capabilities: identity integration, secrets management, role-based access, and observability. These are not features you bolt on after the fact but instead require deep architecture knowledge, infrastructure experience, and judgment. Adding them took the same kind of hard work it has always taken. The agent had compressed the path to a demo dramatically. It had not given as much benefit as we considered adding enterprise-grade capabilities required for a production deployment.

That gap is the story. Coding agents are powerful accelerators inside a defined technical boundary — contained scope, known technical surface, clear specification. Outside that boundary, or when asked to define one from scratch, they need help.

There is a second pattern we saw: current tools are highly effective for local, personal, bounded work. But their design assumes proximity to a developer, a terminal, a repository, and a personal directly guiding the work. The farther work moves from that setting — into shared business processes, cross-domain systems, governed enterprise data, and production infrastructure — the weaker the fit becomes.

So, yes, coding agents are great and, in fact, we use them every day and see huge benefits. But, today, there are still gaps. As your firm adopts agents, you should go forward with your eyes wide open.

Figure 1, What Works, and What Does Not Work (Yet)

What Works

Contained Applications (Well understood, limited, scope)

The clearest win for coding agents is building applications where scope is bounded (and limited) and well understood by the developer. Single-page tools, internal dashboards, API adapters, proof-of-concept services, form-based workflows — this is where the tools perform best. Scope is limited, inputs and outputs are visible, and hidden dependencies are modest.

Productivity gains in this territory are often measured in multiples rather than percentages. Project skeletons, routing wiring, library selection, and repetitive glue code collapse into a conversation plus review. The result may still need cleanup, but elapsed time changes materially.

The document ingestion scenario I mentioned earlier illustrates the principle. The agent scaffolded the interface, wired the API, generated extraction flows, and produced a working routing view quickly because the perimeter was already understood. So, yes, we made it work because we understood the problem and it had a known shape. However, without our help, the agent alone would not have discovered that shape from scratch or extend it into the production environment where the shape was imposed by organizational constraints rather than by the problem itself.

This class of work includes greenfield UI, integration wrappers around stable APIs, repetitive refactors within a known architecture, and code generation against a clear specification. In every case, the agent fills in the interior of a frame that already exists. It does not define the frame.

Cheaper Iteration, Faster Iteration, Radically Reduced Time to Feedback

The more important gain is often not the code itself — it is the reduction in the cost of trying an idea.

When each iteration costs minutes instead of days, a team behaves differently. It tests alternate structures, tries a different framework, generates three versions of a data flow instead of arguing about one in the abstract. Dead ends become cheap enough to test instead of debate. Questions that previously remained open until late in the project can be resolved early with a concrete artifact.

This is one reason coding agents are already valuable even where their output requires extensive review. They compress exploration. A team that can run through five viable options in a day will usually make better decisions than a team forced to choose one option up front because each iteration is expensive. The agent does not remove the need for judgment; it moves judgment earlier, against something tangible rather than abstract.

That advantage matters most in early-stage work, internal tooling, experimental features, and low-risk workflow automation — settings where flexibility and iteration matter more than production hardening.

Orientation and Learning

Coding agents can generate working examples in an unfamiliar framework, demonstrate how a library is used, and sketch the rough structure of an API integration far faster than most people can extract the same picture from documentation alone.

A generated example may contain poor assumptions or brittle structure. It still helps a developer get oriented faster. A person evaluating several options on a short deadline can use an agent to get a first executable pass and then inspect, refine, or discard it. The startup cost of entering adjacent technical territory drops substantially.

For organizations, this lowers the friction of experimentation and tool evaluation. For individual practitioners, it shortens the path from question to first implementation. The generated artifact is not the answer; it is a starting point that would previously have taken days to reach.

Legacy Migration

One of the most practically useful enterprise applications is legacy migration, provided the problem is decomposed correctly. Large migration programs contain enormous volumes of repetitive mechanical work: syntax transformation, API substitution, boilerplate generation, framework conversion, and test stub generation across many files.

Agents handle this well when the work unit is bounded and the migration rule is explicit. A service, module, or interface layer can often be transformed with substantial time savings. A large legacy estate handed wholesale to an agent will not convert cleanly.

However, the harder part remains outside the agent’s reach. Legacy systems contain undocumented business rules, workarounds that became de facto requirements, and behavior whose intent is unclear even to the current team. The agent can transform code. It cannot determine whether a subtle branch reflects a genuine business rule, a historical defect, or a compatibility hack nobody wanted to touch. Humans make those calls. The agent accelerates the mechanical volume around them.

Business Users as Bounded Builders

A business user with a coding agent can build a functional demonstration of a workflow, a dashboard, a lightweight operational tool, or a prototype that communicates a process clearly. The person closest to the business problem can create an artifact directly instead of routing every idea through an engineering queue.

Today we see business users building major parts of products independently. But they can’t (yet) work alone the technical boundary is supplied for them — approved components, preconfigured environments, managed deployment rails, known data contracts, and review checkpoints. Inside those rails, they can move quickly. Outside them, technical partnership remains necessary.

This changes how work can be split. The old model placed business users on one side and engineers on the other. The new model allows concurrent work inside a managed technical envelope, provided the organization is disciplined enough to make the envelope explicit and enforce it.

Where Coding Agents Need Help

The most common failures with coding agents cluster around system-scale coherence, production operating context, correctness validation, and governance. These are structural limits tied to how the tools currently operate, not surface-level inconveniences.

Figure 2, What Works, and What Does Not Work (Yet)

System Scale

A single-page application can fit in the scope and knowledge of a person and work well with modern coding agents. A large system with distributed components, shared state, layered dependencies, cross-cutting policies, and multiple implicit invariants usually cannot.

One practical difficulty is that as a codebase grows, agent coherence tends to degrade. It changes one file and quietly breaks assumptions in another. It reintroduces patterns already present elsewhere under a different name. It duplicates logic because the prior implementation was not visible at the moment of generation. It applies a local patch that conflicts with the system’s broader direction. Will this change? Probably. But today is it a real challenge.

Some may think this is primarily a token-limit problem. This is not the case! Large systems are held together by architecture, conventions, hidden dependencies, domain assumptions, and operating constraints that live across code, documentation, infrastructure, and people. An agent can access fragments of that information. It does not maintain an integrated, durable model of the whole.

Code quality problems from this cause tend to appear as coherence problems: flat structure, excessive defensive code, repeated logic, ad hoc schema manipulation, and thin abstractions. The agent solves what is visible now. It does not reason over the lifetime of the software. Teams that accept agent-generated code too quickly and too literally often find it becomes harder to maintain not because it fails immediately, but because the system accumulates local solutions with weak global structure.

Cross-Domain Work

The coherence problem becomes more serious when software crosses business domains. A workflow that touches order management, inventory, billing, compliance, and customer communication does not merely involve more code. It involves domain logic accumulated over time, often inconsistently documented and unevenly distributed across systems and people.

In cross-domain work, the most important constraints are frequently invisible in code alone. They are carried in policy, operations, institutional memory, exception handling, service agreements, and informal knowledge of how the business works. This is the knowledge that surfaces late when it is missed. The code compiles, the flow runs, and the assumptions are wrong in three quiet ways that only appear in production.

I think the root cause is this: human practitioners often underestimate how much of their own cross-domain understanding is tacit until a coding agent produces a perfectly reasonable implementation that misses it.

The Production Gap

A working demo lives in a controlled setting. The environment is shallow, authentication assumptions are simple, services are reachable, and the deployment path may still be manual. The agent performs well because the operating context is minimal.

Production considerations impose a different set of requirements. Session handling that looked fine in a simple setting did not survive a real token refresh model. Environment assumptions that held locally failed in staging. Service wiring that was trivial on localhost had no direct counterpart in the actual cloud topology. These were ordinary production issues, not edge cases. Every senior engineer has seen them before. The agent had no basis for anticipating them.

A platform engineer or senior application engineer carries much of this context implicitly (the tacit knowledge that experts have that is so valuable). They know the organization’s identity stack, secrets patterns, deployment mechanics, monitoring requirements, and operational norms. The coding agent does not have that knowledge unless it is explicitly supplied, and even then it does not internalize the trade-offs the way an experienced practitioner does. Secrets management, deployment automation, observability, rollback strategy, and resilience are not features that emerge from a better prompt. They require architectural decisions made by someone who understands the operating environment.

Correctness Validation

Coding agents can generate unit tests, sometimes quickly and usefully. Generating tests is not the same as validating correctness.

Correctness in enterprise software involves integration behavior, business rules, edge cases, policy obligations, timing assumptions, error semantics, and expected operational behavior. In many systems, “correct” is partly defined by business acceptance criteria that are not fully expressed in code. An agent can only validate against criteria that exist. If the acceptance conditions are weak, incomplete, or implicit, the agent cannot close that gap.

The same constraint applies to debugging. Agents often handle direct, visible failures well: missing imports, type mismatches, known library usage problems. Multi-layer failures are harder. If a problem spans API behavior, infrastructure configuration, authentication, and environment-specific assumptions, the agent tends to patch the nearest visible symptom rather than trace the root cause through the system. A good engineer debugs through a system model. An agent debugs through the local visible surface and tool outputs.

Security and Governance

Agents can generate code that appears functional while embedding weak defaults, broad permissions, or unsafe runtime behavior. The risk is not only in the produced application. If the agent has wide local access, broad network reach, shell execution, and visibility into credentials or sensitive files, the harness itself becomes part of the security problem.

Current coding-agent harnesses were designed for personal productivity. They assume a local machine, a local terminal, local repositories, and a nearby human. That is a reasonable design for personal work. Enterprises need stable identity, scoped permissions, observable actions, auditable access, and shared policy enforcement. The transition from personal coding agent to enterprise coding agent is not primarily a model quality problem. It requires changes to the surrounding control plane: identity, authorization, logging, policy boundaries, data access mediation, and execution isolation. Better model output does not substitute for that infrastructure.

Harnesses Matter as Much as More than the Models

The industry has recognized that coding outcomes are shaped by the harness around the model: how context is assembled, what tools are available, how memory is stored, how long-running work is managed, how shell access is controlled, how repository structure is presented, and how review is integrated into the workflow.

Figure 3, Personal/Local Harness vs Enterprise Harness

Current harnesses are heavily optimized for local and personal work — context from local repositories, memory in local files, a single user nearby for feedback and correction. This design is one reason coding agents feel effective today. It matches a real use case well.

Enterprise context does not work this way. It lives across governed systems, service boundaries, documents, tickets, repositories, policies, databases, runbooks, and identity-constrained applications. Enterprise memory cannot be a set of local files on one machine. Enterprise action cannot rest on proximity to a developer alone.

These are two distinct categories. The first is a personal or local harness, where the agent is a powerful extension of an individual developer. The second is an enterprise harness, where the agent works as one participant in a governed technical and business ecosystem, where agents participate fully in business processes. The first category is already highly productive. The second is still immature. Many discussions about coding agents blur these two categories together, which is why organizations see strong gains in local development work and are surprised when the same pattern does not carry into enterprise production delivery. The surrounding system is different.

What a Well-Defined Boundary Actually Looks Like

The governing principle across this article is that coding agents are powerful inside a well-defined boundary and unreliable outside one. That principle is only useful if the boundary can be made concrete.

A well-defined boundary has five characteristics.

• Decomposed work units: The task handed to the agent should have clear inputs, clear outputs, and a scope small enough to fit in the agent’s effective working context. Handing an agent a service is better than handing it a system. Handing it a module is better than handing it a service. The tighter the scope, the more reliable the output.

• Explicit acceptance criteria: The agent cannot validate against conditions that do not exist. Before generation begins, the correct behavior needs to be specified — happy path, edge cases, error conditions, and business rules. Generating code first and writing tests afterward produces plausible output, not validated output.

• Supplied operating context: Production constraints do not emerge from a prompt. Identity patterns, secrets handling, deployment targets, observability requirements, and infrastructure topology need to be supplied explicitly, either as documentation the agent can reference or as preconfigured rails it operates within. The agent should not discover these through trial and error.

• Structured review checkpoints: Agent output requires review calibrated to the risk level of the work. Greenfield internal tooling needs less scrutiny than code touching customer data, regulated workflows, or production infrastructure. Review should be designed into the workflow, not added afterward when something goes wrong.

• Managed technical rails for non-technical builders: When business users are building inside the envelope, the envelope needs to be enforced. Approved components, locked deployment paths, and identity-integrated environments are preconditions, not optional additions. The business user’s freedom to move quickly depends on the engineer’s prior work to make the boundary safe.

Organizations that can consistently supply these five things will get reliable, compounding value from coding agents. Organizations that cannot will continue to get excellent demos and uneven systems – the demo will be science experiments that never make it out of the lab.

Adoption Will Be Uneven

Large enterprises, particularly risk-averse ones, should be expected to adopt coding agents more slowly in production contexts. The cost of mistakes is higher and the operating constraints are denser. Security review, architecture governance, identity standards, compliance obligations, and incident management requirements do not disappear because a tool is productive.

This slower pace should not be surprising. New technologies usually deliver limited gains at first when organizations try to fit them into old operating models. Early factories did not realize the full benefit of electricity when they used it simply to power the same centralized layouts built for steam. The larger gains came later, when work was reorganized around distributed electric motors and the factory itself was redesigned. Large firms are likely to follow a similar path with coding agents: adoption will be slower where the work, controls, and engineering process have not yet been reshaped to use them properly.

The practical pattern that will emerge is a split. Large organizations will move quickly on internal prototyping, developer productivity support, documentation generation, test assistance, and bounded internal tools. They will move more slowly when agents touch customer-facing systems, regulated workflows, or production decision paths. Both paces are rational given the different risk profiles.

The slower pace in production contexts should not be read as lack of conviction. It reflects the fact that enterprise adoption is not just model adoption — it is operating-model adoption. A large firm must decide how coding agents fit into engineering standards, access control, software delivery quality gates, auditability, and accountability. That takes time regardless of how good the model is.

The Engineer’s Role

Coding agents change where scarce engineering value lies. When code generation accelerates, the relative importance of decomposition, architecture, interface design, validation, security posture, and operating judgment increases. Engineers spend less time on mechanical production and more time on framing, control, and review.

This is already visible in practice. A strong engineer working with a coding agent spends substantial time specifying the work unit, selecting the right context, checking assumptions, shaping the architecture, reviewing generated output, and deciding whether to accept, revise, or discard it. The work becomes more supervisory in some phases and more design-intensive in others. Neither phase is less technical than what it replaces.

Less experienced developers can gain from coding agents, but they face a specific risk: velocity without judgment. If a person can generate code faster than they can evaluate it, apparent productivity can outpace actual understanding. Strong standards, modular systems, disciplined review, and good tests increase the chance that agent-assisted work remains sound. Weak engineering environments can absorb a certain rate of low-quality output. Coding agents increase that rate.

The Operating Guidance

Use coding agents aggressively where the boundary is clear. Use them deliberately where it is not.

They are reliable for bounded application work, interface generation, mechanical migration, scaffolding, local automation, test assistance, documentation support, and rapid iteration around known surfaces. They are reliable when a business user is building inside a managed technical guardrail, and when a human expert has defined the scope and can review the outcome.

They become unreliable when expected to define architecture across large ambiguous systems, integrate multiple business domains from partial context, infer enterprise operating requirements, validate business correctness from code alone, or absorb production responsibility without a strong control layer.

The quality of results depends on the quality of the boundary. A good boundary — decomposed tasks, explicit acceptance criteria, supplied operating context, structured review, and managed rails — turns the agent into a force multiplier on well-framed work. A weak boundary allows the agent to produce plausible output in places where plausible is not enough.

Conclusion

The document ingestion pipeline is a fair summary of the current state. One week to rebuild a demo that previously took twelve weeks. The same elapsed time to get it into production as it ever was.

Coding agents are already highly effective in the environment they were designed around: local context, local memory, local files, immediate feedback, and bounded technical surfaces. The tools are not a disappointment. They are a genuine shift in how contained technical work gets done.

The gap between that and enterprise-scale production delivery is real and will not be closed by better model output alone. It requires better decomposition practices, stronger context engineering, explicit acceptance criteria, hybrid review models, clearer boundary definitions for business users, and enterprise harnesses built for governed participation rather than local convenience. Organizations that do that work will get compounding value. Organizations that skip it will get excellent demos, uneven systems, and hard lessons at the production boundary.

The question is no longer whether coding agents are useful. The question is whether your organization has done the work to define where they are useful and under what conditions — and whether the engineering system around them is strong enough to make the answer durable.

***

Feel free to reach out and connect with the author Eric Broda on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

Agentic Process Automation: A Process Architecture for the Agent Era

The organizing structure that makes an enterprise agent ecosystem manageable, deployable, and governable is the business process. Agentic Process Automation (APA) provides the process architecture — control plane, process definitions, and collaboration fabric — that turns a mesh of agents into managed and governed participants in enterprise business processes.

From Models to Agents to Agentic Processes

The conversation around enterprise AI agents tends to focus on model capabilities: reasoning, tool use, planning, multi-step execution. The harder problem is where the agent runs, what governs it, what connects it to enterprise data, and what ensures it operates consistently across runs.

Figure 1, Agentic Process Automation Architecture

Agentic Process Automation (APA) is an operating architecture — an integrated design that provides the runtime, control plane, knowledge infrastructure, and coordination fabric that enterprise agents require to participate in real business processes.

APA has several major components. At the top sits the Process Manager and Registry, which together form the control plane. Below them are Process Definitions — the blueprints for work. Agents execute within those definitions. A Communications Fabric connects everything at runtime. Three foundation layers — Enterprise Data, Context Serving through the Agentic Knowledge Fabric (AKF), and Trained Memory (the LLM) — provide the grounding that agents depend on to do useful work. On the sides, Development tooling (Marketplace, Process Workbench, Agent Workbench) and Operations tooling (Monitor, Operations Console) support the full lifecycle.

Each of these components exists for a reason. The sections that follow walk through each one in order.

Defining Agentic Processes

Enterprise agent systems start with explicit process definitions. A process definition in APA is built from three primitives. Tasks are executable work steps that agents perform. Decisions are branching steps that evaluate conditions and choose the next path. Connections are edges that link steps together and define flow. That is the entire vocabulary. Every process, regardless of complexity, is composed from these three building blocks.

Figure 2, APA Process Definitions

This simplicity is deliberate. By decomposing work into discrete steps with visible branching logic, process definitions make execution paths auditable and governable. Every task is a named unit of work. Every decision point is explicit. Every path through the process can be traced.

Importantly, the process is the architecture pattern for agent deployment. Agents in APA are deployed inside processes, where each task node acts as the execution boundary for a specific unit of work. The process definition determines what gets done, in what order, under what conditions, and by which agent.

This is where APA diverges from traditional process automation. In conventional BPM or RPA, tasks are rigid scripts or rule-based steps. They execute fixed logic against structured inputs. When the input is ambiguous, unstructured, or outside the predefined rules, the task fails or requires human intervention.

In APA, each task is backed by an agent powered by an LLM. That agent can interpret unstructured inputs, reason over incomplete information, and make judgment calls that rule-based executors cannot. A claims processing task in a traditional workflow either matches its rules or escalates. The same task in APA can read a free-text claim narrative, cross-reference it against policy terms, identify ambiguities, and make a coverage determination within the scope of a single task node.

Agents also bring internal execution capacity that traditional task executors lack entirely. An agent assigned to a task can decompose its own work internally: calling tools, invoking LLM-specific sub-agents, executing multi-step reasoning chains, searching documents, and writing intermediate outputs. The task definition sets the scope and contract. The agent decides how to fulfill it. This keeps the process definition clean and high-level while individual agents handle meaningful, complex work at the task level.

What the Task Boundary Makes Possible

That same decomposition changes how people interact with the system. Human interaction is best handled at the process or task context, where a person can review the business objective, the current state, and the expected outcome of a bounded unit of work. It is a poor fit at the agent runtime itself, such as a raw Claude Code session, where the interaction surface is tied to internal execution details rather than business context. APA places human participation at the process and task level, where approvals, clarifications, escalations, and overrides align with the work structure itself.

Process and task decomposition also change the model strategy. A monolithic agent design tends to bind the whole workflow to one model stack and one vendor’s strengths and limitations. APA decomposes the workflow into bounded tasks, which means each task can be assigned the most appropriate agent and model for that unit of work. One task may use a reasoning-heavy model, another may use a fast extraction model, and a third may use a vendor-specific coding or search agent.

This structure also creates the opening for a more controlled use of loosely bounded agents. General-purpose runtimes such as Claude Code or Codex may still execute rich internal reasoning and tool use, but they do so inside a task with a defined purpose, input, output, and authorization boundary.

This means a process can incorporate powerful general-purpose agents without requiring those agents to become the process architecture themselves. The task boundary holds the business structure, while the agent supplies execution depth inside it. That separation is what allows enterprise systems to use flexible agents while still preserving process shape, human checkpoints, and governed flow.

The Control Plane: Process Manager and Registry

The Process Manager is the runtime orchestration layer. It launches process instances, advances execution from step to step, dispatches tasks to agents, handles branching logic at decision nodes, tracks status, and manages pauses, failures, and completion. It is the engine that turns a static process definition into a running operation.

Figure 3, APA Process Manager and Registry

The Registry is the persistent store where process definitions and agent definitions are registered and retrieved. It is the system’s source of truth for configuration. When the Process Manager needs to launch a process or assign work to an agent, it retrieves the relevant definitions from the Registry. This separation means execution is always consistent with the declared design, and definitions can be updated, versioned, and audited independently of the runtime.

Together, the Process Manager and Registry form the control plane. The core argument is pretty simple: agents cannot participate safely in enterprise processes without something that dispatches work, enforces sequencing, handles exceptions, and retrieves authoritative definitions. The control plane provides that.

The control plane also solves the distributed orchestration problem. In APA, a process may involve multiple agents running in different environments, with different capabilities, owned by different teams. The Process Manager orchestrates across that distribution. It does not need to know the internal workings of each agent, but it definitely needs to know the process definition, the current state of execution, and which agent is responsible for each task.

This is process-level orchestration of distributed agents. In coding/personal agents, orchestration is handled inside single agent. In APA, coordination happens at the workflow layer. One agent might run locally. Another might be a hosted service. A third might be a specialized sub-agent owned by a different department. The Process Manager dispatches to all of them through the same mechanism, tracks their results through the same state model, and advances the process through the same defined flow.

This is also where vendor heterogeneity becomes operationally manageable. The process manager can dispatch work to a coding agent, a retrieval agent, or a specialized decision agent through the same task abstraction, even when those agents come from different vendors and expose different internal mechanics. The control plane standardizes how work is assigned, tracked, and completed without requiring a common internal runtime across agents.

Multi-Agent Support – Event Normalization

In practice, every agent runtime emits its own event vocabulary. Claude Code produces events like task_started, tool_use, tool_result, thinking, and content_block_delta. OpenAI’s Codex produces a different set: tool_called, handoff_requested, reasoning_item_created, mcp_approval_requested. These are different event models with different granularity, different lifecycle assumptions, and different semantics for similar operations.

Figure 4, APA Agent event Normalization

APA addresses this through event normalization. Raw events from heterogeneous agent runtimes are normalized, standardized, aggregated, and filtered before they enter the process-level event stream. The normalization layer sits between the agent runtimes and the process-level event model. It translates vendor-specific telemetry into a common vocabulary that the rest of the architecture can consume without knowing which agent or vendor produced it.

The normalized event model operates at three levels. Process Events capture the lifecycle of the process instance itself: started, completed, failed, paused, resumed. Task Events capture the lifecycle of individual work units: ready, assigned, completed, failed, input requested, input received, paused, resumed. Agent Events capture what happens inside a task execution: agent started, agent completed, plan available, run started, completed, handoff, tool started, tool completed, tool failed.

Each level serves a different audience and a different operational concern. Process events tell operations whether the business workflow is progressing. Task events tell the control plane whether individual units of work are completing and whether human input is needed. Agent events tell diagnostics teams what happened inside a task when something went wrong. All three share a common event schema and flow through the same communications fabric.

Without normalization, cross-vendor observability is not practical. An operations team tracing a failure across a Claude Code extraction task and an OpenAI screening task would need to read two unrelated log formats, reconcile two different lifecycle models, and manually reconstruct the execution sequence. With normalization, the same trace appears as a single stream of process, task, and agent events regardless of which runtime produced them.

Agents as Bounded Process Participants

Within APA, an agent has a specific definition. An agent has a persistent identity and a defined role. It may have skills and access to tools. It can execute work and participate in decisions. It appears as a node inside a process definition.

This is a description of a bounded, accountable process participant. The identity is stable across process instances. The role determines what the agent is authorized to do. The skills and tool access determine what it is capable of doing. The process definition determines when and where it acts.

Figure 5, Agents – Bounded Process Participants

Each task node in a process definition provides an explicit demarcation point for security, identity, roles, and access rights. When the Process Manager dispatches a task to an agent, that dispatch carries the task’s security context: which agent identity is executing, what role it holds for this task, what data and tools it is permitted to access, and what actions it is authorized to take.

The task boundary is where governance is enforced. It is a scoped authorization tied to a specific unit of work inside a specific process instance. The same agent could hold different access rights at different tasks within the same process, or across different processes. Governance is a property of the agent-task binding.

This architectural choice makes access control granular, auditable, and aligned with the structure of the work being done. It also introduces new mechanisms for security and control. Because the boundary is the process task rather than the agent as a whole, permissions can be tied to business purpose, input and output contracts, allowed tools, permitted collaborators, and required approval points. Security policy becomes structurally aligned with process design rather than retrofitted around a general-purpose runtime.

A payment remediation process makes the point concrete. The same reconciliation agent may have read-only access when investigating a mismatch, approval rights when assigned a settlement decision, and no access at all to unrelated treasury systems. The agent identity is stable, but its authority is scoped by the task it is executing.

This distinction is probably most important for loosely bounded agents. Consider Anthropic’s Claude Code (OpenAI’s Codex is the same): its value comes from flexible tool access and open-ended problem solving. Constraining Claude Code at the Claude Code level is difficult, because restricting its tools or scoping its file system reach usually requires runtime configuration that sits outside any particular business process and applies uniformly regardless of context.

Constraining Claude Code at the process-task level is cleaner. The boundary is external to the agent. It is declarative and is defined in the process definition and enforced by the Process Manager. And it is contextual so that different tasks can grant different access rights to the same agent based on what the work requires. The process definition applies the constraint. Security, tool access, inter-agent communication permissions, and data access rights are all properties of the task (instead of properties of the agent). The agent operates at full capability within whatever boundary the task defines.

The Communications Fabric: Coordination at Scale

The Communications Fabric is the runtime substrate that connects agents, the Process Manager, enterprise data services, and context serving. It uses publish-subscribe and event streaming as its primary communication pattern, implemented on infrastructure such as NATS/JetStream or Kafka.

Figure 6, APA Communications (Events/PubSub)

Three properties matter.

First, the pub-sub pattern decouples producers from consumers. Agents know about each other indirectly, when they publish events and subscribe to relevant channels. This supports asynchronous coordination and makes the system tolerant of agents running at different speeds, in different locations, or on different schedules.

Second, a global namespace simplifies discovery and networking. Agents and services are addressable by name, which eliminates the need for point-to-point connection configuration as the number of agents and services grows.

Third, event stream persistence supports replay and diagnosis. Every event in the fabric can be stored, replayed, and inspected. This provides the observability backbone that operations teams need to understand what happened in a process execution, diagnose failures, and audit agent behavior after the fact.

The fabric also broadens observability. APA can still capture detailed telemetry from any participating agent: tool calls, task start and stop events, sub-agent invocations, retries, failures, and execution timing. The difference is that these signals no longer remain trapped inside one agent runtime. They can be emitted onto the shared fabric and correlated at the system level, which creates a new level of observability across processes, agents, vendors, and models. A tool call made by one agent and a pause event emitted by another can be understood as part of the same business execution trace.

A concrete case is a sanctions-screening flow that uses one vendor’s document-extraction agent, a second vendor’s screening agent, and an in-house exception-handling agent. A false match may only surface after the screening stage, even though the root cause was an extraction error two steps earlier. With a shared event stream, operations can replay the execution, correlate the extraction output, screening decision, and exception path across vendors, and isolate the exact failure mode without relying on three disconnected logging systems.

The fabric is what makes distributed agent orchestration practical at scale. Without it, the Process Manager would need direct connections to every agent and service. With it, coordination happens through the event stream. The Process Manager publishes task dispatches. Agents subscribe, execute, and publish results. Context services respond to requests over the same fabric. The architecture scales because the fabric scales.

The pub-sub model also matters for agent-to-agent coordination. In many enterprise processes, one agent’s output is another agent’s input. The fabric handles that task handoff without requiring the agents to know about each other. They communicate through events on named channels, and the Process Manager controls sequencing.

The Grounding Layer: Enterprise Data, Context Serving, and Trained Memory

Three infrastructure layers sit at the base of the architecture and provide the grounding that makes agent execution useful and trustworthy.

Figure 7, APA Memory

Long-term memory (which is also dynamic) is an enterprise’s data including databases, standard operating procedures, audio/video, and documents. These are the organization’s operational records that become the source material that agents need to reference when performing tasks. That data exists in enterprise systems (and, perhaps obviously, not in the LLM’s training set).

Working memory, made available through context serving is implemented through the Agentic Knowledge Fabric (AKF), is the layer that assembles and delivers runtime context to agents as they execute tasks. Rather than leaving agents to retrieve information from general-purpose indexes or rely on parametric model knowledge, the AKF curates and delivers relevant information at the point of work. The context an agent receives is scoped to the task, assembled from authoritative sources, and delivered through a controlled pipeline.

That control is architecturally necessary. Without it, agents build or retrieve context through ad hoc retrieval pipelines, task by task and team by team. Context quality then varies across processes, the basis for a decision becomes hard to reconstruct, and there is no reliable audit trail of what information the agent used. The result is inconsistent execution and weaker governance.

Static memory refers to the LLM itself, or more specifically the general reasoning and language capability that agents draw on. The LLM provides the ability to interpret natural language, reason over complex inputs, generate structured outputs, and make decisions. But it probably is insufficient on its own. Without enterprise data and context serving, the LLM has general intelligence but no grounding in the specific reality of the organization.

The lending decision example makes the layering concrete. The model provides language and reasoning capability. Enterprise systems provide applicant data, policy documents, and regulatory rules. The AKF assembles the subset relevant to the current underwriting task, packages it into task-scoped context, and delivers it at execution time.

The argument is that useful enterprise agency depends on governed data access and deliberate context assembly. The AKF bridges enterprise data and agent execution. It ensures agents work with the right information, scoped to the right task, delivered through a pipeline that can be audited and controlled.

Lifecycle Tooling: Development and Operations

Development tooling covers the Marketplace, where reusable process templates, agent definitions, and composed workflow patterns can be published for others in the organization to discover and reuse. A central platform team may publish a standard claims intake process, a risk team may publish an approved screening agent, and line teams may consume and adapt those building blocks rather than starting from scratch. The Process Workbench provides design and testing capability for process definitions. The Agent Workbench supports building and configuring agents, including defining their identity, roles, skills, and tool access.

Operations tooling covers the Monitor, which provides runtime observation of running processes and agent behavior, and the Operations Console, which supports management of the production environment.

Synthesis: APA as a Coherent Operating Architecture

Maybe it is obvious by now, but none of these components work in isolation. The process definition is inert without the Process Manager to execute it. The Process Manager is blind without the Registry. Agents are ungoverned without task boundaries. Task boundaries are unenforceable without the control plane. Coordination is impossible without the fabric. Execution is ungrounded without enterprise data and context serving.

Agentic Process Automation’s architecture dictates that enterprise agent systems require all of these components, designed together, operating as one coherent architecture. So, yes today’s focus on models is important. But as importantly, it is the architecture around that makes it production-ready.

***

Feel free to reach out and connect with the author Eric Broda on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

The Emerging Agent Economy - Who Wins, and How?

In the emerging agent economy, who wins and how will be determined by which organizations learn to re-architect their work around agents - using them to build cheaper, iterate faster, experiment more and open the door for tiny teams to play on a giant stage.

Introduction

Between our client work and John’s (the co-author of this article) vantage point in the middle of San Francisco’s agent boom, we now have a front-row seat to how quickly the ground is shifting. Here is what we are seeing and hearing:

• New tools are letting developers create software at radically lower cost and much faster speed than even a few years ago

• The agent economy - where agents become commonplace doing real work - is here, now!. Developers and non-developers can now get working software or features out the door faster than ever; things that used to take months are turning into days or even hours of effort.

• But progress is uneven. If the opportunity is this big, why does it seem like not every company is participating? If the tools are already here, why does it still feel so uneven - why are some teams racing ahead while others barely know where to start?

Taken together, these signals point to a deeper shift in how software gets built and who can build it.

This article is about the agent economy, and, specifically, who wins in this new world, and how?

Agents of Change: Collapsing Software Costs, Exploding Possibilities

Industry leaders like to speculate when we will see the “one-person billion-dollar company.” Whether that exact outcome ever appears is almost beside the point. The phrase is useful because it captures, in one image, just how much leverage agents could create - who gets to build, who gets to scale, and who ultimately wins as work becomes more automated and more software-driven.

We are already seeing the foundations of that world. With commonly available tools, developers can spin up fleets of agents that write code, test systems, move data, and talk to customers. The cost of assembling these digital workers is trending toward zero, and the time from idea to working prototype is shrinking from months to days, sometimes hours. The question leaders keep asking us is simple: does this wave of agents matter now, or is it a distant future problem?

When we look at our experiences, it feels very present. Five years ago, shipping a serious product often meant a 5-10-person team working for about a year. Today, one or two people can get to a pretty credible prototype in a couple of weeks. AI tools and automation are quietly taking over large pieces of what used to be manual work - coding, testing, documentation, even parts of infrastructure - so that machines increasingly work alongside humans rather than waiting passively for instructions.

This is more than a productivity bump. It is a collapse in both the time and the money required to build software, and that collapse forces a deeper question: if this much leverage is suddenly available, what exactly is changing under the surface of our organizations? To answer that, we need to zoom out and look at the broader system that is emerging - a system we call the agent economy.

The Agent Economy

When we talk about the “agent economy,” we mean a world where a lot of the work is done by software agents that can observe, decide, and act - not just passively sit behind a user interface waiting for a click. McKinsey calls this the “agentic organization”; The labels differ, but the implication is the same: the firms that win will be the ones that treat agents not as a feature, but as the operating system of the business.

Key prerequisites are in place: the cost collapse comes from these agents taking over whole chains of tasks end-to-end - integrating systems, following rules, closing loops - not just helping with one isolated step in the process. But it’s not only about cost coming down; at the same time, our speed of iteration and our speed of experimentation are going up sharply. We’re paying less per attempt while also being able to try many more things, much more quickly - and that combination is where the magic really is.

Across the industry, you can feel a shift from “apps you click” to “agents you direct,” where you say, “Handle this onboarding,” or “Prepare this analysis,” and a cluster of agents goes off and actually does the work - again and again, letting you refine and improve in tight loops.

For developers, for teams, and for enterprises, this feels like getting superpowers: we’re no longer limited by our own typing speed or the size of our immediate team; rather, we can orchestrate an ecosystem of specialized agents that keeps cycling through ideas, versions, and improvements.

Our speed of iteration goes way up: instead of shipping one version of a feature every few weeks, we can spin three or four variations in a single day, see what sticks in production or in user tests, and roll the best one forward.

But our speed of experimentation jumps too: we can try entirely new ideas - a different product feature, a new onboarding flow, a new internal report - without committing six months of a team; we can run many small experiments in parallel and only double down on what shows real signal.

And then there’s the delivery cycle, what we think of as the 4Ps: Plan to POC to Pilot to Production. In an agent economy, that whole loop gets compressed, because agents help us plan faster, generate POCs automatically, instrument pilots with rich telemetry, and harden successful patterns into production with far less handcrafting.

Figure 1: Plan to Production – Faster Iterations, More Experimentation, Lower Cost

What was software delivery like 3-5 years ago (“yesterday”)? For most companies, getting from an idea to something running in production was a long relay race: a team of 5-10 people would move carefully from planning, to a proof of concept, to a limited pilot, and only then to full deployment. Each handoff took weeks. Requirements documents were written and rewritten, environments were set up, test data was prepared, and every change triggered another round of meetings. A one-year cycle from plan to production was not unusual; in many firms it was the norm. The system encouraged caution and paperwork, not rapid learning.

The agent economy compresses this entire journey. With software agents doing much of the routine analysis, coding, testing, and documentation, that same path from plan to production can now be handled by a tiny team (1-2 people) in roughly a month. The stages still exist - teams still plan, experiment, pilot, and harden systems - but they move through them at high speed. Iterations are faster because agents can try many variants in parallel. Experimentation is cheaper because prototypes can be generated and revised in hours, not weeks. And by the time a solution reaches production, its cost base is already lower, because so much of the work has been automated.

And the benefits of the agent economy (and its cycle compression) may actually compound. EY, a consulting firm, says that “early investments in data quality, integration capabilities, and AI-native architectures compound over time, creating organizational capabilities that provide sustained competitive advantage.” They go on to state that investments today will reap immense competitive advantages tomorrow: “Organizations that begin building capabilities now will develop advantages that become increasingly difficult for competitors to replicate.”

Implications of the Agent Economy

The implication of the agent economy is quite profound: when the bottleneck shifts from human labor to imagination, the real constraint becomes how quickly organizations can decide what they want to build next.

At the individual level, we picture a single developer “hiring” (building) agents to write tests, refactor code, generate documentation, monitor logs, and even watch production for anomalies - suddenly one person starts to feel like a small virtual team.

At the small-team or startup level, we imagine a five-person company that feels like fifty: agents handling sales outreach, customer support, marketing content, basic finance tasks, and internal reporting, all running in the background while the humans focus on vision, product, and relationships.

At the enterprise level, we’re already seeing early patterns in banks, insurers, and industrial firms - agents helping with customer onboarding, triaging complex service requests, orchestrating internal workflows, and turning messy knowledge bases into something employees can actually use.

Across all three levels, the human role shifts from “doing every step” to “designing, supervising, and coordinating fleets of agents that do the repetitive work at scale.” From a “human-in-the-loop” to a “human-above-the-loop” where small, outcome-aligned agentic teams - two to five humans supervising dozens of agents - own an end-to-end outcome like onboarding or product launch.

And once we see that shift clearly, we probably should ask a deeper question - the one we’ll tackle next: if agents are doing more and more of the work, how do economics, pricing, governance, and trust change in this new landscape of second-order effects?

The Agentic Divide

The societal result of the agent economy compounding is what we call the “agentic divide.” It is a close cousin of the older “digital divide,” but the line is drawn in a different place. The digital divide was about who could get online. The emerging agentic divide is about who can put AI agents to work on their behalf. On one side are people and organizations with fleets of agents handling research, drafting, coding, customer support, and even parts of strategy. On the other are those still relying almost entirely on human effort and manual processes. The first group effectively commands a flexible, always-on workforce that can be pointed at almost any knowledge task; the second moves at traditional human speed, with traditional human limits. As before, the gap is not just about tools, but about the outcomes they make possible.

What makes this new divide more dangerous is the compounding effect. Agents do not simply execute tasks faster and cheaper; they accelerate the rate of experimentation. A team using agents can spin up dozens of product variations, marketing campaigns, or process changes in the time it takes a conventional team to design and review one. They can test, learn, and iterate in rapid cycles, feeding the results back into both their human decision-making and their agents’ prompts and workflows. That feedback loop - experiment, learn, refine, repeat - means that advantages in speed and cost quickly translate into advantages in quality, creativity, and market share.

Over time, the result is an exponential widening of the gap. Organizations that adopt agents early will use them to invent better products, improve customer experiences, and discover entirely new lines of business. The gains from those innovations can be reinvested into even more powerful agentic infrastructures, further extending their lead. Meanwhile, firms that hesitate face a harsher reality: they are competing against opponents with a workforce that is effectively infinite, instantaneous, and continuously improving. The risk is not just falling behind on efficiency; it is being locked out of the fount of innovation itself - left on the wrong side of a divide that is far harder to cross than simply getting online.

As software becomes cheap and abundant in this setting, the scarce resources are no longer licenses; they become ideas, distribution, high-quality data, and institutional trust. Traditional SaaS models - charging per seat, per month - start to feel misaligned when agents, not humans, are doing a large share of the work, pushing us toward outcome-based pricing and usage models tied to tasks, decisions, or business results. Governance and trust move to the center: if agents can send emails, move money, or approve workflows, we have to be explicit about who sets their goals, who audits their behavior, and who is accountable when something goes wrong.

So, the real question is no longer simply whether a firm participates in the agent economy, but whether it can afford not to.

But if value and risk are both shifting toward those who can harness agents at scale, why aren’t more organizations moving faster - and what, in practical terms, is holding them back? This is where the obstacles come into focus.

Obstacles – What is Holding Us Back?

We often come back to William Gibson’s line: “The future is already here-it’s just not evenly distributed.” That is exactly how this moment feels. Some teams are already living in an agent-driven future, with agents embedded in everyday work, while others are still operating as if nothing fundamental has changed. In the context of the agent economy, Gibson’s quote reads less like an observation and more like a warning: agents amplify the gap between early movers and slow movers, because the more you let agents do, the faster you can learn, adapt, and compound advantages.

On one side, we see solo builders and startups using agents everywhere; on the other, we see large organizations stuck in pilots and proofs of concept that never quite make it into production, so they never experience the real benefits of speed and scale. That gap is not about willpower alone. Many organizations are wrestling with very practical constraints:

• Data challenges. Some organizations simply do not have the data they need in digital, usable form, which means there is nothing for agents to act on or learn from. Even when data exists, it is often fragmented, low quality, or poorly documented, so any agent trying to work across systems ends up confused rather than productive. Ownership is murky-no one is clearly responsible for cleaning, structuring, and governing the data-which makes it hard to trust agents with anything mission-critical.

• Skills gaps. Many teams lack people who can bridge AI, software engineering, and the business domain, so they struggle to design agents that solve real problems rather than toy ones. Existing staff are already stretched thin keeping legacy systems alive, leaving little time or energy to learn how to build and supervise agents properly. Hiring for these skills is competitive and slow, so even leaders who see the opportunity feel constrained by the pace at which they can build internal capability.

• Organization and control. Traditional structures are optimized for predictability and approvals, not for rapid iteration with agents that can act semi-autonomously. Risk and compliance functions often default to “no” or “not yet,” even when the actual risks could be managed with narrow, well-designed use cases. Decision-making cycles move in months-steering committees, business cases-while the technology is moving in weeks, creating a persistent mismatch.

• Technical debt. Many enterprises are running on decades-old systems that were never designed to be plugged into agents, so even simple automations turn into integration projects. Layers of workarounds, custom code, and manual processes make it hard to find a clean “entry point” where an agent can take over without breaking something else. Leaders know they need to modernize, but the scale of the clean-up job is intimidating, so they postpone serious agent adoption and fall further behind.

• Culture. Perhaps most importantly, many firms still think in terms of “adding an AI feature to an app” instead of redesigning work so agents sit inside the flow of business and carry tasks from start to finish. There is often a quiet fear-among both managers and staff-that if agents start doing more, roles will be threatened, which produces resistance dressed up as caution. Success stories remain trapped in isolated pockets, so the organization never fully internalizes what it looks like when agents become normal, everyday collaborators.

Taken together, these are not just abstract worries; they are the mechanisms by which the agentic divide widens. A small set of teams is quietly compounding advantages in the agent economy, while others watch from the sidelines. The point, however, is not to treat these obstacles as excuses to delay, but as design constraints to work within. That is why, in the next section, we turn to a more practical question: given these realities, how can organizations introduce agents in a way that is safe, governed, and scalable-moving from isolated experiments to durable, system-level solutions?

Solutions – The Path Forward

At this point, the strategic question is no longer “Should we try agents?” - that feels settled. The real question is, “Where in our workflows do agents belong, and under what guardrails do we let them operate?” The journey is long, but it starts with a first step that is both ambitious and realistic: a near-term vision of where agents can create tangible value in the next 6–18 months, grounded in the fact that the technology is moving quickly but not magically. Leaders need a view of the opportunity that is big enough to matter yet concrete enough to touch today’s processes and constraints.

That vision has to be tested, not merely discussed. A practical starting point is a single, modest, human-heavy process - a claims review, a credit check, a new-hire onboarding flow - where the stakes are medium, not existential. Map the repeatable, high-volume tasks and insert agents there under close human supervision. The goal is explicitly “test and learn”: see where agents actually help, where they get confused, and what kinds of human oversight are needed. Crucially, that learning should cover not only the technology, but also roles, responsibilities, and governance: who is accountable for the agent’s output, how exceptions are handled, how risk and compliance are involved, and what it means for managers and frontline staff when an agent becomes part of the team.

From there, the familiar 4Ps - Plan, POC, Pilot, Production - become the scaffolding for scaling. You plan by defining a narrow, well-bounded use case and clear success metrics. You build a proof of concept that shows the agent can perform the core tasks with real data. You run a pilot with real users and real stakes, instrumented with rich telemetry so you can see where things go wrong. Only then do you harden the pattern into production, with documented runbooks, clear ownership, and explicit guardrails. Each loop through the 4Ps should leave you with better models, better processes, and a clearer sense of where agents belong in the organizational chart, not just in the architecture diagram.

To move beyond isolated experiments, though, you need more than clever prompts and a single chatbot. You need enterprise-grade capabilities: identity and access control for agents, robust audit trails, monitoring and observability, policy enforcement, state and context management, and reliable routing so agents can call tools and talk to each other without creating chaos. Around that, you need ecosystem services that all agents share: a common messaging fabric, a catalog of tools and APIs, governance services that check purpose and policy, and logging and metrics that let humans see what the ecosystem is doing in real time. This shift - from “we have a chatbot” to “we run an agent ecosystem” - is what we mean by an agentic mesh: a mesh of agents, tools, and workspaces that behaves more like a service mesh or data mesh, with standards for identity, communication, observability, and trust built in.

An upcoming O’Reilly book, “Agentic Mesh”, goes deeper into how to build microservice-style, enterprise-grade agents; how to anchor them in shared workspaces so they can coordinate on long-running processes; how to layer governance and trust frameworks on top; and how to get from science experiments to production-ready agent ecosystems that a bank, an insurer, or a manufacturer would actually bet their business on. The organizations that win will be the ones that quietly plant the seeds of an internal agent economy now - combining their data and distribution with the ability to design, deploy, and safely manage large numbers of agents - rather than treating agents as a thin conversational front end. In other words, the first step is modest and local, but if you design it well, it is also the beginning of a much larger transformation, which is where we turn next.

Our (Cloudy) Crystal Ball...

When we mentioned earlier about the “one-person billion-dollar company,” we were not making a literal prediction or selling a fantasy. We meant it as a symbol of leverage - a way to capture how far a single motivated person, or a very small team, might go when they can orchestrate fleets of agents that write code, run experiments, talk to customers, and stitch systems together. Whether that exact scenario arrives or not, the direction of travel is clear: work is being reorganized around agents, and the cost of creating and scaling software is collapsing.

If there is a single thread running through this article, it is that this shift is already visible. Agents are compressing the old 4P cycle - Plan, POC, Pilot, Production - from years to months or even weeks. Early adopters are turning human-heavy processes into test-and-learn loops, where teams can try many more ideas at much lower cost. They are forcing us to confront a new “agentic divide,” in which organizations that re-architect around agents compound advantages in speed, experimentation, and learning, while others stay stuck in pilots, legacy systems, and cautious culture. The future, as William Gibson warned us, is arriving unevenly - and in the agent economy, that unevenness translates directly into uneven outcomes.

Our crystal ball is cloudy, and we will not pretend to know exactly how this plays out. But we do have a few firm convictions. The real divide will not be between those who “use AI” in a vague sense and those who do not, but between organizations that treat agents as the operating system of the business and those that bolt them onto old processes as cosmetic add-ons. The winners will be the firms that start modestly - a medium-risk, human-heavy workflow, a tightly scoped pilot - and then deliberately grow an internal agent economy: building enterprise-grade capabilities, shared ecosystem services, and something like an agentic mesh so agents, tools, and people can cooperate at scale under real governance.

That is why our invitation is simple and practical: start designing for agent-native organizations now. Treat agents not as a feature, but as true collaborators that sit inside the flow of work. Use them to compress your own plan-to-production cycles, to test and learn your way through the obstacles, and to plant the seeds of an internal agent economy before the agentic divide hardens. The agent economy is already forming around us; agents really are becoming the agents of change. The open question is whether you will be an active participant in shaping that economy - or whether you will let others design it for you, and then live with the rules, and the outcomes, they decide.

***

Feel free to reach out and connect with the authors – Eric Broda and John Miller. Questions and comments are welcome and encouraged!

***

All images in this document except where otherwise noted have been created by Eric Broda (the author of this article). All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are ours alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

The Agent is the Harness

An agent harness is the runtime system that turns a model into an operating agent, but the harness required for a coding or personal agent is fundamentally different from the one required for an enterprise agent. Coding harnesses are built for workspace execution; enterprise harnesses are built for governed participation in long-running business processes under identity, policy, and trust.

Introduction

Agent harness design has moved to the center of agent engineering. The shift became harder to ignore after the capability jump in late 2025, when stronger models made clear that production performance was no longer explained by model quality alone. The surrounding runtime now determines whether an agent can sustain continuity, use tools under control, assemble the right context, recover from failure, and produce evidence that its work should be accepted.

The problem is that much of the current harness discussion still comes from coding agents and personal agents. That work has value, but it carries structural assumptions: a visible user, a bounded session, a local workspace, broad tool access, and a task centered on files or research output. Teams building enterprise agents often extend that pattern instead of recognizing that the operating model itself has changed.

The central claim of this article is that an enterprise harness is not a larger coding harness. It is a different architectural form: a governed execution layer for institutional work. That form can be understood through three dependent layers. At the base is security, identity, and trust. Above that sits the execution and control plane. At the top sits the operating model that defines how the agent participates in work. The top layer depends on the middle, and the middle depends on the base.

This article defines the harness, introduces that three-layer model, summarizes the broader contrast between coding and enterprise harnesses, and then focuses on four dimensions where the coding pattern leads to the wrong architecture rather than merely an incomplete one. Those four are identity, authorization, state management, and failure handling.

What an agent harness is

An agent harness is the engineered runtime system that surrounds a model and makes the agent operational over time. It is the machinery that lets the agent receive work, assemble context, access tools, persist state, act within boundaries, recover from failure, and produce evidence that its work was valid. In practical terms, the harness determines what the agent can see, what it can do, what it remembers, and what conditions must be satisfied before its work is accepted.

The harness is more than a prompt, more than a tool list, and more than a wrapper script. In small systems it may include prompts, memory files, a filesystem, a browser, a shell, tests, and a progress log. In larger systems it expands into identity, authorization, orchestration, observability, policy enforcement, workflow state, audit evidence, and service-level reliability. The model still matters, but the harness decides whether that model can be trusted in execution.

A general harness can be described component groups: context and state management; action and environment access; control and recovery; and verification and evidence. Together they determine how the agent receives information, acts on the world, persists continuity, and proves that its work is acceptable.

That definition applies to both coding agents and enterprise agents. What changes is the weight and design of each component. A coding harness treats the workspace as the center of gravity. An enterprise harness treats the need for enterprise-grade capabilities as the primary focus. That change in focus is what changes the architecture.

Three Layers of an Enterprise Harness

The first layer is security, identity, and trust. This is the foundation. An enterprise agent must have a stable identity, explicit credentials, lifecycle state, revocation paths, and bounded authorization. Its trust posture cannot be implied by the fact that it is useful. It has to be grounded in evidence, governance, and control. Without that layer, there is no reliable way to know which agent acted, which permissions it held, or whether it should continue to be allowed to operate.

The second layer is the execution and control plane. This is the runtime machinery that lets the agent do work under control. It includes tool access, state management, memory artifacts, orchestration, failure handling, reliability, and scalability. Every action the agent takes passes through this layer, and every action is constrained by the layer below it. Tool access, for example, is never just a convenience feature in an enterprise harness. It is a controlled action surface whose boundaries depend on identity and authorization.

The third layer is the operating model. This defines how the agent fits into institutional work. It includes the agent’s purpose, its unit of work, its human relationship, runtime environment, context sources, conversation model, discoverability, observability, verification, and explainability. This layer describes what the agent is doing in the enterprise and how the enterprise expects to interact with it. It only works if the layers below it can sustain it.

The dependencies matter. A harness that gets the operating model right but lacks strong identity and authorization is ungovernable. A harness with strong security but weak state management cannot sustain long-running work. A harness with good tooling but no structured failure handling cannot safely participate in real processes. An enterprise harness is therefore a systems design problem. The layers have to be designed together.

Coding and personal harnesses also have versions of these layers, but they are lighter, often implicit, and organized around a different center of gravity. They stabilize a workstation-shaped environment. Enterprise harnesses stabilize an institutional environment. That is the shift the rest of the article examines.

Summary Comparison

Most of these are differences of degree. A coding harness handles state; an enterprise harness handles more state for longer periods under stricter durability requirements. A coding harness supports verification; an enterprise harness verifies against broader standards. Those are meaningful shifts, but they can be extended incrementally. The deeper issue appears where the workstation assumption itself stops holding. The test is whether extending the coding pattern produces an architecture that is merely incomplete or one that is structurally wrong for the operating context. The next four sections focus on those cases.

Identity: session-scoped runtime versus persistent principal

The decisive question is simple: is the agent a runtime convenience or a recognized enterprise principal? Coding harnesses usually choose the first answer. The user knows which tool is running, the repo knows which session made a change, and that is often enough. The harness may distinguish between worktrees, sessions, or runtime instances, but it does not need to treat the agent as a durable institutional principal because the human sponsor remains close to the task.

Enterprise settings break that assumption. An agent that handles first-notice-of-loss intake for auto claims may read claim records from a claims administration platform, pull police reports from a document repository, consult a coverage policy service, and update a customer workflow queue. If identity remains session-scoped in that environment, the organization loses the ability to answer basic governance questions. Which agent acted? Which approved version was deployed? What credential scope did it hold? Under whose authority did it recommend denial, escalation, or payment review?

Extending the coding pattern produces a system that can act but cannot be governed. Actions may be logged, but the logs do not point to a stable enterprise principal. Permissions may exist, but they are attached to transient runtime contexts rather than to a durable identity. Discoverability weakens because the organization cannot publish a meaningful description of an agent that has no stable institutional form. Accountability weakens for the same reason: remediation has no anchor.

An enterprise harness has to assign stable identity at the foundation. The agent needs ownership, lifecycle state, credentials, policy bindings, and revocation paths. That identity has to persist across sessions and deployments so the enterprise can tie actions to an approved principal rather than to an ephemeral execution. Identity is what lets every higher-level control work. Authorization depends on it. Observability depends on it. Trust depends on it.

In the claims example, a disputed payout six months later should not send investigators searching through runtime logs that refer only to containers or sessions. They should be able to identify the specific claims-triage agent, its version, its approval status at the time, the credential scope it held, and the policy set attached to it. Under a persistent identity model, that is possible. Under a session-scoped model, the organization can shut down a runtime, but it cannot manage a principal. That is the difference between an agent that happens to exist in production and one that can be governed as an enterprise actor.

Policy and authorization: broad access versus zero-trust control

Broad local access is useful in a workstation. That is why coding harnesses commonly expose bash, filesystem access, browser control, code execution, and nearby tools. The design pressure favors speed and convenience. The harness is trying to make the workspace legible and actionable with minimal friction.

That model becomes structurally wrong when the agent is no longer acting inside a bounded local workspace. Enterprise agents touch production systems, customer records, financial ledgers, regulated documents, and approval steps. In that setting, broad ambient access creates an agent with too much latent authority, often inherited from a surrounding runtime or shared service account, without evaluating whether the current action is appropriate in the current context.

A coding-style extension usually puts authorization at the perimeter rather than at the action boundary. The agent can call a system because the harness made that capability available once, not because this particular action is permitted now. That is a serious mismatch for enterprise work, where legitimacy changes by case, role, business purpose, policy condition, and workflow state. An action that is valid during intake may be invalid after an exception has been raised or after a required approval has not yet been granted. A system-level grant cannot express that.

An enterprise harness has to enforce least privilege and per-action policy evaluation. Every request to use a tool, call an API, read a dataset, write a record, or delegate to another agent has to be checked against identity, role, task, business purpose, system boundary, and policy state. The harness has to know not only whether the agent can ever use a tool, but whether it can use it here, now, for this case, and for this reason. This is where zero trust becomes a runtime property rather than a slogan.

Consider a remediation agent working a consumer-bank dispute case. It needs access to card transaction history in the ledger system, customer profile data in the CRM, and complaint notes in the case platform. In a coding-style harness, the API credentials for all three systems may simply be present whenever the agent runs. The agent can continue using them even after the case reaches a state where Regulation E review requires human approval before customer-facing action. In a zero-trust harness, access is scoped to the current case, step, role, and policy condition. If the workflow crosses an approval boundary, the harness denies the action or routes it to approval before execution. That moves policy from observation to control.

State management: local artifacts versus durable process state

A multi-step approval workflow exposes the difference quickly. Suppose an enterprise agent assembles vendor onboarding documents, routes them for sanctions review, waits for legal approval, and then resumes to complete supplier setup. If its continuity depends on a local progress file or embedded note, the process looks resumable from inside the runtime and fragile from everywhere else. A human reviewer may not see the current hold reason. A second agent may not know what remains pending. The workflow engine may not know that the agent is waiting on counsel review at all. That fragility becomes visible when you compare it to the persistence model it was extended from.

That kind of local persistence works well for coding harnesses. Files, git history, checkpoints, progress notes, and workspace documents let the next session resume from where the prior one stopped. For coding and personal tasks, the state is close to the work, the project is bounded, and the artifacts live in the same environment the agent already uses. The harness solves a real continuity problem because the model has no durable memory of its own.

Enterprise state is different in kind. It is not only a convenience for continuation. It is part of the process itself. The harness has to preserve case status, prior decisions, pending approvals, deadlines, exceptions, conversation continuity, and the history of actions taken over time. That state may need to remain visible across multiple services, other agents, and human operators. It may have compliance implications. It may determine whether a later action is legal, valid, or timely.

If the coding pattern is extended here, the result is fragile and often invisible state. The agent stores progress in local notes, embedded memory files, or runtime artifacts that work for one task instance but do not constitute a durable operational record. Another agent instance may not see them. A human reviewer may not be able to inspect them. A workflow engine may not know they exist. The organization ends up with state that helps the agent continue but does not help the institution govern the process.

An enterprise harness has to treat state as durable process state tied to the business object. In the vendor-onboarding example, the authoritative record should show the supplier ID, the current workflow step, the sanctions-review outcome, the pending legal approval, the next due date, and the explanation for the hold. The agent can still use private working memory for local reasoning, but the authoritative process state has to live in governed stores with visibility, lifecycle management, and shared access patterns appropriate to the process. That is what makes the work resumable, reviewable, and governable.

Failure handling: local correction versus governed recovery

Failure handling is where the workstation pattern becomes actively dangerous. In a coding harness, a failed tool call usually means retry, revise, rerun tests, or restore from a checkpoint. That pattern works because most failures are local to the workspace and can be corrected by more execution against the same artifact.

Enterprise failures are different. They may involve inconsistent state across services, missing approvals, duplicate events, broken handoffs, regulatory deadlines, or partial side effects that cannot be safely retried without coordination. A local retry may make the situation worse rather than better because the failure is no longer confined to the runtime. It is part of the business process.

A common example is a two-system financial update. An agent posts a refund adjustment to the payment ledger, then fails while updating the customer account platform that drives statements and balances. If the harness simply retries the whole transaction because that is how it handles error recovery, the ledger may receive a duplicate adjustment while the customer account remains out of sync. The result is not just a failed task. It is a reconciliation problem with financial and control implications.

An enterprise harness therefore needs governed recovery. It has to support idempotent retry, task suspension, human escalation, approval requests, workflow rerouting, and compensating actions. In the refund example, the harness should record the partial outcome, block unsafe retries, detect whether the ledger write was already committed, and route the case into recovery. That may mean opening an operations task, invoking a compensating transaction, or requiring finance-operations approval before proceeding. The difference is fundamental. A coding harness treats failure as something to correct locally. An enterprise harness treats failure as a stateful process event that has to preserve auditability and process integrity.

The Harness Layers are not independent

These harness layers work only as an integrated system. Identity enables authorization because the policy engine needs a known principal. Authorization constrains tool access because the control plane cannot safely expose capabilities without scoped permissions. State management and orchestration depend on those controls because long-running workflows need durable, governed state rather than ad hoc local memory. Observability depends on identity and state because the enterprise has to know who acted and what happened. Explainability depends on observability and policy because it has to reconstruct not only the action but the reason and governing rule behind it.

The architectural implication is direct. Adding identity to a coding harness does not produce an enterprise harness if the authorization model, state model, and failure model remain workstation-shaped. Adding a workflow engine does not solve the problem if the agent still operates with broad ambient authority and local-only memory. Adding audit logs does not create trust if the system cannot tie them to a stable principal or reconstruct a governed recovery path. Enterprise harness design is not a checklist of features. It is a dependency structure.

This also explains why many enterprise agent efforts feel haphazard. Teams add prompts, tools, memory files, retries, and workflow logic in response to immediate failures, but the pieces are built on inconsistent assumptions. Some parts assume a coding assistant. Others assume a business worker. The resulting system may function in demonstrations and fail in production because the architectural layers do not support one another.

Conclusion

The visible literature on harnesses has clarified important mechanics: externalized state, context control, tool mediation, orchestration, verification, and recovery. But much of that literature still reflects the assumptions of coding and personal agents. It is grounded in sessions, workspaces, files, and user-adjacent execution. That is why it transfers only partially to enterprise settings.

Enterprise agents operate inside business processes, across systems, under policy, with persistent identity and institutional consequences. Their harness cannot be a larger workstation scaffold. It has to be a process control plane. The three layers capture that architecture: security, identity, and trust at the base; execution and control in the middle; operating model at the top. The four dimensions examined here show where the coding pattern breaks structurally rather than incrementally.

As agents move into production operations, harness architecture becomes the primary engineering challenge. It becomes more consequential than prompt design, and in many cases more consequential than model selection. The model supplies inference. The enterprise harness decides whether that inference can be turned into governed work.

***

Feel free to reach out and connect with the author, Eric Broda, on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the author(s) alone and do not necessarily reflect the views of my (our) clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

Observer Agents – Sensors for the Agent Ecosystem

Observer agents are the eyes and ears of the agent ecosystem, continuously sensing and interpreting raw signals, and providing the awareness that allows the Agentic Mesh ecosystem to adapt, respond, and act in real time.

In a factory, sensors listen to the machinery, actuators act on the assembly line, and controllers bind them together into a working system. The same is true in the Agentic Mesh: observer agents are the sensors that continuously scan for change in contrast to traditional task-oriented agents that execute tasks. A thriving agent ecosystem needs both. Without sensors, the system lacks awareness; without actuators, it cannot move; and without coordination, it cannot function as a whole.

Observer agents stand apart from today’s most common agents. While prompt-driven agents react to human requests and actuator-style agents execute tasks, observers are focused on awareness. They are always listening-monitoring data streams, telemetry, and events-and they filter, aggregate, and classify signals to separate noise from insight. In this sense, they are not just passive watchers; they are the Mesh’s first line of intelligence, creating the context that other agents need to act responsibly and effectively.

Beneath the surface, observer agents are designed as layered architectures. At the lowest level, they capture raw events, such as price fluctuations or system anomalies. These raw signals can be passed along or aggregated by higher-level observers, which filter further, correlate events, and even generate new, more meaningful signals. The result is a cascading hierarchy where each level transforms low-level noise into increasingly higher-level insight, enabling the Mesh to progress from detection to understanding. Observer architectures, in this way, act as pipelines that refine raw inputs into actionable intelligence.

Finally, observer agents do not operate in isolation-they are the connective tissue of the agent ecosystem. The insights they generate provide the inputs that goal-oriented agents use for decision-making and can serve as the triggers that activate task-oriented agents. An observer might detect a compliance anomaly, issue an event that represents the insight, and initiate a task agent to file a report or escalate the issue. In the broader Agentic Mesh, observers act as the nervous system, delivering the awareness and intelligence that allow agents and fleets to operate as safe, reliable, and enterprise-grade ecosystems.

This article will explore:

• What observer agents are and how they differ from today’s prompt-driven and actuator agents.

• Observer agent architecture, including layered hierarchies that filter, aggregate, and generate insights.

• Integration into the Agentic Mesh, where observer agents provide the awareness and triggers that bind the ecosystem together.

Observer Agents – What are they and How are they Different?

In a factory, the simplest building blocks of automation are sensors and actuators. Sensors watch: they detect temperature, vibration, or pressure. Actuators act: they move parts on the assembly line, switch valves, or control motors. Controllers sit in between, binding them into a working system. The same logic applies in the world of agents. Task-oriented agents are like actuators—they act on instructions and execute tasks. Observer agents, by contrast, are like sensors—always listening, always scanning for changes, and feeding that awareness back into the broader system.

In agentic mesh, three types of agents work together to transform raw events into meaningful actions: observer agents, goal-oriented agents, and task-oriented agents. Figure 1 shows how these categories—sensors, orchestrators, and actuators—form a pipeline that allows large, distributed systems to observe their environments, make sense of what is happening, and act with precision. Observer agents, at the foundation, serve as the ecosystem’s “eyes and ears.” They capture events such as alerts, faults, or news, aggregate them, and then analyze their meaning. Their role is to ensure that higher-level signals are forwarded into the system, allowing other agents to work with distilled insights rather than unfiltered noise.

Figure 1, Observing, Goal-Seeking, and Executing

The second agent group, goal-oriented agents, act as orchestrators that interpret information in the broader context of the ecosystem. They use shared workspaces—sometimes called “super-contexts”—to bring together observations, decide what matters, and plan responses. These agents do not execute tasks directly but instead organize workflows, delegate responsibilities, and set priorities. They bridge the gap between raw data and actionable work, ensuring that the system’s responses remain coherent, timely, and aligned with higher-level objectives.

Finally, task-oriented agents take on the role of actuators, carrying out specific tasks based on the plans set by goal-oriented agents. They decompose complex problems into executable steps, identify the appropriate tools or collaborators needed, and drive concrete outcomes. Whether it is calling APIs, interacting with systems, or performing detailed actions, task-oriented agents form the “hands” of the ecosystem. Together, these three agent types form a loop of observing, orchestrating, and executing—an essential structure for building scalable, enterprise-grade agentic systems.

Unfortunately, today’s agent ecosystems are missing this critical sensing capability. Most agents are built to respond to human prompts, queries, or commands. They wait passively until someone asks for something, or until they are scheduled to perform a task. What is absent is an agent that can “listen” continuously to its environment—whether that environment is market data, log streams, IoT sensors, or social signals—and broadcast relevant events in real time. Observer agents fill this gap. They are not driven by requests from people, but by the flow of signals in the world around them.

This makes observer agents fundamentally different from the task-oriented models we see today. Task agents wake up, do work, and return a result; they live in cycles of action. Observer agents live in cycles of awareness. They don’t wait to be told what to do; they notice, analyze, and broadcast what’s happening. In doing so, they give the ecosystem eyes and ears—something most current agent frameworks lack. Without observers, agents are clever but blind, acting without the context of a dynamic, real-time environment.

Observer Agents – How do they Work?

The Observer Agent Architecture, in Figure 2, shows how raw events are captured, processed, and transformed into actionable insights within an agentic ecosystem. At its core, the architecture separates the responsibilities of event detection and event handling: the observer tool continuously monitors for signals—using periodic checks or event listeners—while the observer agent subscribes to these published events and applies algorithms to filter, aggregate, and analyze them. This design ensures that complex systems can sense their environment in real time, reduce noise, and forward meaningful information to other agents for coordinated action.

Figure 2, Observer Agent Architecture

Observer agents play the foundational role of detecting signals and translating them into actionable insights. The diagram above breaks down this process into two key components: the observer tool and the observer agent. The observer tool runs an event loop that makes periodic calls (via callback) to a tick() function. The tick() function itself has two personalities: it can operate in a one-shot mode, checking whether an interesting event has occurred and then emitting it, or it can take on a listening role, waiting—sometimes indefinitely—for an event to arrive, and then calling emit() to transform that signal into a structured event ready for analysis.

Once an event is generated by the observer tool, it is handed off to the observer agent through a publish-subscribe model. The agent subscribes to the event queue and processes incoming information through its internal algorithm. This step is critical, as it is where raw signals are turned into something more meaningful: aggregated patterns, filtered signals, or analyzed insights.

In this way, observer agents act as broadcasters within the larger agentic mesh. After applying their algorithm, they can publish higher-level insights to other agents, who may then use these outputs to orchestrate workflows or execute specific tasks. This makes the observer agent architecture a keystone for real-time responsiveness in complex systems: it allows organizations to move from passive data collection to active, intelligent monitoring that fuels decision-making across the entire ecosystem.

At the technical level, observer agents rely on observer tools—data feeds, sensors, APIs, or event listeners—that capture raw signals from the environment. But raw events are noisy, and not every anomaly matters. The role of the observer agent is to aggregate, filter, and interpret these streams. It may combine multiple weak signals into one meaningful event, or it may discard irrelevant noise while highlighting critical patterns. This filtering role makes them more than just passive consumers of data; they are intelligent intermediaries, producing actionable signals for other agents and people.

This is where they diverge sharply from traditional event-driven architectures. Event-driven systems have long existed in enterprise IT, allowing services to react to triggers such as “new order placed” or “error logged.” Observer agents build on that foundation but add an LLM or reasoning engine as a brain. Instead of simply routing or transforming events, they can correlate across streams, detect subtle patterns, and even generate new insights. An observer agent doesn’t just say “error occurred”—it can say “this error matches a failure pattern seen last month and may indicate an emerging systemic risk.”

Because of this intelligence, observers can be built into hierarchies that mirror real-world sensing systems. At the bottom are low-level observers, capturing raw data like ticks in financial markets, packet flows in a network, or readings from IoT sensors. These agents forward their processed outputs to mid-tier observers, which aggregate across multiple feeds. At the top, high-level observers synthesize signals from many sources, producing strategic insights or triggering orchestrated responses. This cascading design provides a consistent way to manage complexity: each layer filters, aggregates, and interprets, so the ecosystem never drowns in raw data.

Hierarchies of observer agents also make the Mesh resilient. If one observer fails, others continue to operate, and higher-level observers can cross-validate inputs. This layered approach ensures that no single agent becomes a bottleneck or point of failure. It also mirrors how people and organizations process information: individual employees notice details, managers synthesize across teams, and executives focus on high-level trends. By building observer hierarchies, the Agentic Mesh scales human-like awareness into a machine ecosystem.

The value of this architecture becomes clear when comparing it to task-oriented agents. Task agents execute: they file reports, schedule meetings, or run workflows. But without context, they risk acting blindly or inefficiently. Observer agents supply that context. By identifying critical changes in the environment and passing them forward, observers give task agents the insight they need to act intelligently. They are the spark that initiates action and the lens that sharpens decisions.

In practice, observers can serve as both initiators and enablers. A compliance observer might detect unusual trading behavior, generate an event, and trigger a task agent to launch an investigation. A supply-chain observer might aggregate multiple small signals—supplier delays, shipping bottlenecks, demand spikes—and produce a higher-level event that prompts reallocation of inventory. In each case, observers transform raw inputs into meaningful outputs that make the entire ecosystem smarter and more responsive.

Ultimately, observer agents expand the definition of what an agent ecosystem can be. Prompt-driven agents respond to people. Task-oriented agents execute work. Observer agents watch, interpret, and signal change. Together, they create a full loop of awareness and action. Just as factories rely on sensors and actuators working together, the Agentic Mesh relies on observers and task agents to bind awareness and action into one system. This article begins with that distinction—what observer agents are and why they matter—before diving deeper into their architectures and their role in the broader Agentic Mesh.

At their core, observer agents are microservices with a brain. Like any modern microservice, they are lightweight, containerized, and deployable in scalable environments. What makes them unique is the addition of an LLM or reasoning module that allows them to process incoming signals intelligently. This brain distinguishes observer agents from traditional services that merely route or log events—observers can aggregate, filter, interpret, and generate insights in real time, creating higher-order meaning from raw data.

Every observer agent operates around an internal event loop. This loop governs the tools the observer controls, orchestrating how they access the environment. Tools may monitor databases, watch APIs, listen to message streams, or even read sensor feeds. The observer decides when and how these tools should be invoked, ensuring that the agent is continuously attentive without overwhelming the system. This event loop architecture makes observers reliable, responsive, and efficient in managing environmental inputs.

Observer tools can operate in different modes depending on the need. Some are periodic: they execute at regular intervals, scanning for anomalies or new signals in the environment. Others are long-lived listeners: they sit idle but awake, waiting indefinitely for something to occur—a stock price crossing a threshold, a sensor reporting a critical temperature, or a log entry signaling an error. The observer’s event loop integrates these modes seamlessly, allowing multiple tools to operate concurrently without conflict.

The power of the event loop lies in its safety and predictability. Left unmanaged, long-lived listeners can create resource leaks, or periodic tools can overwhelm systems with excessive polling. The observer event loop abstracts this complexity away from developers, offering a managed execution environment that schedules checks, handles failures, and gracefully recovers from errors. In practice, this means observers can safely scale to thousands of tools and streams without collapsing under their own weight.

Once an observer agent detects an event, its job is not complete until it shares it. Observers use a standard “emit” function that publishes events into the ecosystem’s event management layer, often implemented with systems like NATS, Kafka, or Pulsar. Emitted events become first-class citizens in the Mesh: they are timestamped, traceable, and made available for any interested subscriber. This broadcast model ensures that observer outputs are not hidden in silos but are accessible across fleets and ecosystems.

The subscription model makes observer agents especially powerful. Any number of downstream consumers—task agents, goal-oriented agents, or even people monitoring dashboards—can subscribe to the observer’s events. This decoupling allows observers to remain simple and focused on their sensing role, while the broader Mesh decides what to do with their signals. In this way, observer agents form the “nervous system” of the Mesh, continuously generating signals that other agents interpret and act upon.

Because observers are built on a microservices foundation, they inherit all the enterprise-grade practices already well established in the cloud-native world. They can be secured with mutual TLS (mTLS) for encrypted communications, authenticated with OIDC to acquire identities, and authorized with OAuth2 roles for fine-grained access control. These integrations mean that observer agents are not novel from an infrastructure standpoint—they fit into well-understood operational frameworks, reducing barriers to enterprise adoption.

Observers also come with built-in observability. Like any microservice, they can emit logs, traces, and metrics into monitoring platforms. But because they are event-centric, they can also send alerts directly to operations consoles when anomalies are detected. For example, an observer that notices repeated authentication failures might emit both an event to the Mesh and an alert to the security operations team. This dual pathway makes them both part of the agentic workflow and part of enterprise IT operations.

When deployed inside the Agentic Mesh, observers gain an additional layer of trust. Mesh components enforce explainability and traceability, ensuring that every emitted event is accompanied by metadata about its source, reasoning, and context. Zero-trust principles apply at every step: no observer is trusted implicitly, and every interaction must be authenticated, authorized, and logged. This combination of zero-trust posture and traceability ensures that observers can be trusted in sensitive environments, from financial services to healthcare.

Ultimately, the observer agent architecture is about combining familiar enterprise practices with new intelligence. They are microservices, so they inherit scalability, security, and reliability. They have a brain, so they can transform noise into insight. They operate in event loops, so they can manage multiple tools seamlessly. And they broadcast through the Mesh, so they connect sensing to acting. In short, observer agents bring awareness into the Agentic Mesh, ensuring that enterprises are not just building systems that act, but systems that listen, interpret, and evolve in real time.

Let’s walk through a simple example of how observer agents work, using a stock market scenario. Imagine you have an observer agent that “listens” to a live stock ticker feed. Its job is simple: watch the stream of prices, and if anything significant happens—say a stock price jumps more than 5% in a minute—it takes note. This is like a sensor on a factory floor detecting a sudden vibration in a machine: the observer isn’t doing the work of fixing or trading, it’s just watching for changes.

Inside, the observer has a small loop that constantly checks its inputs. In our example, it might connect to both the ticker feed and a financial news feed. Some of these tools check periodically (for example, scanning the news every 30 seconds), while others wait for events to arrive (like live price updates). The observer agent’s loop keeps all this organized—making sure tools don’t collide, that nothing gets missed, and that if a tool crashes, it gets restarted.

When something happens—say the price of Stock A suddenly spikes—the observer agent recognizes this as a meaningful event. It then “emits” the event into the ecosystem. Think of this like the observer writing a short note: “Stock A up 5% in 60 seconds” and dropping it into a central message system such as Kafka or NATS. That message is timestamped and made available to anyone who cares about market signals. The observer doesn’t decide what happens next; it just provides the event.

Subscribers then pick it up. Maybe a trading bot subscribes and decides to buy. Maybe a risk-management agent subscribes and checks if the spike looks suspicious. Maybe a compliance agent logs the event for audit. The beauty is that the observer doesn’t need to know who is listening. It just listens, detects, and signals. In a way, it’s like the factory analogy again: sensors detect vibration, controllers interpret, and actuators act. Observer agents provide the eyes and ears that let the rest of the agent ecosystem respond intelligently.

Observer Agents – Integration with Agentic Mesh

Observer agents, goal-oriented agents, and task-oriented agents integrate to form a scalable, coordinated system, as shown in Figure 3. Each type of agent plays a distinct but complementary role, ensuring that raw signals can be turned into meaningful insights and ultimately into concrete actions. This flow—sensing, orchestrating, and executing—allows organizations to manage complexity while maintaining agility in their operations.

Figure 3, Observer Agent Integration

The process begins with observer agents, which function as sensors. These agents monitor a wide range of events at scale, such as shifts in consumer sentiment or changes in pricing. Rather than acting directly on these events, observer agents publish the information to the broader system. This ensures that the raw observations are captured and made available for higher-level processing, preventing valuable signals from being lost or siloed.

Next, goal-oriented agents step in as orchestrators. They receive event data from observer agents and interpret it within a broader context. For example, a marketing-related event might trigger a goal-oriented agent to create a strategic plan. These agents break down broad objectives into structured goals, coordinate tasks across the system, and determine which task-oriented agents or tools are best suited to carry out the work. Their role is to translate signals into actionable workflows that align with organizational objectives.

Task-oriented agents then take over to execute the detailed steps required to achieve the defined goals. These agents act as actuators, breaking down plans into fine-grained tasks and calling upon the necessary tools or APIs. For example, a goal-oriented agent may ask a task-oriented agent to calculate a market size or produce a specific deliverable, which is then executed step by step until completion. This structure ensures that even complex projects can be managed reliably by decomposing them into smaller, manageable components.

The integration of these three layers—observers sensing, goal-oriented agents orchestrating, and task-oriented agents executing—creates a scalable model for intelligent systems. It allows for real-time responsiveness to external signals, ensures that work is intelligently distributed across agents, and provides a clear path from raw data to completed outcomes. In this way, the system mirrors how human organizations operate at scale, with specialized roles working together in a coordinated loop of observation, decision-making, and execution.

Observer Agents – First Class Members of the Agent Ecosystem

One of the most powerful integration patterns is building hierarchies of observers. At the lowest level, simple observer agents capture raw events—stock ticks, server logs, IoT sensor readings—and forward them onward. Higher-level observers aggregate these streams, filtering noise and combining weak signals into meaningful insights. This tiered abstraction ensures that the Mesh can handle massive amounts of raw data without overwhelming downstream agents, surfacing only the most important events. The result is a pipeline of awareness that scales from fine-grained details to strategic insights.

Observers also play a critical role in activating task-oriented agents. Task agents are the actuators of the Mesh: they carry out specific work when conditions are met. An observer might detect a system anomaly and trigger a remediation agent to restart a service. Or it might spot unusual market activity and activate a trading agent to execute a position. In this way, observers act as initiators of action, turning passive task agents into responsive, real-time participants in the ecosystem.

At the same time, observer agents feed insights into goal-oriented agents. These are higher-order agents tasked with achieving long-term objectives—optimizing a portfolio, maintaining compliance, or orchestrating a supply chain. By providing them with real-time signals, observers enhance their decision-making capabilities. A goal-oriented agent is only as good as the information it receives, and observers ensure that its inputs are both current and meaningful. They become the bridge between low-level signals and high-level strategy.

Observer agents can be arranged into collaborative ecosystems to manage vast streams of events in a scalable way. Observer agents capture signals from multiple sources—ranging from raw data feeds to real-world alerts—and pass them along to other observers. By organizing observers into layered structures, the system can progressively aggregate, filter, and analyze information before it reaches higher levels of the ecosystem. This tiered approach ensures that the flood of incoming signals is refined into meaningful, manageable insights.

Figure 4, Observer Agent Ecosystems

Discovery and reuse of observers is also built into the Agentic Mesh. Like all agents, observers can be published into a registry or marketplace, where other teams or systems can find them. This makes it easy for organizations to share observer agents across domains. A financial market observer might be reused by multiple desks; a compliance log observer might serve multiple departments. Registries give observers the same discoverability and lifecycle management as other agents in the Mesh.

Managing fleets of observers is another integration point. In practice, enterprises will run not just one or two observers, but thousands. Like any other agent type, observer fleets can be deployed and orchestrated with Kubernetes-style fleet management capabilities. This allows organizations to scale observers up or down, roll out new versions, and ensure consistent monitoring across environments. Observers are microservices with brains, and the Mesh treats them with the same operational rigor as any production-grade service.

Observers are also integrated with the Mesh’s control plane. Through control plane services, they can be started, stopped, configured, or throttled dynamically. Administrators can adjust thresholds, switch data sources, or reassign observers to new roles without manual intervention. This centralized control makes observers not only powerful but governable, aligning them with enterprise requirements for security, compliance, and operations.

Together, these integrations transform observer agents from isolated tools into ecosystem enablers. They provide the eyes and ears of the Mesh, trigger actuators into action, inform strategic goal-oriented agents, and operate under enterprise-grade controls. By plugging seamlessly into registries, fleet management systems, and control planes, observers embody the Agentic Mesh philosophy: agents that are not only intelligent but integrated, secure, and scalable. In this way, observers anchor the Mesh’s awareness, ensuring that the ecosystem is not only capable of action, but of perception and insight.

Observer Agent – Ecosystem Topologies

On the internet, sensor topologies appear in systems like CDNs, where distributed nodes detect traffic anomalies and forward them to regional aggregators in a hierarchical structure, and in IoT smart homes, where devices connect to a central hub in a star topology that filters and relays data. Similarly, distributed monitoring systems such as Prometheus or Datadog use federated topologies, with local collectors passing metrics to higher-level aggregators that provide a global, correlated view of system health.

Similarly, in factories, assembly line monitoring often uses a linear topology where sensors track each stage of production in sequence, while SCADA systems employ hierarchical tree structures with field sensors feeding data to PLCs and supervisory systems. For predictive maintenance, sensors on equipment are arranged in mesh topologies, enabling resilient, redundant communication that ensures continuous monitoring even if individual sensors fail.

Figure 5, Observer Agent Topologies

There are three common ways that observer agents can be organized into topologies: star, hierarchical (SCADA-like), and mesh. Each topology provides a different balance of scalability, resilience, and efficiency, reflecting trade-offs between centralized control, structured layering, and distributed collaboration. By mapping these structures onto observer agents, we can see how complex systems can sense, filter, and respond to events at scale.

The Star Topology arranges observer agents around a central node, which acts as a hub for event collection and aggregation. Each peripheral observer listens to its local environment—capturing events such as market signals, security alerts, or operational anomalies—and sends them directly to the hub. The hub filters noise, correlates signals, and forwards only meaningful insights. This design is simple, easy to manage, and ensures that decisions are consistent because they pass through a single point. However, it creates dependency on the hub, which may limit resilience at very large scales.

The SCADA/Hierarchical Topology introduces multiple layers of observer agents, each with its own scope and level of abstraction. At the lowest level, local observers capture raw signals. These are then passed upward to mid-tier observers, which aggregate and contextualize them, and finally to top-tier observers, which detect patterns across large domains. This resembles industrial control systems, where PLCs roll up data to supervisory systems. The strength of this model is scalability and clarity: raw data is progressively refined, ensuring that higher-level agents focus only on the most relevant insights.

In contrast, the Mesh Topology distributes responsibility evenly across all observer agents. Here, each observer not only listens for events but also shares them with neighboring observers, creating redundancy and resilience. If one agent fails, others can still propagate the event across the network. This topology excels in dynamic environments where robustness is critical, such as predictive monitoring or cybersecurity. The tradeoff is greater complexity, since coordination and deduplication are required to avoid overwhelming the system with redundant signals.

Applying these structures to observer agents in the Agentic Mesh, we see that each topology fits different use cases. A star arrangement might work best for a localized domain, such as monitoring a single business process. A hierarchical arrangement could serve large-scale enterprises, where signals must flow from front-line operations up to corporate decision-makers. A mesh design, on the other hand, could be deployed across distributed infrastructures like cloud services or global supply chains, where resilience and adaptability are paramount.

These topologies also highlight how observer agents integrate with goal-oriented and task-oriented agents. In star and hierarchical models, goal-oriented agents may sit above the observer hub or supervisory layer, orchestrating work based on aggregated insights. In a mesh, however, goal-oriented agents might exist throughout the network, receiving inputs from multiple points and dynamically coordinating responses. Task-oriented agents, in turn, benefit from whichever topology ensures that they receive clean, timely, and relevant signals.

Ultimately, observer agent topologies are not one-size-fits-all but instead form a toolkit. By selecting and combining star, hierarchical, and mesh arrangements, organizations can build sensing networks that match their operational priorities—whether that is simplicity, scalability, or resilience. Just as factories, IoT systems, and the internet use different sensor topologies to meet their needs, observer agents in the Agentic Mesh can be deployed in the structure best suited to the environment they monitor and the goals they serve.

Summary

This article has explored the essential role of observer agents within the Agentic Mesh, positioning them as the sensors of the ecosystem—always on, always listening, and always filtering noise into actionable insights. We examined how observer agents differ from prompt-driven and task-oriented agents, their layered architectures that transform raw signals into meaningful intelligence, and their integration with goal-oriented and task-oriented agents to create a full cycle of awareness, orchestration, and execution. By looking at architectures, integration patterns, and real-world sensor topologies, we saw how observer agents provide the nervous system for enterprise-grade agent ecosystems.

In my own mind, the opportunity is clear: anyone can begin to design and deploy their own observer agents, hierarchies, and topologies to bring real-time awareness into their systems. With the Agentic Mesh as the foundation, you can build ecosystems that listen as intelligently as they act—star topologies for simplicity, hierarchical designs for scale, and mesh arrangements for resilience. By combining these patterns, organizations can create sensing agent ecosystems that not only monitor but also interpret and respond dynamically to the world around them, unlocking the promise of agents that are not just clever but truly aware.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

The Agentic Knowledge Fabric – An Approach for Token-Aware Knowledge Serving

The Agentic Knowledge Fabric is an architecture for token-aware knowledge serving. It assembles the minimum viable context for an agent’s current task from enterprise systems, documents, and policies.

Introduction

The Agentic Knowledge Fabric, or AKF, is the context engineering layer for Agentic Process Automation. Its job is to turn fragmented enterprise knowledge into runtime context for a specific step of work. In most organizations, that meaning is spread across systems of record, SOPs, policy documents, tickets, emails, source code, transcripts, and operator judgment. AKF converts that material into context that is scoped, traceable, and token-aware.

This article follows two views. The first explains how business meaning is represented through semantics, storage, retrieval, and the runtime artifacts built on top of them. The second explains how that meaning is operationalized through ingestion, compilation, and serving.

Semantics for Agent Context Generation

Before a system can retrieve and package the right material, it has to reduce ambiguity. Enterprises reuse the same words across functions, systems, and controls, often with different meanings. AKF addresses that by making business language explicit, governed, and machine-usable.

Figure 1, Semantics for Agent Context Generation

Vocabulary

The vocabulary layer serves as the enterprise’s operational dictionary. It captures the terms that appear in forms, tickets, logs, data fields, SOPs, and internal communications, then binds those terms to stable identifiers. Where a surface term carries multiple meanings, AKF separates them through scoped senses. A term such as customer may resolve one way in marketing, another in sales, and another in anti-money-laundering operations. That scoped sense becomes an early routing and retrieval constraint.

Taxonomy

Taxonomy organizes terms into practical retrieval facets such as jurisdiction, product family, process stage, risk tier, case type, and control category. These act as execution filters. Before the system begins assembling context, taxonomy narrows the candidate set of facts, rules, thresholds, and exceptions.

Those facets continue to matter downstream. Once a request is parsed, they shape policy selection, concept resolution, and packaging. By the time context is assembled, the eligible content has already been narrowed substantially.

Ontology

AKF captures formal meaning through an ontology. It defines the classes, properties, and typed relationships that make business meaning structurally computable. The intent is not to model the full enterprise in academic detail. The ontology is shallow, task-directed, and built to support traversal from a business object or action to the facts, controls, and related entities relevant to the current step.

Operational instances do not live in the ontology. A customer record, a case record, or a specific policy document remains outside it. The ontology provides the schema against which those instances are interpreted.

Storage

Once semantics are defined, they need to persist in structures that support later resolution. In Figure 1, that storage layer is represented by knowledge graphs and indices or metadata.

Knowledge graphs capture entities and typed relationships in a form that supports traversal across business objects. They make it possible to move from a case to a customer, from a customer to an account, or from an action to the governing control attached to it. Indices and metadata provide additional access structures. They support filtering by attributes such as jurisdiction, effective date, risk tier, ownership, or source system, and they can also support vector or section-level search when appropriate.

Bindings and Retrieval

Bindings connect semantic meaning to live enterprise sources. They map ontology classes, properties, and relationships to operational systems, document collections, APIs, records, metadata stores, or graph traversals. Without bindings, the ontology remains a formal model. With them, the system can locate relevant instances and resolve them at runtime.

Retrieval is the runtime act of selecting the material needed for the current step. In Figure 1, retrieval appears through provenance and access methods. Provenance records where material came from, which version was used, and what source path produced it. Access methods are the concrete retrieval mechanisms that use bindings plus storage structures to get the required information. Depending on the case, retrieval may rely on direct lookup, metadata filtering, graph traversal, or section-level search.

About Concept Cards and Policy Cards

AKF uses two runtime artifact types: concept cards and policy cards. Concept cards carry business facts and entity state. Policy cards carry governing logic such as eligibility, prohibitions, exceptions, approvals, effective dates, and precedence rules.

Both provide the intermediate form used for runtime context serving. They are sectioned, versioned, and structured for selection, ordering, expansion, and bounded packaging. A concept card represents a business object in runtime form, including the sections, handles, relationships, and selection rules needed for context generation. A policy card does the same for control logic, organizing the rules and related material the serving layer needs during execution.

The final object sent to the agent is usually a minimum viable context package assembled from selected sections of one or more concept and policy cards.

Ingestion, compilation, and serving context

The second architectural view explains how enterprise knowledge becomes runtime context. AKF operates through three stages: ingestion, compilation, and serving. Ingestion and compilation are primarily offline. Serving is the online runtime path.

Figure 2, Ingestion, Compilation, and Serving Context

Ingestion: governed intake of enterprise knowledge

Ingestion is where the fabric acquires the raw material of enterprise meaning. That material extends well beyond databases. It includes structured systems, SOPs, source code, audio or video, tickets, emails, cloud drives, chat systems, regulatory material, and expert interviews. Many of the boundary conditions that shape business work live outside transactional systems, so the intake path has to cover both operational records and process assets.

For structured sources, ingestion aligns fields and records to semantic identifiers, preserves keys and temporal validity, and attaches governance metadata such as lineage and effective date. For unstructured sources, ingestion segments documents into retrieval-ready units that follow business logic rather than arbitrary chunk size.

Audio and video sources are converted into transcripts, extracted decisions, and references back to the source media. Tacit knowledge enters through explicit capture workflows such as expert interviews, incident reviews, and operator walkthroughs. It becomes admissible only after it has been captured, structured, attributed, and governed like any other source.

Compilation: from source material to runtime contracts

Compilation turns ingested material into governed runtime artifacts. This is where vocabulary, taxonomy, ontology, storage, and bindings become operational together. The context compiler resolves synonyms and aliases, assigns taxonomy facets, links concepts and policies, versions artifacts, and preserves the relationships the serving layer will later use.

The output includes concept and policy card structures stable enough for generic runtime use. Concept cards typically include sections for identity, state, linked entities, supporting attributes, source handles, and supplemental evidence. Policy cards typically include sections for eligibility, exclusions, exceptions, override logic, approvals, escalation triggers, and provenance.

Compilation also preserves the distinction between template and instance. A concept-type or policy-type card defines a runtime structure in advance, and serving can later instantiate part or all of that structure for a specific request. That pre-work keeps the online path predictable.

The compiler also prepares relationship handles. The ontology may define that certain concept classes are governed by certain policy classes, while the binding layer defines how those relationships resolve in operational systems. Versioning is part of the same stage. AKF needs explicit versions, effective periods, and replacement relationships so the serving layer can reconstruct the rule state in force for a given step.

About SKILL.md

SKILL.md provides task framing for the serving layer. Concept cards and policy cards supply the relevant business facts and governing logic. SKILL.md defines the work being attempted in the current step, including task shape, required inputs, expected outputs, and execution intent. The context server uses that task framing to determine what is mandatory, what is optional, and how the selected concept and policy sections should be ordered in the final package.

Serving: online assembly of minimum viable context

Serving begins when an agent asks for context for a specific step. The request may be natural language or a structured equivalent. The serving layer parses it, extracts intent, entity references, and candidate taxonomy facets, and normalizes those values through the vocabulary layer. The result is a semantically typed request frame.

From there, the system uses the ontology to determine which classes and relationships are relevant. At that point it knows what kinds of objects and policies are in play, but not yet where their instances live. The binding layer resolves the relevant sources, retrieves or instantiates the needed concept sections, and identifies the governing policy path through typed relationships and contextual filters.

The agent does not need to name the correct policy or know where it resides. The serving layer moves from the business object or action to the applicable policy class, then resolves the policy instance through the binding layer and the current taxonomy facets.

Once the server has the selected concept and policy material, it assembles the final package. That package is the minimum viable context, or MVC (see next section). Policy material usually comes first because it defines the allowed action space. Concept facts follow because they determine whether policy conditions are satisfied. Supporting evidence and provenance come after the controlling material.

Minimum viable context as an engineering discipline

MVC treats context as a designed runtime artifact rather than an uncontrolled prompt dump.

Priority comes first. Mandatory policy blocks and mandatory concept blocks are identified before supporting content.

Token budgeting comes next. The server reserves space for the request frame, semantic bindings, controlling rules, required facts, and provenance. Optional material is added only if space remains. Stable cut-line rules determine what drops out when the package reaches its limit.

Expandability provides a controlled way to add detail. Because concept and policy cards are sectioned and carry stable identifiers, the agent can request additional blocks by reference when more detail is required. The first response remains bounded, while follow-on requests can retrieve narrower additions such as a full exclusion clause or the evidence behind a threshold.

Source discipline constrains the package to material that entered through the governed semantic, binding, and provenance path.

Why AKF is more than plain RAG

Plain retrieval-augmented generation typically depends on search over chunks and then leaves the model to infer which parts are controlling and which are supporting. AKF introduces structure before reasoning begins. It uses scoped vocabulary senses to reduce ambiguity, taxonomy facets to constrain applicability, ontology relationships to discover relevant controls, bindings to resolve live enterprise sources, and packing rules that place governing logic ahead of supporting narrative.

Conclusion

The Agentic Knowledge Fabric makes Agentic Process Automation operationally viable. It gives agents the business context required for the current step in a form that is bounded, policy-aware, traceable, and usable at runtime.

Its value appears before the agent takes action. The fabric prepares enterprise meaning for runtime use, so a live request can be matched to the relevant facts, controls, and decision context without forcing the agent to search across raw systems and documents. The result is a minimum viable context package shaped for the step at hand.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

Agentic Process Automation – Role-Based Evaluation Framework for Agents

Agentic Process Automation puts agents inside enterprise workflows at scale — thousands of them, making decisions, routing work, invoking tools. Evaluating whether each one is safe to operate requires matching performance criteria to the governance risk each agent actually carries.

Introduction

Agentic Process Automation puts agents inside enterprise workflows at scale — thousands of them, making decisions, routing work, invoking tools. Evaluating whether each one is safe to operate requires matching performance criteria to the governance risk each agent actually carries.

That matching is the core problem. An agent can complete tasks quickly while violating policy. It can remain compliant while consuming too much compute to be viable. It can appear accurate while using tools incorrectly, escalating poorly, or behaving inconsistently across similar cases. A few summary metrics or anecdotal feedback are not enough. And even when the right things are measured, the meaning of a weakness depends on context. A reliability issue that is tolerable in a low-risk drafting workflow is disqualifying in a multi-step process where the agent has broad discretion. Without a way to classify the operating context and then evaluate the agent within that context, organizations drift toward either over-control or under-control.

APA addresses that problem with two linked models. The first is a governance posture matrix built on two axes — autonomy and criticality — that classifies each agent use into one of four roles: Worker, Assistant, Administrator, or Approver. The second is a capability profile built on seven operational dimensions that measures how the agent performs within the assigned role. The governance role determines which dimensions matter most, which dimensions carry hard minimum thresholds, and which weaknesses are operationally unacceptable. The sections that follow describe the two models, explain how they interact, and walk through a worked example.

The Two Models

The first model is the governance classification. It places an agent use on a two-axis grid. The vertical axis is autonomy, which measures delegated discretion: how much freedom the agent has to choose methods, sequence actions, and adapt to inputs. The horizontal axis is criticality, which measures consequence severity if the agent is wrong, acts when it should not, or fails to escalate when it should. The purpose of this model is classification and it determines the control posture: how much oversight, verification, monitoring, and approval the use requires.

Figure 1, Agent Evaluation Framework

The four governance quadrants map cleanly to familiar enterprise roles across industries such as banking, insurance, medical operations, and manufacturing. In each case, the mapping follows the same logic. The Worker role is a tightly bounded execution role with limited consequences. The Assistant role is also narrow in scope, but its output feeds a high-stakes decision. The Administrator role has broad procedural discretion in a domain where errors are recoverable. The Approver role combines broad discretion with severe consequences if the decision is wrong.

In banking loan origination, for example, a Loan Processor aligns to Worker because the role executes standardized steps in a constrained lane. A Clerk aligns to Assistant because the role prepares material that supports a regulated decision but does not make that decision. An Underwriter aligns to Administrator because the role exercises real discretion across multiple inputs and systems, though the process remains administratively recoverable. A Loan Officer aligns to Approver because the role has both discretion and authority in a materially consequential outcome. The same pattern holds across other industries. The mapping is illustrative rather than prescriptive, but it shows that the quadrant model corresponds to operating structures enterprises already recognize.

The second model is the capability profile. It measures the agent across seven operational dimensions: task completion, output quality, policy compliance, escalation judgment, tool-use correctness, reliability, and efficiency. The purpose of this model is evaluation. It determines whether the agent is performing to standard within the operating posture assigned by the governance matrix.

These models are intentionally compact. A larger enterprise framework could also score dimensions such as observability, reversibility, coupling, or blast radius. Those factors still matter, but here they are incorporated either into the criticality judgment or into the control requirements that follow classification. The practical sequence remains simple: classify the use, then evaluate the agent in a way that matches that class.

At-a-Glance: Agent Evaluation Roles

Each governance quadrant defines a distinct operating posture based on autonomy and criticality. The quadrant tells the organization how much control the use requires and what kind of performance evidence matters most. It is the bridge between exposure and evaluation.

Figure 2, Agent Evaluation Roles

The four roles can be summarized briefly. Worker is a narrow, low-consequence role where the main question is whether the agent delivers useful value. Assistant is also narrow, but its output feeds a sensitive decision, so trustworthiness and proper handoff matter more than speed. Administrator expands delegated discretion in a recoverable domain, making stability and correct tool use central. Approver combines broad discretion with severe consequences, which means protective behavior dominates the evaluation model.

Role: Worker - Low Autonomy, Low Criticality

The Worker role is the lowest-risk operating posture. The agent operates inside a tightly bounded lane, and the consequences of failure are limited. Typical uses include internal drafting support, constrained summarization, non-material triage, or low-sensitivity classification workflows where outputs are visible, reversible, and easy to correct. The agent has little discretion, and the organization can keep the blast radius small.

That containment posture shapes the control model. Permissions should remain narrow. Outputs should be easy to inspect, override, or discard. Logging should support iteration, comparison, and troubleshooting, but it does not need the depth required in higher-consequence settings. The management objective in this quadrant is to determine whether the agent creates enough value to justify continued deployment.

That is why task completion and output quality carry the highest weight. In this quadrant, the main failure mode is not harm. It is irrelevance. If the agent does not complete useful work or does not produce acceptable outputs, the deployment fails even if it is well controlled. Efficiency also matters because low-risk settings are where the business case is tested. An accurate agent that is too slow or too expensive for a low-value task still fails operationally.

Reliability and tool-use correctness still matter, but moderate weakness can be tolerated during iteration when failures are visible and contained. Policy compliance and escalation judgment are measured as well, though they are not primary drivers unless the agent begins to drift outside its containment boundary. At that point the problem is no longer just poor performance. The operating posture itself may need to be reconsidered.

Role: Assistant - Low Autonomy, High Criticality

The Assistant role governs uses where the agent remains in a narrow lane, but the process it supports carries material consequences. Typical uses include recommendation generation for regulated reviews, evidence preparation for approvals, financial pre-checks, or structured document validation in a high-stakes process. The agent does not execute the final decision, but its output influences a sensitive decision made by a person or formal control point.

That distinction is important. Narrow scope does not remove risk when the output feeds a consequential gate. If the evidence is incomplete, misleading, poorly assembled, or routed incorrectly, the gate is weakened even if a human remains in the loop. The purpose of the Assistant posture is therefore to preserve gate integrity while still capturing the throughput and consistency benefits of agent support.

For that reason, output quality, policy compliance, and escalation judgment all carry the highest weight. The agent must produce work a reviewer can trust. It must remain inside the approval path. It must escalate uncertain or ambiguous cases instead of forcing them through. Reliability and tool-use correctness also matter because unstable behavior or bad tool execution can quietly distort what reaches the reviewer. Efficiency is deliberately less important here. Speed matters only after trustworthiness and boundary discipline are in place.

The threshold logic follows directly from that posture. Weak efficiency may be tolerable. Weak compliance, poor escalation, or unreliable output quality is not. In this quadrant, protective dimensions override a strong aggregate profile because the whole operating model depends on them.

Role: Administrator - High Autonomy, Low Criticality

The Administrator role governs uses where the agent has meaningful freedom to choose methods, select tools, sequence actions, and adapt to inputs, but operates in a domain where errors are recoverable and the consequences remain limited. Typical uses include internal research support, low-sensitivity orchestration, content assembly in non-material workflows, or internal process helpers that span multiple steps and systems.

The central purpose of this posture is validation. The organization is deliberately expanding the agent’s operating envelope in a low-consequence setting to determine whether autonomous behavior is actually stable. The question is no longer whether the agent can complete a narrow task. The question is whether it can sustain coherent behavior across multiple steps, tools, and decision points without becoming brittle, erratic, or difficult to control.

That is why reliability and tool-use correctness become the dominant dimensions. These are the strongest indicators of whether broader delegation is warranted. An agent that appears useful but behaves inconsistently has not earned sustained autonomy. An agent that reasons plausibly but selects the wrong tool or misuses parameters introduces hidden failure modes that compound as complexity rises. Task completion and output quality still matter because the agent must produce value, but they are not sufficient on their own.

Compliance and escalation remain part of the profile, though they are not the main drivers in this quadrant because there is no high-impact gate being protected. Efficiency sits in the middle. The organization wants reasonable economics, but it can tolerate some overhead while learning whether autonomous operation is viable. The main risk in this posture is premature trust: giving an agent broader delegation before its behavioral stability is proven.

Role: Approver - High Autonomy, High Criticality

The Approver role is the highest-risk operating posture. The agent has broad discretion in a domain where the consequences of failure are severe. Typical uses include complex case handling in regulated workflows, multi-step decision support across multiple systems, or sensitive operational orchestration where a wrong action can cause material financial, regulatory, or operational harm.

In this quadrant, both axes are elevated at the same time. The agent has enough autonomy to take action paths the organization did not explicitly script, and the cost of a wrong action is high. Capability alone is therefore insufficient. The operating model requires strong permissions control, deep traceability, independent verification for sensitive actions, explicit exception handling, rollback readiness, and adversarial testing.

The evaluation logic reflects that exposure. Policy compliance, reliability, tool-use correctness, and escalation judgment carry maximum weight because they are the protective dimensions that keep the agent inside its permitted operating envelope. Output quality remains important, but it is secondary to bounded behavior. Task completion matters, but throughput cannot compensate for weak control integrity. Efficiency is weighted lowest because cost and latency are subordinate to safety, traceability, and control.

The threshold logic is also strongest here. Failure in a protective dimension should suspend, constrain, or materially narrow the agent’s operating role until remediation is complete. A strong weighted average does not offset weak compliance, unreliable behavior, incorrect tool use, or poor escalation judgment in a high-autonomy, high-criticality environment.

Capability Model: the Seven Dimensions

In APA, agents participate in enterprise business processes alongside people. They classify documents, route work, make bounded decisions, invoke tools, and hand tasks to humans or systems. Because agents are performing work that organizations already understand at the process level, it is useful to begin with a familiar performance management vocabulary.

Figure 3: Agent Capability Model

The capability model evaluates agents across seven dimensions: task completion, output quality, policy compliance, escalation judgment, tool-use correctness, reliability, and efficiency. Four of these dimensions come from familiar enterprise performance management practice. Three address behaviors and costs that are specific to agents. Together, they provide a complete profile of whether the agent is doing the work correctly, staying within its operating boundaries, and using enterprise resources in a viable way.

Human-Like Performance Dimensions

These four dimensions align closely to how organizations already evaluate people in operational roles. They make the framework easier for business and operations teams to understand and apply.

Task Completion

Task completion measures whether the agent finished the assigned work and moved the process to its next step. Evidence includes completion rate, successful resolution rate, downstream acceptance, and reduction in manual rework. This is the most basic operational question: did the assigned work get done?

This dimension is separate from output quality. An agent may complete a task while producing weak work, or fail to complete a task despite generating strong partial output. Measuring completion independently keeps the framework focused on actual process progression rather than surface impressions of usefulness.

Output Quality

Output quality measures whether the agent’s work product is correct, complete, consistent, and fit for downstream use. Evidence includes output sampling, deterministic validation, domain review, completeness checks, metadata checks, and downstream usability.

In multi-step workflows, output quality also includes handoff quality. An agent that finishes its local task but omits identifiers, strips relevant context, or fails to pass exception flags has produced a defective output even if the task appears complete from its own perspective.

Policy Compliance

Policy compliance measures whether the agent stayed within role boundaries, respected permissions, and followed required business and process rules. This is the direct analogue of rule adherence in human performance management.

Compliance failures should be measured explicitly rather than inferred from bad outcomes. An agent may produce acceptable results while still violating process rules, skipping controls, or acting outside its authorized scope. That makes compliance a distinct dimension rather than a byproduct of general performance.

Escalation Judgment

Escalation judgment measures whether the agent knew when to proceed, when to ask for clarification, and when to hand work to a person or another agent. It captures whether the agent recognizes the limits of its authority, certainty, and competence.

This dimension is especially important in enterprise settings because many failures come from inappropriate continuation rather than obvious task error. An agent that proceeds when it should defer can create downstream problems even when its local reasoning appears plausible.

Agent-Specific Performance Dimensions

These three dimensions reflect behaviors and cost structures that do not map cleanly to traditional human performance management. They require engineering instrumentation in addition to business review.

Tool-Use Correctness

Tool-use correctness measures whether the agent selected appropriate tools, invoked them with correct parameters, and interpreted tool responses correctly. This captures a distinct agent failure mode: plausible reasoning paired with incorrect execution.

This dimension must be measured directly through traces, tool-call records, parameter inspection, and response validation. An agent may appear effective at the surface level while introducing hidden execution errors that only become visible after they propagate through downstream systems.

Reliability

Reliability measures consistency and stability across repeated runs, similar inputs, and normal operating load. For agents, unreliability may reflect prompt sensitivity, context failure, model instability, or branching behavior across equivalent cases.

This dimension matters because average performance can conceal unstable behavior. An agent that succeeds on most runs but behaves unpredictably on similar cases is difficult to trust operationally, especially when the organization is deciding whether to expand its delegated scope.

Efficiency

Efficiency measures resource use relative to value delivered. For agents, this includes latency, cost per task, retry counts, token consumption, and tool-call volume. It addresses operational viability rather than correctness.

Efficiency should remain a distinct dimension because an agent can be accurate and compliant while still being economically weak. A deployment that consumes too much compute, generates too many retries, or adds too much latency may fail in practice even if the work product is acceptable.

Caveats Around Ownership

The split between the two groups also implies a split in ownership. The human-like dimensions, task completion, output quality, policy compliance, and escalation judgment, can largely be owned by operations and business teams through review, sampling, audit, and exception analysis. The agent-specific dimensions, tool-use correctness, reliability, and efficiency, require engineering and platform teams to build and maintain instrumentation such as trace logs, tool-call records, token accounting, and consistency testing. Making that ownership model explicit is important because performance management becomes weak very quickly when measurement responsibility is left ambiguous between teams.

Measurement and Scoring

A capability profile is only useful if it can be scored and interpreted consistently. Each dimension needs a scoring method, an evidence source, and an interpretation that changes by governance quadrant. The scale used here is 0 to 5. A score of 1 indicates failure. A 2 indicates inconsistent or below-standard performance. A 3 indicates acceptable production performance. A 4 indicates strong performance. A 5 indicates dependable performance with little operational concern. These are performance scores, distinct from the weighting model used by the governance posture.

The score must be grounded in evidence from three sources. Log-based instrumentation shows what the agent actually did: traces, tool calls, retries, latency, exceptions, approvals, and boundary checks. Automated validation shows whether the behavior or output was correct: schema checks, rule checks, known-answer tests, and consistency tests. Human review captures what automation and logs do not: scored sample review, domain audits, override analysis, and edge-case inspection. As criticality rises, the depth of evidence must rise as well.

The scoring flow has four steps. First, classify the use into a governance quadrant. Second, apply the weights and minimum thresholds associated with that quadrant. Third, score all seven capability dimensions using evidence. Fourth, review both the weighted profile and the threshold results. The weighted profile shows the agent’s overall operating shape. The threshold check answers a different question: is the current control posture still valid? If a protective dimension falls below threshold, that failure overrides the weighted result. Strong averages must not mask dangerous weaknesses.

Example: Clinic Scheduling and Referral Agent

Consider a clinic scheduling and referral agent used in a mid-size medical practice. Its role is to manage appointment scheduling, process referral routing, handle prior authorization submissions to insurers, coordinate follow-up reminders, and assemble patient documentation packages for specialist visits. It has meaningful discretion: it selects scheduling slots based on provider availability and patient history, chooses insurer workflows, decides when to bundle or split documentation requests, and adapts its sequencing based on urgency flags and resource constraints. But, importantly, it does not make clinical decisions. Exception cases are reviewed by a care coordinator, but routine administrative workflows are handled end to end without approval gates.

Figure 4: Agent Capability Model

Under the governance posture matrix, this use fits the Administrator quadrant: high autonomy, low criticality. Autonomy is high because the agent makes real procedural choices across multiple systems. Criticality remains lower because the direct consequences of error are operational and generally recoverable: scheduling conflicts, delayed authorizations, misrouted referrals, or incomplete document packages. These failures may still matter to service quality and timeliness, but they are not the same as direct clinical decision errors. The purpose of this posture is to test whether autonomous administrative behavior is stable, bounded, and dependable.

That classification determines the evaluation priorities. In Administrator, reliability and tool-use correctness are dominant because the organization is testing whether the agent can chain actions across systems without instability. Task completion and output quality still matter because the agent must remain useful. Policy compliance and escalation judgment are measured as well because the agent still operates inside defined boundaries. Efficiency matters, but less than stability.

Assume the agent scores 3 on task completion, 4 on output quality, 2 on policy compliance, 2 on escalation judgment, 2 on tool-use correctness, 2 on reliability, and 4 on efficiency. On that profile, only output quality and efficiency meet minimum expectations. The agent is producing acceptable work products and doing so at reasonable cost, but it is failing on the dimensions most important to the Administrator posture. Reliability and tool-use correctness are especially weak. That means the agent’s autonomous behavior is not yet stable enough to justify the delegation it has been given.

The practical failures are easy to see. The agent may choose the wrong insurer workflow, pass incorrect identifiers into a scheduling system, or assemble different documentation packages for materially similar cases. Weak policy compliance and escalation judgment indicate that it is also not staying reliably within its operating boundaries or handing off cases when it should. These are precisely the types of weaknesses the Administrator quadrant is meant to surface before the agent is trusted with more consequential work.

The operational conclusion is therefore clear. This is not an “adequate with room for improvement” result. The agent is failing across most of the profile, including the two dimensions that carry the most weight in its quadrant. The remediation path should include deterministic validation on tool parameters before execution, stronger consistency testing across similar cases, tighter permission scoping, and explicit escalation triggers for case types that should defer to a care coordinator. Until those dimensions improve, the agent’s autonomy should be constrained through fewer workflow paths, tighter parameter controls, and expanded human review.

This example shows the practical value of the framework. A weakness is not interpreted in isolation. It is interpreted through the governance posture. The same score may be tolerable in Worker and disqualifying in Administrator because the operating purpose of the two postures is different.

Conclusion

Agent performance management in APA requires two linked instruments. The governance posture matrix classifies each use case by autonomy and criticality and assigns the control posture that fits the exposure. The capability profile evaluates the agent across seven dimensions, four drawn from familiar human performance management practice and three specific to agent behavior and infrastructure economics.

The connection between the two models is the key design choice. Governance classification determines what matters most, what minimum thresholds must hold, and which kinds of weakness are unacceptable in that role. An Administrator use is judged primarily on whether autonomous behavior is stable and tool execution is sound. An Assistant use is judged primarily on whether the output is trustworthy, policy compliant, and correctly escalated. The same seven dimensions are used across the framework, but their interpretation changes with the operating posture.

For organizations moving agents into real business processes, the operating method is simple: classify the use, score the agent, and let the governance posture determine how the results should be interpreted. That prevents strong averages from masking dangerous gaps, aligns evaluation with the level of delegated trust, and gives business and engineering teams a common framework for deciding where agents can safely operate, where they need tighter controls, and where they are not yet ready.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Agentic Process Automation – The Agentic Knowledge Fabric

The Agentic Knowledge Fabric is a runtime knowledge layer that captures enterprise knowledge from documents, systems, processes, policies, and expert judgment, then serves the minimum viable context required for effective and token-aware agent operations.

Introduction

Agentic Process Automation has agents participating directly in business processes, making step-level decisions, interpreting mixed inputs, coordinating across systems, and operating within policy and control boundaries. That shift matters because many enterprise processes now depend on judgment over documents, messages, exceptions, thresholds, and domain rules that do not fit cleanly into deterministic flow logic.

When an agent executes one of those enterprise steps, output quality depends on whether it receives the right context for that specific task: the right subset of enterprise knowledge, containing the correct definitions, policy constraints, exceptions, and decision thresholds. In most enterprises, that context is fragmented across policy manuals, standard operating procedures, source systems, regulatory texts, tickets, emails, and human judgment. As a result, the knowledge needed for a single decision step is rarely assembled in a form that is complete, scoped, and usable at execution time.

The Agentic Knowledge Fabric (AKF) is the knowledge foundation for Agentic Process Automation (APA). It addresses that operating gap by converting fragmented enterprise knowledge into bounded context artifacts that can be retrieved and assembled under explicit context limits.

AKF is built on an engineering premise: context should be treated as a product with predictable size, stable identifiers, provenance, and deterministic assembly. That premise drives both the logical architecture—how meaning is represented, indexed, linked, and selected—and the operational pipeline that builds and maintains those representations.

Collaboration Challenges

The parable of the blind men and the elephant captures the most concrete failure mode for agent execution: different teams experience the same enterprise object through different interfaces and therefore form different meanings. A “customer” in marketing is an audience member; in underwriting it is an applicant; in servicing it is an account holder; in AML it is a regulated subject tied to beneficial ownership and risk controls. Each view is locally valid because each team touches a different part of the operational system through different stages and obligations. The system-level gap is that most enterprises do not represent those meanings as explicit, scoped senses with enforceable boundaries.

Figure 1, Knowledge Foibles

The “broken telephone” dynamic describes how meaning erodes as knowledge moves through delivery layers. A policy intent begins in a control owner’s language, then becomes a requirement, then a user story, then an implementation, then a runbook, then a ticket template, then a data field label. At each handoff, qualifiers and exceptions are dropped because they are costly to encode, hard to test, or treated as edge cases. The resulting artifacts can remain internally consistent—tables exist, fields are populated, and SOPs read plausibly—while the operational meaning has shifted. For agents, that shift becomes a missing decision boundary.

Imperfect communications amplify the same failure even when intent does not degrade in a single linear chain. Large enterprises coordinate through partial artifacts: email threads, Slack snippets, meeting notes, tickets, internal wikis, and undocumented tribal knowledge. These channels support speed and local coordination. They rarely preserve replayable decision logic, applicability conditions, or provenance suitable for audit. Humans compensate with shared context and ad hoc clarification. Agents require a substrate that makes those constraints explicit and retrievable at the decision step.

When these failures combine—meaning drift across handoffs and multiple valid meanings across domains—the enterprise produces knowledge artifacts that are difficult to use for agent execution. Similarity search can surface relevant passages, but it does not consistently bind the correct term sense, the governing exception, or the controlling threshold for the current task step. Agents then operate with either too much context that dilutes constraints or too little context that omits them. AKF is motivated by a direct requirement: agents need runtime-delivered meaning that is disambiguated, scoped, policy-bound, and packaged to the decision step.

Agentic Knowledge Fabric: Semantics Optimized for Agent Context Generation

AKF assembles runtime context through four mechanisms: semantics, storage, retrieval, and a core foundation of concept and policy artifacts. Together, these mechanisms define the logical architecture for how enterprise meaning is represented, indexed, linked, and selected.

Figure 2, Semantics for Agent Context Generation

Semantics

Semantics reduces ambiguity before retrieval and packing begin. The semantic layer supports step-scoped context assembly with stable references and predictable structure.

We use vocabularies are operational dictionaries tied to enterprise usage: the terms found in UI labels, tickets, logs, data fields, emails, and SOPs. Each term is normalized to a stable identifier. When the enterprise uses the same word in multiple domains, vocabulary entries are bound to explicit scoped senses, such as “customer:marketing” and “customer:aml.” Those scoped senses become retrieval filters, which prevents cross-domain leakage when an agent request uses a term that has multiple meanings.

Taxonomies in AKF are organized as retrieval facets aligned to decision variance. Common facets include jurisdiction, product family, process stage, risk tier, and control category because those dimensions often drive different thresholds, exception paths, and approval requirements. Their role is practical: they narrow the candidate set early so later stages can focus on the most relevant policy and evidence fragments.

And we keep ontologies shallow and task-directed. They focus on typed links that support context computation and traversal. This makes it possible to traverse from a task object to the controlling constraints without building a deep enterprise-wide semantic model that is expensive to maintain and difficult to operate.

Storage

Storage supports heterogeneous sources and runtime assembly. It holds representations at multiple granularities so the context server can compose a small, decision-ready package instead of forwarding whole documents.

Knowledge graphs store entity networks and typed links aligned to the semantic layer. Their role is navigational: they support targeted hops from a task object to governing policies, required approvals, dependent entities, and authoritative sources. That improves retrieval precision and reduces the amount of candidate text that must later be ranked and packed.

Indices and metadata support deterministic filtering and ranking. Relational metadata captures constraints such as business unit, system of record, policy jurisdiction, effective date, approval status, and ownership. Embeddings (in vector databases) support similarity ranking when queries are partial or sources are unstructured. Metadata (in relational databases) bounds the candidate set; embeddings help order the remaining items.

Content is stored in retrieval-sized units – concept and policy cards described later – that are designed for assembly. Typical units include policy clauses, decision tables, exception definitions, SOP fragments tied to a tool action, and concept attribute blocks that an agent can cite. Each unit carries stable identifiers, provenance pointers, and governance metadata so a context package can be audited and reproduced.

Retrieval

Retrieval produces a context package. It begins with intent classification, entity binding, vocabulary expansion, and scope reduction through taxonomy facets and metadata filters. From there, the system traverses the graph to locate governing constraints and ranks candidate fragments using relevance and freshness signals.

The retrieval stage is where the mechanisms described earlier begin to operate together. Semantics constrains the meaning of the request, storage provides the candidate units and links, and retrieval assembles those inputs into an ordered set of fragments suitable for serving.

Provenance is returned with each retrieved fragment as operational metadata. It includes origin pointers to actual data and corpus documents, versioning and effective dates, and the selection path used to retrieve the fragment. Provenance supports not only traditional audit and lineage needs but also improves runtime behavior by allowing the server to favor authoritative, compact sources and to return the originating text when disagreements arise.

Concept and Policy Cards

Concept cards represent the stable entities and facts required for execution: customers, accounts, products, controls, cases, claims, shipments, vendors, thresholds, and their canonical identifiers. They keep those entities consistent across systems and representations so a request can bind to the correct object and then retrieve the relevant attributes and relationships for the current step.

Policy cards represent decision boundaries: rules, exceptions, overrides, approval thresholds, escalation conditions, and conflict-resolution precedence. They are structured with explicit applicability criteria so the server can select the governing logic for a task step directly, without scanning broad narrative policy text.

Token Budgets and Context Packing

The context window is the scarcest resource in the agent landscape, so correctly assembling – or packing – the context window is a first-class problem. Context packing in AKF is implemented as deterministic allocation and ordering. The context server starts with a target size for each request and allocates portions of that space to block types. A common allocation reserves capacity for request framing and entity bindings, assigns the largest share to governing policy and decision logic, and uses the remainder for supporting evidence and provenance pointers.

Packing proceeds in priority order with explicit cut lines. Mandatory blocks are packed first: identifiers for bound entities, governing policy clauses, required approvals, and any disqualifying exclusions relevant to the step. Optional blocks are added next: exceptions, decision tables, thresholds, tool-specific SOP fragments, and supporting evidence. When the package exceeds the target size, the server applies stable reduction rules, such as removing examples before rules, commentary before decision tables, and secondary evidence before controlling clauses. The result is a context package whose shape remains stable across runs for the same request type.

Agentic Knowledge Fabric: Ingesting, Compiling, and Serving the Agent Context Window

The logical architecture described earlier explains how meaning is represented, stored, and selected. This section turns to the operating flow that makes those capabilities usable in practice. AKF works through three stages: ingestion, compilation, and serving. Ingestion finds and prepares enterprise knowledge from structured, unstructured, and multi-modal sources. Compilation transforms that material into concept cards, policy cards, and minimum viable context artifacts that can be indexed, linked, and maintained. Serving takes an incoming agent request and assembles the relevant context into a bounded package that is ready for execution. Together, these three stages explain how fragmented enterprise knowledge becomes step-specific agent context.

Figure 3, Ingestion, Compilation, and Serving Context

Ingestion

Ingestion begins with discovery: identifying authoritative knowledge sources and classifying them by structure, ownership, access constraints, and change rate. It covers operational systems and curated datasets. It also includes process assets such as SOPs, runbooks, decision playbooks, tickets, and internal guidance because those materials often contain boundary conditions and exception handling absent from transactional records.

Structured ingestion covers relational tables, event streams, logs, and curated datasets. The mechanical work is entity and field alignment: mapping records to concept identifiers, attaching governance metadata such as system of record, lineage, and effective dates, and preserving enough schema semantics for deterministic filtering. This allows structured records to serve as compact grounding evidence without forcing an agent to interpret raw schemas inside the context window.

Unstructured ingestion covers documents and artifacts such as PDFs, internal wikis, tickets, emails, and file shares. The engineering task is segmentation into retrieval-sized units with stable references to source location and version. Segmentation follows downstream decision needs, so units align to decision boundaries, tool actions, and concept attributes instead of arbitrary chunk boundaries.

Multi-modal ingestion adds transcription and extraction for audio and video. The pipeline produces time-coded transcripts, extracted decisions and action items, and references to the underlying media segment. This matters because many operational decisions are communicated verbally, and replayable provenance often requires returning the exact segment that supported a decision.

Tacit knowledge capture is treated as an ingestion source with a repeatable method. Expert interviews, incident reviews, and operator walkthroughs are converted into structured artifacts that preserve decision rationale, recurring exception patterns, and boundary conditions. Each artifact is linked to concepts and policy boundaries and stamped with provenance so it can be retrieved and served like any other unit.

Compilation

Compilation transforms ingested material into the artifacts the fabric can actually use at runtime. In the updated flow, this stage centers on two compiled products—concept cards and policy cards—and on the compiler process that assembles and maintains them. The objective is to turn raw enterprise material into bounded, structured units that can later be selected and packaged for a specific agent step.

Concept cards capture the business entities and facts an agent may need to reference during execution. A concept card typically includes the concept identifier, scoped senses, synonyms, owning systems, key attributes, and relevant relationships. The card is organized so downstream stages can retrieve only the needed sections, such as identifiers, thresholds, related entities, or attribute blocks, without pulling the full card into context. In the updated diagram, the concept card is one of the two primary compiled artifacts feeding the compiler loop.

Policy cards capture decision logic in a similarly bounded form. A policy card contains rules, exceptions, overrides, thresholds, escalation requirements, applicability criteria, and precedence information, along with pointers to authoritative sources and versions. This turns long-form policy material into a retrieval-ready unit that can be selected directly for a task step. In the updated diagram, policy cards sit alongside concept cards as equal inputs into compilation, reflecting that runtime context depends on both business facts and governing constraints.

The Context Compiler resolves synonyms through the semantic layer, applies taxonomy facets, links entities and policies, versions cards, and maintains the relationships needed for later retrieval. Its role is iterative rather than one-time: as source material changes, the compiler updates cards, preserves structure, and keeps them aligned to the storage and retrieval model described earlier. The circular flow in the figure is useful here because compilation is not a simple pass-through stage; it is a continuing process of normalization, card generation, refinement, and maintenance.

Compilation also produces the specifications that later allow the serving layer to assemble Minimum Viable Context. For each task or process step, the system defines what sections of which concept cards and policy cards are required for correctness and audit. Those specifications are usually expressed through templates, then adjusted by heuristics and operational feedback. Templates are typically co-developed by process owners, domain SMEs, and platform teams because they encode the step-level view of what an agent must know before it can act.

A claims adjudication step makes this concrete. For that step, the compiled concept material may include claim identifier, loss type, claimed amount, timestamps, evidence pointers, policy identifier, and jurisdiction. The compiled policy material may include payout thresholds, applicable exclusions, and escalation rules tied to fraud indicators or manual review triggers. The point of compilation is not yet to serve those items to the agent; it is to express them as stable cards and card sections so the serving stage can later assemble the minimum viable context for that specific step with predictable structure and scope.

Serving

Serving begins when an agent issues a request for a specific task step. That request is the trigger for context assembly. The serving layer interprets the request, binds the relevant entities, identifies the task or process step, and determines which compiled concept and policy materials are applicable. It then uses the retrieval structures described earlier—semantic bindings, metadata constraints, and linked relationships—to locate the card sections and policy fragments that govern that step.

The context server takes the incoming request, selects the relevant step template, applies jurisdictional and process-specific filters, and retrieves the candidate concept and policy blocks needed for the task. From there, it assembles a minimum viable context package: a bounded set of materials that gives the agent the facts, rules, thresholds, exceptions, and provenance needed to act. The package is ordered deliberately so the most controlling items, such as governing rules or exclusions, appear ahead of supporting evidence and secondary context.

The output of serving is a step-specific context package prepared for direct agent use. Each block is returned with stable identifiers and provenance pointers so the agent can reason over the material, reference it explicitly, and support downstream audit or human review. The package is shaped according to the packing and cut-line rules defined earlier, which allows the server to preserve the most important decision material when context space is limited.

Serving also establishes a clear interaction pattern between the agent and the fabric. The first response gives the agent the minimum viable context for the current step. If the agent requires more detail, it can issue another request for specific blocks, such as the full text of an exclusion clause, the evidence behind a threshold, or the escalation rule associated with a manual review path. Because those blocks carry stable identifiers, the server can fulfill the request directly without reconstructing or resending the entire package.

This makes serving an active runtime function rather than a one-time delivery step. The server responds to the initial request, returns the smallest sufficient context package, and then supports bounded follow-on requests as the task unfolds. In this way, the serving layer provides a controlled interface between the compiled knowledge assets in the fabric and the agent that must use them during execution.

Comparisons with Alternatives

Traditional knowledge management systems are optimized for human discovery and long-form explanation. They are valuable repositories, but their dominant unit is the document, and their navigation assumes human readers who can skim, infer applicability, and reconcile conflicts. AKF shifts the unit of delivery to a packed context package composed of retrieval-sized fragments tied to concepts and decision boundaries, with deterministic assembly and provenance.

Enterprise ontology programs focus on conceptual consistency and semantic integration across systems. They can improve data interoperability, but they often expand in scope and depth until maintenance dominates, and they do not necessarily produce step-scoped decision artifacts that can be served during runtime execution. AKF uses shallow ontologies and typed links for traversal and applicability, while placing decision logic in explicit policy cards designed for retrieval and packing.

Plain RAG systems rely on similarity search over chunks and then expect the model to infer decision boundaries from retrieved text. Better chunking, metadata filters, and reranking can improve retrieval quality, and many teams should try those steps first. But those improvements still do not fully address scoped term senses, explicit policy applicability, or deterministic packing order under runtime constraints. AKF addresses those gaps through scoped senses in vocabularies, applicability facets in taxonomies and metadata, graph traversal to bind governing policies, and packing rules that place decision boundaries ahead of supporting narrative.

Conclusion

Agentic Process Automation depends on more than capable agents. It depends on whether each agent receives the correct business meaning for the step it is executing: the right definitions, thresholds, rules, exceptions, and decision boundaries, delivered in a form it can use at runtime. That is the role of the Agentic Knowledge Fabric. AKF provides the knowledge foundation for APA by turning fragmented enterprise knowledge into compiled, traceable, step-specific context that can support execution inside real process and control constraints.

This is the practical link between the two ideas. APA defines a new operating model in which agents participate directly in enterprise processes. AKF supplies the context infrastructure that makes that participation dependable. Enterprises will make the shift from isolated agent pilots to durable process automation when they treat context delivery with the same engineering discipline applied to systems, controls, and data pipelines. The path usually starts with one bounded process stage, a small set of governing concepts and policy cards, and instrumentation that shows whether the delivered minimum viable context is sufficient under real operating conditions. That is often enough to determine whether an organization is experimenting with agents around the edges of a process, or building the knowledge substrate required for APA to work at scale.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Ambient Agents: Always On, Always Listening, Always Working

Ambient agents run in the background, are stateful, and long-running. Agentic Mesh offers the ecosystem services to support ambient agents at-scale.

Today, most people meet agents through a familiar interface: a chat window. The interaction is direct and mostly one-to-one. A person asks, the system answers, and the conversation ends when the session ends.

That model will not hold for the work many organizations actually need agents to do. Not all agent collaborations require a human in the loop any more than every application requires a user watching it run. Some agent work will look like pipelines, batch jobs, and background services: quiet, continuous, and mostly invisible until something goes wrong or a decision needs a signature. In that world, humans do not “chat” with agents as much as they supervise them—approving exceptions, supplying missing context, or signing off on outcomes.

The more important problem, then, is not how to perfect the chat experience. It is how to enable broad agent-to-agent coordination while still offering human interaction at the right moments. Ambient agents have to discover other agents, negotiate responsibilities, exchange artifacts, and hand work off across long-running, stateful threads. They must be able to pause, resume, and explain themselves without assuming anyone is present, and they must do so in ways that remain governable and auditable.

The obstacle is that many teams are still building as if agents are chatbots with better prompts. In an enterprise setting, that assumption produces predictable failure modes: work that cannot reliably resume after interruption, actions that cannot be attributed to a stable identity, and systems that are difficult to govern, audit, and scale. As the industry starts to converge on standards like A2A and MCP, the idea of agents collaborating over explicit protocols—rather than ad hoc UI sessions—is gaining acceptance, because it matches the shape of the work organizations actually need.

In this article, we (John Miller, my co-author, and I) lay out the architectural implications of the shift to ambient agents, and the foundation an Agentic Mesh must provide to make them safe and operational. Specifically, I examine four requirements that become non-negotiable as agents move into the background: they must be headless (unbound from a UX), distributed (able to coordinate across services), identity-bearing (so actions are controlled and attributable), and stateful (so collaboration is reliable over time).

The Chatbot Trap

Most enterprises are approaching agents with the wrong mental model. They are treating them as a new interface layer—chatbots with better reasoning—when the real destination is not a window on a screen. It is a fleet of long-running workers operating largely out of sight, coordinating with each other across systems, and producing outcomes with real operational and financial consequences.

The trap is subtle because chat is the easiest place to start. A session-bound, UX-tethered design assumes a user is present, context is ephemeral, and failures can be handled by “try again.” But the work organizations want agents to do often looks less like a chat session and more like an application: event-driven, multi-step, multi-day, interruption-prone. Information arrives late, approvals happen asynchronously, dependencies fail, and handoffs are constant. When you build agents as conversations that end, you build systems that cannot reliably continue.

That mismatch produces predictable failure modes. Work gets duplicated or dropped because there is no durable state and no resumable thread. Actions cannot be confidently attributed because agents lack stable identity, least-privilege controls, and auditable authorization boundaries. Coordination degrades into brittle glue code because there is no shared conversation fabric for agents to discover one another, route tasks, exchange artifacts, and record receipts. And when something goes wrong, teams cannot explain what happened, why it happened, or who—or what—was responsible.

The cost of waiting is not that you will fail to deploy agents. You will deploy them. The cost is that you will deploy them on a foundation that does not scale, then pay for it later in operational risk, governance debt, and expensive rewrites the moment a serious workflow spans time, systems, and teams. Ambient agents are coming whether or not the architecture is ready; the decision is whether you build the substrate now, or rebuild it later under pressure.

A good example always helps... Imagine an ambient remediation workflow after a suspected fraud event. A detection agent flags the case and opens a long-running thread. An evidence agent gathers signals from multiple systems. A compliance agent issues a ruling. A notification agent drafts customer communications. A human relationship manager supplies missing context when asked, then disappears again. The workflow can pause for hours or days, and it must survive restarts and partial failures. When services bounce mid-stream, the system has to resume safely—without re-sending customer notices, duplicating account holds, or losing the audit trail that proves who authorized what, when, and why.

Why Chatbots Still Dominate

I have been designing and building distributed systems for a long time and this approach sounds almost intuitive (well, for me anyway).

So, why is building ambient agents still in its infancy? Here are a few guesses.

A UX-bound chatbot is probably the default because it is the easiest thing to ship that still looks like “AI.” A text box plus an LLM produces immediate, legible output. It demos well and it feels finished because the conversation has a clean boundary: you open a session, you ask, you get a response, you close it. The hard parts of enterprise work—waiting, resuming, coordinating, handing off—are conveniently out of frame. For most teams under pressure to show progress, that packaging is irresistible.

There is also a simple cognitive trap at work: if all you have is a hammer, everything looks like a nail. Organizations have spent a decade building digital products around screens, sessions, and user flows. Many teams are good at UX. Far fewer have built background systems that run continuously, coordinate across services, and do useful work without someone watching. So, when “agents” arrive, teams reach for the tools they already know—UX, prompts, chat—because it is familiar. And the moment you start thinking “pipeline” or “batch job” or “always-on worker,” you are no longer in product UX land – instead you are in operations land.

Chat-first designs are also a kind of liability shield. The moment an agent operates without a human sitting in front of it, you’ve crossed from “assistive software” into “operational actor.” That triggers a different class of scrutiny: who authorized the action, what data it touched, how it can be revoked, how to audit it, how to prevent repeats, how to explain a decision after the fact. A chatbot keeps a human as the actuator, which conveniently pushes responsibility—and risk—back onto the user. “The model suggested it” is one kind of story. “The system did it” is a very different one.

Then there is the collaboration problem hiding inside the integration problem. Ambient agents only become real when they can actually do things: consume events, call systems, coordinate handoffs, write durable state, and produce outcomes. But the moment you have more than one agent in play, you also need a way for them to find each other, negotiate responsibility, pass work, and exchange artifacts without turning every handoff into a bespoke integration.

The truth is without common protocols, inter-agent coordination devolves into brittle glue code and one-off conventions. With protocols like A2A and MCP, the industry finally has a credible path to broader agent-to-agent communication—one that doesn’t require every vendor to reinvent discovery, messaging, tool invocation, and provenance from scratch.

A chat UI can deliver value while avoiding most of this. It can “talk about” the workflow without being accountable for executing it end-to-end. It can summarize a policy without being bound by least privilege. It can propose an action without generating the receipts you need when auditors show up. It can look smart while still living outside the boundaries of enterprise systems.

Underneath all of this is a harder truth: what we are describing is distributed computing, and distributed computing is hard to do well. It is hard even when the “work” is cleanly defined and the state is simple. We still need to deal with partial failure, retries, ordering, idempotency, backpressure, network partitions, inconsistent clocks, and systems that fail in ways that are perfectly normal but maddening to reason about.

But conversational, long-running interactions are distributed computing on steroids. When we add conversational, stateful interactions the problem domain becomes very, very hard. When threads persist for days, involve multiple agents, depend on intermittent human input, and must survive restarts without duplicating side effects, things get complicated very quickly. We are no longer just distributing computation; we’re distributing responsibility and memory. The failure mode isn’t “a request timed out.” It’s “the agent repeated an irreversible action,” or “the system cannot explain why a decision was made,” or “two agents diverged and nobody noticed until a customer complained.”

So, the market does what markets always do: it optimizes for what can be shipped, sold, and supported today. Chatbots fit the current tooling, pricing, and buyer expectations. Ambient agents require a foundation—identity, durable state, orchestration, observability, and governance—and they increasingly require a shared language for agent collaboration. Many vendors don’t have that foundation yet, and many buyers haven’t demanded it. But that gap won’t last. As soon as organizations ask agents to run real workflows over real time, the chat window stops being a product and starts being a crutch.

But that’s exactly the point: the chat-first approach persists not because it’s the destination, but because it’s the easiest on-ramp. To move from demos to durable enterprise workflows, we need a different agent model—so before we talk architecture, let’s define what an ambient agent actually is.

Ambient Agents

Ambient agents in Agentic Mesh have three defining characteristics: they run in the background, they continuously observe and act while collaborating with other agents, and they are long-running—meaning they retain enough state and memory to survive interruption and resume reliably.

Figure 1, Ambient Agents

Ambient agents run in the background.

They operate persistently and invisibly, embedded inside environments, workflows, and systems. In practice, they look less like “a conversation UI” and more like an always-on service: closer to an application, a pipeline, or a batch job that keeps moving even when no one is watching. They are “always on” in the practical sense—available to notice change, receive signals, and initiate work without requiring a user to start a session.

Because they run in the background, ambient agents are designed around continuity, not interaction. They can keep a process moving while humans are busy, asleep, or only intermittently involved. People still matter—often as approvers, exception handlers, and context providers—but humans are no longer the engine that keeps the thread alive. The work progresses whenever the next input arrives, whether that input comes from a person, a system, or another agent.

This background posture also changes what “control” looks like. Instead of being steered moment-to-moment through a UI, ambient agents are governed by conditions, triggers, policy, and workflow context. The unit of progress is not a back-and-forth exchange in a chat box, but a sequence of decisions and actions that unfold as the environment evolves—and that sequence has to be durable, attributable, and auditable, because it produces real outcomes.

Ambient agents continuously observe and act.

They watch their environment the way operational systems do: by interpreting telemetry, transactions, user behavior, and system state. Their job is to detect meaningful patterns—signals, anomalies, thresholds, gaps—and respond in a way that advances the workflow rather than merely generating an answer. This is one reason chatbots are the wrong mental model: observation doesn’t start when a user types. It’s already happening.

They also listen for direct input and commands from people or other agents. The key difference from a chatbot is that these inputs are not the only “start button.” An ambient agent can be driven by autonomous signals (a fraud score crossing a threshold, a document arriving, a service failing) and by intentional directives (a human escalation, a manager approval, a peer agent request). Both are first-class triggers, and in a mature system they flow through the same shared fabric so an agent can act, hand off, and wait without losing the thread. Standards like A2A and MCP matter here because they make agent-to-agent collaboration less like bespoke glue and more like a normal operating mode.

Because observation and action are continuous, ambient agents behave like coordinators. They decide when to act immediately, when to request clarification, when to wait, and when to escalate. The “conversation” becomes less about chatting and more about operating: gathering evidence, making a decision, taking an action, and leaving behind enough structure—messages, artifacts, receipts, and state—that another agent or a human can pick up the thread with confidence.

Ambient agents are long-running.

They can run for long periods because the work they support rarely completes in a single sitting: inputs arrive late, dependencies change, approvals come asynchronously, and tasks span hours or days. Long-running here is not a “long response.” It is long-lived participation in a workflow.

To make that possible, they retain memory of goals, actions, decisions, and context across sessions, reboots, and interactions. They can pause when something is missing, resume when it arrives, and continue without losing coherence. This is the point where “stateful” stops being a technical preference and becomes a requirement: without durable state, you don’t just lose context—you risk duplicate side effects, broken audit trails, and coordination failures that show up as real-world damage.

Long-running capability also enables reliable coordination with others. An ambient agent can hand work to another agent, wait for results, reconcile conflicting information, and keep the overall thread intact. Instead of treating interruptions as failures, it treats them as normal operating conditions—designing for persistence so the workflow remains stable even when the environment is not.

Architecture Implications

The problem statement set up a simple mismatch: enterprises are trying to do long-running, multi-agent work with a session-bound, UX-tethered chat model. That mismatch doesn’t just create awkward user experiences; it creates operational risk - work that can’t reliably continue, actions that aren’t attributable, and systems that don’t scale cleanly beyond demos. Ambient agents are the corrective move, but they only work if the architecture changes with them.

The three defining characteristics of ambient agents - running in the background, collaborating through long-running conversations, and remaining stateful across interruptions - translate directly into non-negotiable architectural requirements. Background operation implies the agent cannot depend on a chat window or a human being present. Long-running, multi-agent collaboration implies a fabric for communication and coordination rather than a single private thread. And statefulness implies the ability to persist progress and recover safely when components restart or fail.

Figure 2, Ambient Agents: Architecture Implications

That’s why the shift to ambient agents drives four core implications: ambient agents must be headless, implemented as distributed services, identity-bearing, and stateful. These are not feature choices; they are the minimum substrate required to make ambient agents operable, governable, and safe at scale. The next sections unpack each implication in turn and show what it demands from real systems, not just prototypes.

Ambient Agents are Headless

Without a UX to lean on, an ambient agent must run on signals, not screens.

Most agent applications today are built around a user interface. A typical example is the chatbot: it appears as a visible interface on a website or app, waits for a user to type something, and responds within that session. The entire interaction is framed by the user’s presence and activity. These agents are interactive but short-lived. They are instantiated when needed and often reset when the session ends. Their behavior is driven by user prompts, and their architecture assumes a live, connected front-end. In contrast, ambient agents are not designed to be seen or interacted with directly. Their architecture must not assume the presence of a UI, nor rely on user-initiated sessions.

Figure 3, Ambient Agents are Headless

Running in the background means that ambient agents must be headless by design. They are not tied to browser windows, mobile apps, or desktop applications. There is no screen to display a menu, no input box for a query, and no ongoing user presence. This separation from the front-end is not a limitation; it is a deliberate design choice. It allows agents to run continuously, independently of whether a human is watching or interacting. Instead of being event-driven by direct user input, they operate based on signals from the environment, other agents, or background data pipelines. The absence of a connected UX requires a different communication model - one that is asynchronous, loosely coupled, and resilient to delays or disconnections.

Despite being headless, ambient agents still need to interact with people. But rather than waiting for direct user input, they monitor for signals that may come from human activity, such as submitted forms, sensor data, business transactions, or command messages. These interactions are not framed as real-time conversations but as discrete events that occur within larger workflows. For instance, a user might upload a file or change a system setting, which then triggers the agent to act. In this model, agents listen for inputs - some from humans, others from machines - but their primary execution path is designed to operate autonomously. Human interaction is just one of many potential inputs, and often not the most frequent one.

This shift has important architectural consequences. The logic that would traditionally reside in the front-end must now be encapsulated in the agent itself or in supporting services. The agent must validate inputs, track progress, and decide next steps without relying on visual cues or real-time clarification. It must also provide feedback in a different way - typically by writing to logs, updating shared state, or triggering downstream actions. The goal is not to eliminate human input altogether, but to make agents robust and useful even when human attention is intermittent. In doing so, ambient agents become infrastructure-like: persistent, reliable, and largely invisible, yet deeply embedded in the flow of work.

Coming back to our earlier example: In fraud remediation, the work cannot depend on a chat window - signals arrive from systems and other agents, and human involvement is intermittent, not continuous.

Ambient Agents are Implemented as Distributed Services

If ambient agents are meant to operate at scale, they can’t be apps — they must be services.

That is why ambient agents are headless. They are services that live behind the scenes, relying on infrastructure that supports asynchronous and programmatic interaction. In practice, this means favoring APIs, message queues, and event buses instead of click-based input mechanisms. Agents publish and consume structured messages, or they interact with RESTful or gRPC endpoints, depending on the task. This design aligns with enterprise integration patterns, but it also supports something more fundamental: agent-to-agent collaboration. If agents are collaborative by design, then their “native language” has to be protocols and messages, not screens and sessions.

Figure 4, Ambient Agents are Distributed

What we are building is distributed computing with a conversational interface and long-lived state. That combination is a very, very difficult problem to solve! The good news is that most of the core problems are known: partial failure, retries, ordering, idempotency, backpressure, and observability have been studied for decades, and there are mature patterns to address them. The bad news is that “known” does not mean “easy.” These are the kinds of problems that only feel solved right up until you try to run them at scale, across teams, across systems, over real time, with real consequences.

Ambient agents are not designed as short-lived processes. Instead, they are long-running services with well-defined lifecycles. Each agent must be deployable, observable, restartable, and updatable without loss of state. This requires infrastructure that supports robust lifecycle management — including start, stop, pause, resume, and upgrade operations. And because ambient agents are designed to run in the background and sustain long-running threads, interruption is not an exception case. It’s normal. The system has to treat restarts, redeployments, and partial outages as routine operating conditions, not as catastrophic failures.

To support large-scale deployment and manageability, ambient agents benefit from containerization technologies such as Docker. Containerization allows agents to be packaged with all their dependencies, ensuring consistent behavior across different environments. In addition, orchestration platforms like Kubernetes can manage these containers, providing fault tolerance, resource scheduling, health checks, and rollout strategies. This ensures agents can be deployed, scaled, and recovered efficiently in dynamic enterprise environments — with the key caveat that “recovered” must include “resumed,” not “restarted and hoped for the best.” The state and the thread have to come back with the process.

Ambient agents must operate across multiple execution environments, including cloud infrastructure, on-premises servers, and edge devices. This distributed nature introduces several architectural challenges. Agents need to tolerate differences in compute resources, network conditions, and local configurations. Moreover, they must be resilient to partial system failures, such as network partitions or temporary unavailability of services. Distributed execution is not a choice but a foundational requirement and it is exactly why the “chatbot” mental model breaks down. A chat session can pretend the world is stable. Distributed services can’t.

In distributed environments where many agents operate concurrently, the system must support multi-tenancy and dynamic workload balancing. This means that different agents, possibly from different business units or use cases, can safely share the same infrastructure without interfering with each other. It also means that workloads should be assigned intelligently across available nodes to optimize resource usage and avoid bottlenecks. This requires runtime awareness of agent activity, health, and resource consumption — and, increasingly, shared conventions for how agents advertise capabilities, invoke tools, and exchange results. This is one of the reasons standards like A2A and MCP are gaining traction: they create a more interoperable baseline for agent collaboration, which makes a service-oriented architecture more feasible outside a single vendor’s ecosystem.

In the same workflow, no single agent can “own” everything; it must coordinate across specialized services (risk scoring, case management, compliance review, notifications) over a shared messaging fabric. That is the day-to-day reality of ambient agents: not a single clever model in a box, but a distributed system of cooperating workers, operating continuously in the background, and staying coherent over time.

Ambient Agents have Identity

Without identity, autonomy becomes a liability.

Every ambient agent must have a unique and persistent identity. This identity remains stable across restarts and redeployments while also allowing for consistent logging, traceability, and accountability. It also enables long-term correlation of agent behavior across time and across tasks. Without a unique identity, it becomes difficult to monitor or audit individual agent activities or apply policy constraints at the agent level.

Figure 5, Ambient Agents have Identity

With a unique identity in place, the next step is authentication and authorization. Each ambient agent must be able to prove its identity to other agents or systems it interacts with. This requires integration with standard enterprise security protocols, such as OAuth2, JWT, or mutual TLS. Once authenticated, agents must be granted access based on their identity and role. This prevents unauthorized behavior and ensures that agents can only perform tasks they are explicitly allowed to carry out.

Beyond basic authentication, agents benefit from a role-based or attribute-based model of access control. An agent acting as an observer may only read telemetry data, while an agent acting as an executor may be allowed to take corrective actions. Policies can be enforced centrally to define what each role is allowed to do, including time-based constraints, data access boundaries, or escalation requirements. Assigning roles to agents simplifies their behavior model and supports safe coordination across fleets.

In most organizations, human users are managed by a centralized identity provider. Ambient agents must follow the same model. By integrating with enterprise IAM systems like Keycloak, Active Directory, or Okta, agents can be provisioned, authenticated, and audited using the same infrastructure already in place for human users. This reduces operational overhead, improves visibility, and aligns with enterprise security policies. It also enables federation, single sign-on, and revocation mechanisms for agent access.

So, when the agent places, for example, an account hold or sends a customer notification, the action must be attributable to a stable, authenticated identity with least-privilege authorization - or the workflow becomes operationally unsafe and unauditable.

Ambient Agents are Stateful

Without durable state, recovery becomes guesswork.

Ambient agents must maintain state across long-running tasks, interruptions, and restarts. This means that agent state must be stored in durable back-end systems such as databases, object stores, or event logs. The state may include task progress, prior decisions, open questions, and intermediate results. Without durable state, an agent cannot resume where it left off after a crash or system restart. State is the foundation for continuity, reliability, and correct behavior over time.

Figure 6, Ambient Agents are Stateful

It is not sufficient for agents to merely store their state. That state must also be observable to operators, debuggers, and supervisors. Engineers need to inspect the current or past state of an agent to understand why it made a particular decision or to diagnose failures. This requires state schemas to be structured, versioned, and queryable. In some cases, audit trails must be recorded for compliance, requiring additional metadata about who initiated a change and when it occurred.

Ambient agents often handle tasks that unfold over hours or days. This requires the architecture to support resumable workflows, timeout handling, and waiting states. Agents may need to wait for external events, human input, or downstream dependencies. Rather than using simple synchronous logic, agents often adopt workflow engines or orchestration frameworks that support checkpoints, retries, and recovery. This ensures that progress is not lost and that multi-step processes can be reliably executed.

Agents must respond to temporal events such as delays, deadlines, and timeouts. They must also be able to recover gracefully after interruptions. This requires infrastructure that can schedule tasks, resume from persisted state, and handle retries without side effects. Recovery logic must be carefully designed so agents do not repeat actions unnecessarily or skip critical steps. All of this increases the reliability and predictability of agent behavior in real-world conditions.

Clearly, if the system restarts halfway through the case, the agent must recover its exact progress and outstanding obligations so it does not repeat irreversible steps (like holds or notices) and can explain the full history end-to-end.

Conclusion

The rise of ambient agents, in my opinion, marks a turning point in how we design and deploy intelligent systems. Moving beyond isolated interactions, these agents operate like background services—always on, quietly observing and acting—while coordinating with other agents over long-running threads. In other words, the center of gravity shifts from “a helpful chat window” to “a distributed fleet that gets real work done.” That shift introduces architectural demands that many teams have been able to postpone: durable state, resumable conversations, stable identity, least-privilege authorization, and the ability to explain what happened after the fact. None of this is science fiction. It is distributed computing, with all the usual failure modes, now carrying responsibility, memory, and side effects.

The challenge is that this is hard in exactly the way distributed systems are hard: the problems are well-known, the patterns exist, and the edge cases still hurt. What changes with ambient agents is the cost of getting it wrong. A timeout is one thing. A repeated irreversible action, a lost audit trail, or two agents diverging silently is something else. If we take the design seriously—grounding it in familiar human patterns of communication, memory, and role-based collaboration, and supporting it with shared protocols for agent-to-agent interaction—we can build systems that are not only intelligent, but resilient, interpretable, and aligned with enterprise workflows that span time, systems, and teams.

As organizations look to take advantage of ambient agents, success will depend on a substrate where state is reliable and visible, conversations are persistent and recoverable, and coordination scales across fleets and ecosystems. Those requirements are already showing up in the market, which is why standards like A2A and MCP are gaining traction: they acknowledge that most agent work will be collaborative, asynchronous, and only occasionally human-facing. My crystal ball is foggy at the best of times, but this direction is no longer speculative. The time to prepare is now. For teams building the next generation of agent ecosystems, the decision to invest in an Agentic Mesh that can support ambient agent collaboration may be one of the most consequential design choices of the decade.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout my latest book with O’Reilly.

***

All images in this document except where otherwise noted have been created by Eric Broda (the author of this article). All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are mine alone and do not necessarily reflect the views of my clients.

From Personal Agents to Enterprise Process Agents (Agentic Process Automation, Part 2)

Agents have advanced to the point where they can participate directly in enterprise work, far beyond the confines of personal productivity. Agentic Process Automation emerges from that shift and introduces a new design model for business processes, in which agents operate as governed process participants with defined roles, bounded capabilities, and accountable outcomes.

Introduction

Agents have advanced to the point where they can participate directly in enterprise work, far beyond personal productivity. That shift changes the design problem. Once an agent moves from assisting one person to operating inside a business process, the enterprise is now ensuring that agent can perform a defined role inside a governed operating model, with controlled access, explicit responsibilities, and measurable outcomes.

That is the context for Agentic Process Automation, or APA. APA extends business process automation into an agentic model in which agents act as real process participants. They classify intake, gather information, apply policy, trigger downstream work, and hand off state to other actors, including both humans and specialized agents.

The immediate driver is actually quite practical: agents are already compressing time spent on software tasks such as scaffolding, refactoring, testing, and routine integration, and that same productivity pattern is now moving into business operations, where the work product is a ticket, a decision, a document, a reconciliation, or a coordinated update across systems.

But while the opportunity is real, so are the architectural challenges. Enterprise work requires role boundaries, failure handling, auditability, and dependable coordination across many actors. Some processes decompose neatly into stages and sub-steps, but others cut across functions, require shared services, or involve exception paths that do not fit a clean hierarchy.

This article explains the overall approach for APA, why personal agents are not sufficient for enterprise execution, why agents should usually map to process responsibilities, how skills define governed capabilities, and why a Knowledge Fabric is required to supply the minimum viable context for execution and improvement.

Personal Agents are not Enterprise Agents

The current agent wave began with chat systems that answered questions, summarized material, and searched. It then moved into tool-using agents that can plan, execute multi-step tasks, verify outputs, and iterate. But most of them are still personal agents, and that distinction matters.

Figure 1, Enterprise Agents and Personal Agents

A personal agent is designed around one user and one workspace. It runs in that user’s identity and credentials. It typically reaches resources through that user’s account, even when those resources are corporate systems. Its operating model assumes continuous interaction: the user prompts, reviews, corrects, and iterates. This is highly effective for individual productivity because it shortens the cycle between idea, execution, feedback, and revision. That is why personal agents feel immediately useful. They improve the throughput of one person working in one work surface or environment.

The enterprise does not scale by multiplying personal work surfaces. Instead, it scales by implementing repeatable capabilities inside business processes.

The unit of adoption is therefore not the individual, rather it is the process.

The unit of accountability is not a user session, rather it is governed service behavior that can be monitored, audited, and improved over time.

An enterprise may benefit from employee-facing personal agents, but that is not the same as making agent behavior part of core operational execution.

That leads to a different kind of agent. Enterprise agents run under service identities, not personal identities. They access enterprise resources through scoped, policy-bound permissions. They operate in the background, respond to requests or events, and do not depend on a constant user interface. A user interface may still be present for approvals, oversight, and exception handling, but the agent itself behaves as a service participant. It enters a process, performs a task, hands off work, and contributes to a measurable business outcome.

Once that shift is made, scale changes the operating model again. Once benefits are seen and experience grow, enterprises will not stop at five or ten agents. They will run hundreds or thousands, or maybe more. Those agents must find each other, collaborate, and in some cases transact. At that point, the problem is no longer how one agent helps one person, instead it is how many specialized agents participate reliably in a multi-step business flow.

This is also where enterprise requirements become materially harder than in a traditional assistant model. A bad permission on a personal agent may expose one user’s workspace. A bad permission on an enterprise agent may expose a shared service or trigger a broad chain of incorrect actions. A weak audit trail in a chatbot is inconvenient. A weak audit trail in a multi-agent process can make root-cause analysis or regulatory review impossible. The move from personal to enterprise agents is a shift from interactive assistance to governed operational behavior.

Agentic Process Agents

The cleanest way to design enterprise agents is to start with the process itself. Business processes are already decomposed into stages, decisions, handoffs, and sub-steps. That structure is often hierarchical. A top-level process such as account opening breaks into major stages such as identity verification, KYC, funding, and notification. Each stage then breaks into smaller operational tasks.

Figure 2, Agentic Process Agents Implement Processes

That existing structure provides a strong blueprint for agent design. Rather than starting with a generic agent and searching for work, the enterprise can map agents directly to process responsibilities.

These agents can be understood as Agentic Process Agents: agents that participate directly in business processes as operational actors, each responsible for a defined unit of work within the larger flow. One agent may own a top-level stage. Other agents may perform narrower steps within that stage.

This design matters because it turns agents into process components rather than loosely attached helpers. An Agentic Process Agent is an executable process participant defined by the work unit it performs, the inputs it accepts, the outputs it produces, and the policies under which it operates. At a higher level, an agent may coordinate a full stage such as identity verification. At a lower level, other agents may gather documents, validate document quality, verify identity attributes, and confirm the result before handing off to the next stage.

A bank account opening flow makes the model more concrete. The top-level process receives an application and must produce either an opened account, a rejection, or a request for review. Within that process, an identity stage may itself break into document collection, document verification, identity matching, and confirmation. A stage-level agent can coordinate those steps, but it should not be forced to perform each one as an opaque monolith. A document verification agent can focus on file completeness and authenticity checks. An identity matching agent can evaluate whether the supplied evidence matches declared attributes. A confirmation agent can decide whether the identity stage is complete or whether the case should escalate. Each agent has a narrow role, and the combined result becomes the stage output consumed by the next step in the process.

In that model, the process hierarchy becomes the agent hierarchy. Some agents are shared services that cut across multiple processes and become reusable participants invoked from multiple flows. APA therefore should not be read as a rigid rule that every agent must fit a strict hierarchy. The hierarchy is a useful design default for bounded work. Cross-process service agents still fit the model as long as their role, interface, and authority are explicit.

This is also the point where enterprise-grade requirements become non-negotiable. Security matters because an agent can amplify the blast radius of a bad permission model. Observability matters because distributed process failures must be diagnosable end to end. Discoverability matters because large fleets need a catalog of capabilities, interfaces, owners, and constraints. Reliability, durable state, explainability, and long-running interaction handling all become part of the minimum design baseline. These are the operational requirements of treating Agentic Process Agents as governed participants in business execution.

Skills Define Capabilities While Agents Execute the Process

Process mapping defines where an agent fits. A second design layer defines what that agent is actually allowed and able to do.

Figure 4, Agents and Skills Implement Processes

A skill is a formal specification of a bounded capability. It defines the task, required inputs, applicable rules, expected outputs, and the conditions under which execution succeeds, fails, or escalates. In practice, a skill is the executable contract behind a process step. The agent is the runtime actor. The skill is the declared capability used by that actor to perform governed work.

This distinction is essential because enterprises do not want opaque generalists with unclear boundaries. They want agents assembled from explicit, reusable capabilities that can be reviewed, tested, versioned, and audited. A higher-level process agent may coordinate a business stage, but the work itself is carried out through narrower skills such as identity verification, document validation, exception handling, policy evaluation, or confirmation.

A useful skill specification is concrete. At minimum, it should identify the skill name and purpose, required inputs, optional inputs, preconditions, decision rules, output schema, failure modes, escalation criteria, and required evidence or logs. In the identity stage of account opening, a “verify identity” skill might require applicant identifiers, declared attributes, and one or more identity documents. It may apply rules such as minimum document count, acceptable document types, freshness thresholds, match tolerances, and policy gates for manual review. Its output should not be vague prose. It should return a structured result such as “approved”, “rejected”, or “needs review,” together with confidence signals, reason codes, extracted evidence references, and any downstream obligations.

Policy binding is where the skill becomes enterprise-grade. A skill should not only encode what can be done; it should also encode under what constraints it may proceed. A document-confirmation skill, for example, may be allowed to auto-approve only if all required fields are present, the documents are within validity windows, and no sanctions or fraud flags are active. If a threshold is missed, the failure path should be explicit: reject, request additional information, or escalate to a human reviewer. This is the difference between a capability description and an operational contract.

That separation produces a clean operating model. Agents implement process roles. Skills implement bounded capabilities. The same skill can then be reused across multiple processes without redefining the agent.

The skills layer also changes process design, but this point should be made precisely. APA still uses bounded process structures, but the runtime path can be more adaptive within those bounds. A stage agent may select among approved skills, invoke a shared service, or route to a review path based on current state.

That does not mean unlimited autonomy. It means governed traversal through a defined execution graph: the enterprise pre-approves the reachable states, the permitted collaborators, and the escalation paths, while runtime conditions determine which branch is taken. This is the architectural difference between a brittle fixed sequence and a controlled adaptive flow.

Trust Requires Know Your Agent

Once agents become embedded in real business processes, the enterprise needs a management discipline for them. That is the role of Know Your Agent, or KYA.

KYA is the agent equivalent of employee governance. Enterprises already know how to manage humans in operational roles: verify identity, define responsibility, grant access, train for policy, evaluate performance, and investigate incidents. The same logic applies to agents, but the controls must be expressed in system terms rather than managerial terms.

In practice, KYA includes verifiable identity, declared ownership, scoped permissions, approved tool access, policy binding, evaluation criteria, deployment controls, monitoring, and traceability. This is what turns an agent from an interesting automation artifact into an accountable enterprise actor. Without that discipline, the enterprise has capability without control. With it, the enterprise can define which agent may do what, under which conditions, with what evidence, and with what audit trail.

KYA also clarifies that trust is not a vague sentiment. In enterprise systems, trust is engineered. It is established through bounded access, enforced policies, observable execution, measurable quality, and the ability to reconstruct what happened. That framing matters because enterprise adoption will depend less on novelty and more on whether the agent can be governed as rigorously as any other operational component.

This is also where failure handling must be treated directly. Multi-agent business processes will fail in the middle of execution. A document check may time out. A downstream service may reject a request. A human approval may arrive too late. If the process includes state changes across systems, the design must support compensation, rollback, or controlled partial completion. Traditional BPM already has patterns for this, including sagas and compensating actions. APA does not replace those patterns. It uses them, but applies them to agents as active participants in the flow. A stage agent that initiates an access request may also need a defined compensating skill to revoke that request if a later compliance check fails. A payment-approval path may reserve funds first, then release them if the approval chain does not complete. KYA matters here because the enterprise must know which agent is authorized to perform both the forward action and the compensating action, and under what evidence threshold.

The Agentic Knowledge Fabric

Even well-scoped agents with well-defined skills still need the right context at the right moment. That is the role of the Knowledge Fabric.

Figure 5, Agentic Knowledge Fabric

The Agentic Knowledge Fabric is the knowledge layer behind APA. It sits beneath the process layer and the capability layer and supports the full lifecycle of agent execution. It ingests fragmented enterprise sources such as documents, data systems, communications, procedures, regulations, and subject-matter expertise. It then converts that material into reusable knowledge assets that agents can consume: concepts, policies, constraints, decision criteria, and other context components.

The Knowledge Fabric makes context delivery operational by compiling reusable knowledge assets into the minimum viable context needed for a specific task, sized for the agent’s context window and aligned to the exact responsibility being executed. That means the agent does not receive a raw corpus or a loose retrieval result. It receives a curated working context assembled for that step.

Minimum viable context is the most important operating idea in this layer. “Minimum” does not mean minimal in an abstract sense. It means sufficient and bounded: enough information to execute the current task correctly, but not so much that the agent is overloaded with irrelevant material, conflicting policy fragments, or stale evidence. The context compiler therefore should consider at least four filters: task relevance, policy criticality, source authority, and token budget. Task relevance determines which facts and policies apply to the immediate step. Policy criticality ensures that thresholds, constraints, exceptions, and mandatory review rules are given priority over descriptive background. Source authority resolves which source wins when materials conflict; for example, an approved policy document should outrank an outdated chat summary. Token budget constrains the final assembly so that the most important material survives and the rest remains referenceable but out of the active window.

This is what allows APA to operate on real enterprise work. Most business tasks arrive with ambiguity. Inputs may be emails, PDFs, chats, ticket histories, incomplete requests, or conflicting evidence. The agent must interpret them, combine them with policy and process context, and then produce structured outputs that downstream systems can use. Without a disciplined knowledge layer, the agent either receives too little context and makes weak decisions, or too much context and becomes noisy, slow, and error-prone.

The Knowledge Fabric also closes the feedback loop. After execution, outputs can be compared against expected outcomes, checked for drift or gaps, and fed back into the same knowledge layer to improve future context assembly. If agents repeatedly escalate a specific case type, that may indicate a missing policy card, a weak concept definition, or an unresolved source conflict. If one source consistently generates low-quality context, its ranking or extraction method can be revised. This is how the system improves without turning every failure into an ad hoc prompt edit.

Conclusion

APA should be understood as an enterprise operating model for agent-based work, not as a thin extension of personal-agent productivity. Personal agents prove that the technology can generate useful output. Enterprise execution requires more: process roles, bounded capabilities, trust controls, durable coordination, and source-grounded context.

The design logic is direct. Start with the process and define where agent participation is valuable. Map agents to operational roles, while allowing shared service agents to cross process boundaries where that is the better design. Use skills to define explicit capabilities, including success, failure, and escalation conditions. Apply KYA to make those agents governable and accountable. Support execution with a Knowledge Fabric that compiles the minimum viable context for each step and improves through feedback. That combination does not remove the hard parts of business automation. It addresses them with a model built for intelligent, distributed process participants.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn. Questions and comments are welcome and encouraged!

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

The hard problem isn’t building smarter agents; rather, if we are going to have hundreds, thousands, or maybe millions of agents in each enterprise, then it’s about building the social infrastructure for trust at-scale; it’s about making the entire agent ecosystem and the agents in them transparent, auditable, certifiable – and trusted.

Introduction

The agent story we have been selling ourselves is pretty darn compelling: software that can reason, coordinate, and execute work with the quiet precision of your smartest fellow worker. The promise is not just efficiency. It is agents that are always-on, always listening, and always working. But in practice, there is a gate every enterprise will eventually hit, and it is not model quality, intelligence, or even token costs. Rather, it is trust.

Trust is the price of admission in the agent ecosystem.

Today, most organizations still live in a familiar pattern: data flows in, analysts and systems derive insights, and then people decide what to do. The distance between insight and action is deliberately long, routed through meetings, approvals, second opinions, and the quiet friction of accountability. That friction is not a bug; it is the mechanism that keeps intent from becoming irreversible execution without scrutiny.

Tomorrow, agents collapse that distance. They will not just analyze data and surface recommendations; they will take action - calling APIs, triggering workflows, moving money, changing configurations, messaging customers, delegating work to other agents. The path from intent to execution becomes dramatically shorter, and therefore dramatically riskier. If an enterprise expects thousands - or eventually millions - of these actors operating continuously, trust can’t be something you infer from a good demo or a pilot that didn’t blow up. It has to be infrastructure: verifiable, auditable, and certifiable.

This article lays out Agentic Mesh’s seven-layer trust framework - best understood as a stack - from identity at the foundation to governance at the top. We walk through each layer and show how, together, they turn trust into something operational: purpose plus proof, trust in the ecosystem (not just the agent), and federated trust that can survive scale across teams, vendors, and organizations.

Trust Themes

The argument of this article rests on three themes that reinforce one another. The first defines what it means to trust an agent in practical terms. The second raises the level of abstraction: trust cannot be limited to the agent, because agents only matter inside an ecosystem that must itself be trustworthy. The third addresses the inevitable reality of scale: if enterprises really deploy thousands or millions of agents, trust cannot be handcrafted or centralized - it has to be federated, repeatable, and portable.

Figure 1: Agentic Mesh Trust Themes

Theme #1: Trust is purpose plus proof

A trusted agent is one that fulfills a defined and transparent purpose and demonstrably adheres to its purpose and policies - no more and no less. That definition is intentionally narrower than “a capable agent,” because capability is not the same thing as reliability. In production, trust is not a feeling generated by a good conversation or a reassuring answer; it is the ability to point to concrete evidence that the agent stayed within bounds.

The emphasis on “demonstrably” changes how systems must be built. It pushes purpose and policy out of informal prompts and into durable declarations, tied to identity and enforced through controls. It pushes execution out of the shadows and into visibility - plans that can be inspected, permissions that can be verified and revoked, and traces that can be audited. In other words, purpose is the claim; proof is the mechanism that makes the claim believable at enterprise risk levels.

Theme #2: Trust in agents isn’t enough; we must trust the ecosystem

Even if you could certify that a single agent behaves correctly, that does not automatically make an enterprise comfortable deploying it at scale. Organizations do not run on individual trust alone. They rely on institutions - roles, supervision, escalation, audit, and accountability - because those structures make behavior legible and enforceable across large populations of people. The same is true for agents: they inherit both their power and their risk from the environment they operate in.

So “trust in the ecosystem” means believing the surrounding system is governed, and therefore capable of enforcing rules consistently. It means the ecosystem is transparent enough to understand what agents are supposed to do, observable enough to see what they are doing, explainable enough to justify why decisions were made, and auditable enough to reconstruct events when something goes wrong. Most importantly, it means accountability exists: someone owns the agent, someone owns the policies, and the system has mechanisms to quarantine, revoke, or retire an agent when trust is violated.

Theme #3: Trust at scale must be federated

The moment you move from a handful of agents to hundreds, thousands - or millions - the trust problem changes category. You cannot inspect everything manually, and you cannot rely on one central authority to vet every agent across every department, vendor, and jurisdiction. Trust has to become repeatable and portable: evidence that holds up when an agent crosses boundaries, and verification that does not depend on trusting the original builder.

This is where federation becomes the foundation rather than a nice-to-have. Industrial societies solved “trust at scale” long before software agents by building standards-based regimes: UL and CSA certify products through shared standards, accreditation (delegating authority to certify), and attestation (verifiable claims that travel with the product). The agent ecosystem needs the software equivalent - standards for identity, roles, policies, evidence, and certification - so trust can move across organizations without collapsing into bespoke negotiation. Federation is how you turn autonomy from a local experiment into infrastructure that can safely scale.

The Agentic Mesh Trust Framework

Soon we will see thousands - or even millions - of agents inside a single enterprise, as many industry leaders now predict. At that scale, the familiar safety blanket of “human-in-the-loop” stops being a control strategy and becomes a bottleneck: you can’t approve, review, or second-guess every action without erasing the very autonomy you deployed agents to achieve.

From a practical perspective the operating model probably needs to change. Humans move “above the loop” - defining purpose and policy up front, supervising through evidence, and stepping in only when the system flags uncertainty, exception, or drift. But that shift only works if trust stops being a sense or feeling you get from a good demo and becomes a capability you can verify. In production, trust is the price of admission to the enterprise agent ecosystem.

So, it is probably not very surprising that the conversation about agents keeps coming back to the same question: what does it mean to trust an agent? For people, trust is often social and intuitive. We read tone. We infer intent. We intuitively understand credibility. We grant trust gradually, with context, reputation, and norms acting as scaffolding. Organizations make this workable because they surround people with structure: roles, supervision, escalation paths, audit trails, and consequences. Trust is never just a judgment about a person; it is also a judgment about the institution behind them.

Agents are different. If you are a ChatGPT user (with 800 million weekly users, you probably are) then you know that agents (and large language models) can be capable without being very accountable, helpful without being terribly constrained, and persuasive while sometimes being wrong. And they operate at machine speed - meaning a small lapse becomes a large incident quickly.

A trusted agent, then, must be something more specific than a “good” or “smart” agent: it is one that fulfills a defined and transparent purpose and demonstrably adheres to its purpose and policies - no more and no less. The key word is demonstrably. In an enterprise context, trust is evidence, produced by systems that are transparent, observable, explainable, and auditable.

That is why trust becomes an ecosystem problem the moment you aim for scale. If enterprises are going to run thousands, or even millions, of agents, trust can’t be hand-crafted or bespoke and it definitely can’t be centralized. It must be repeatable, portable, and federated.

Building a trust ecosystem at that scale is hard - but it is not unprecedented: in the physical world, organizations like Underwriters Laboratories have already built federated systems that let millions of products be trusted without being personally re-checked every time they change hands. In fact, Underwriters Laboratories began as a practical response to a new kind of danger: electricity spreading into American buildings faster than anyone could confidently say it was safe. Fire insurers weren’t chasing philosophical certainty; they were trying to stop losses in a world where a bad wire, a cheap insulator, or a poorly built device could turn a building into fire hazards. UL’s insight was not “we will inspect everything forever,” but “we will make safety legible” using test methods, published standards, certification marks, and a system of evaluation that could travel with a product from factory to job site to insurer’s ledger.

Agents need the software equivalent of the UL trust ecosystem - not a one-time security review or a heroic central team that “knows” which agents are safe, but a trust approach that scales with adoption and survives vendor boundaries. In practice that means shared, checkable artifacts: identity and provenance that can be verified automatically; declared capabilities and policy constraints that are machine-readable; standardized evaluations for behavior, safety, and reliability; and attestations that can be issued, audited, and revoked as models and tools change. The point of our UL analogy is that trust becomes a property of the system, not the personality of the product. When an agent moves across teams, vendors, and organizations, its trust should move with it - carried by certifications, logs, and enforceable contracts the way a safety listing travels with a device - so the agent ecosystem can adopt quickly without pretending the risks are gone.

Agentic Mesh’s Trust Framework provides that structure. It is a seven-layer model - best understood as a stack - that builds from identity at the foundation to governance at the top, separating concerns so trust can be engineered, verified, and certified. The first layers establish who an agent is and what it is allowed to do; the middle layers make behavior explainable and observable; and the top layers make trust portable across ecosystems through certification and governance. In the sections that follow, we walk through each layer and show how the stack, taken together, makes trust at scale possible.

Figure 2: Agentic Mesh Trust Framework

Layer 1: Identity and Authentication

Every trust system begins with a basic premise: you cannot trust what you cannot identify.

In human life, identity is so routine we forget how much it carries. A passport, a driver’s license, an employee badge - these aren’t status symbols. Instead, they are anchors for accountability. They let a system say, with confidence, this is who you are, which is what makes it possible to decide what you’re allowed to do, what responsibilities you carry, and what happens if you violate expectations.

Agents need the same anchor. If an agent is merely “some process running somewhere,” every higher control becomes fragile. Authorization becomes guesswork. Audit trails become questionable. Blame becomes diffuse. And in a multi-party ecosystem, impersonation becomes cheap. You can’t build serious oversight on top of a participant whose identity is fuzzy.

So, identity for agents must be verifiable, not declarative. In practice that means cryptographic identity: keys, certificates, signed assertions, and mutual authentication between parties. Mutual TLS is the simplest intuitive model - the agent proves itself to the service, and the service proves itself to the agent - so both sides can confirm they’re talking to who they think they’re talking to. That isn’t a fancy feature; it’s the starting line.

Identity is also lifecycle. For people, identity documents expire, get renewed, and can be revoked. In a serious system, agents need the same discipline: keys rotate, certificates expire, compromised credentials are revoked, and decommissioned agents lose the ability to authenticate. This matters because agents are not static. They get replicated, scaled up and down, rebuilt, and redeployed. Identity has to be stable without becoming sloppy - or worse, permanent.

This is where the definition of trust stops being abstract and becomes operational: trust is purpose plus proof, and identity is the “who” attached to the proof (Theme 1). Without identity, you don’t have the basic foundation for trust.

And identity is also where trust at scale starts to become real. In a world of millions of agents, you won’t have one global registry that everyone uses; we expect to see multiple trust domains - enterprises, vendors, clouds, consortiums - each with their own identity roots. The obvious challenge is to make it interoperable and governed, so identity can be verified across boundaries without collapsing into one-off exceptions (Theme 3).

Layer 2: Authorization and Access Control

Once you can reliably say who an agent is, the next question is plain: what is it allowed to do?

For people, we accept authorization systems as normal. Job roles. Department boundaries. Approvals. Separation of duties. You can be trusted as a person and still not be trusted with payroll. That is not an insult. That is governance.

Agents require a stricter version of the same logic, because agents can act at machine speed, and their mistakes can propagate faster than a human can intervene. The default posture must be zero trust: never trust, always verify.

In practical terms, authorization is how purpose becomes enforceable. It is the guardrail that turns “this agent is supposed to do X” into “this agent can only do the actions required to do X.” Tokens with scopes. Role-based and attribute-based access control. Policy decision points that evaluate context. These are implementation choices, but the underlying principle is constant: least privilege, continuously verified.

Just as important, authorization should often be short-lived by design. In many workflows, the safest permission is not a standing entitlement but a narrow, time-bound grant: a token that expires quickly, a one-time approval to execute a specific step, or a scoped credential that is valid only for the duration of a task. This is how you prevent permission drift - where agents quietly accumulate access because it was convenient - and how you keep autonomy from turning into permanent privilege.

It is tempting to give agents broad access “so they can be helpful.” That temptation is the fastest route to incidents. Helpful is not the goal. Governable is the goal. Agents should begin in a sandboxed state with minimal permissions and must earn additional scope through explicit grants that are justified by their role and purpose - and, where possible, those grants should be temporary and revocable without drama.

This is one of the cleanest places where “trust is purpose plus proof” becomes concrete: authorization is part of the proof (Theme 1). If an agent cannot access what it is not allowed to access, then policy violations shrink from catastrophic to inconvenient.

And it’s also where you see why trusting the agent is never enough. Access control is a property of the ecosystem, not the agent alone (Theme 2). The strongest intentions are meaningless if the surrounding system cannot enforce permissions. In human organizations, policies are only real when they can be enforced - by managers, auditors, or systems. In agent ecosystems, enforcement has to be automated, consistent, and logged.

Layer 3: Purpose and Policies

Identity tells you who the agent is. Authorization tells you what it can do. Purpose and policies tell you what it is supposed to do - and what it must never do - even if it technically could.

This layer is often misunderstood because it sounds like documentation. It is not. Purpose and policies are the agent’s charter: the terms under which the ecosystem agrees to let the agent exist, and the benchmark the ecosystem will later use to judge whether the agent stayed in bounds.

For people, we separate capability from responsibility all the time. A person may be capable of making a decision, but policy may require escalation. A person may have access to information, but policy may forbid using it in certain contexts. A person may be authorized to spend money, but policy may require two signatures above a threshold. These are governance constructs that can’t be reduced to “permissions,” because they’re really about intent, accountability, and acceptable behavior - not just access.

Agents need the same structure, but more explicit. Their purpose should be stated plainly and operationally, in language humans can review and machines can apply. Not “improve customer experience,” but “draft customer support responses using approved knowledge base articles; never send directly to customers; flag uncertain answers for review.” When purpose is vague, trust collapses into interpretation. When purpose is clear, trust becomes testable.

Policies are the constraints that operationalize that purpose. They define boundaries around truthfulness (“do not invent facts”), action (“do not execute transactions without approval”), data (“never store raw PII”), and behavior (“do not attempt to bypass access controls”). The crucial move is that these policies are explicit and durable. They are not hidden in prompts. They are not informal conventions. They are part of what the ecosystem can audit, enforce, and ultimately certify.

This is the spine of “trust is purpose plus proof” (Theme 1). Purpose and policy are the claim; everything else in the stack exists to make adherence demonstrable - so violations can be detected, explained, and acted on, rather than argued about after the fact.

And this layer quietly determines whether trust can scale. If agents from different organizations are going to collaborate, purpose and policy declarations can’t be private dialects; they need standardized shapes and shared vocabularies (Theme 3). In a federated world, interoperability isn’t just about APIs - it’s about common expectations that can be verified across boundaries without constant negotiation.

Layer 4: Task Planning and Explainability

An agent can be authenticated, scoped, and policy-bound - and still behave in ways that make enterprises nervous. The missing piece is often not control but understanding.

Layer 4 is where the black box begins to open. Not by exposing every internal thought, but by making the agent’s work legible: what plan it formed, what steps it intended to take, what tools it chose, what data it relied on, what assumptions it made, and what it did when uncertainty appeared.

In human organizations, explainability is an expectation, not a luxury. A junior analyst can’t just deliver a number; they have to explain where it came from. A manager can’t just say “do it”; they have to justify the decision when asked. Explainability is how accountability becomes practical, because accountability requires reasons, not just outcomes.

Agents need an analogous standard. A plan is a contract with the future. It lets operators see what the agent is about to do before it does it, and it lets auditors reconstruct what it intended to do after the fact. Just as importantly, it creates a natural surface for enforcement: “This step violates policy X,” “This tool requires additional authorization,” “This action should be escalated,” or “This output needs human review.”

This is also where trust becomes safer in a subtle way: explainability reduces surprises. Surprises are what kill adoption. Enterprises will tolerate occasional errors; they will not tolerate opaque errors that cannot be explained, reproduced, or bounded. When an agent can show its plan and rationale, failures become diagnosable events instead of unsettling mysteries.

This is the point where trusting the agent as a standalone actor clearly isn’t enough. You also have to trust the system around it - the ecosystem that records plans, enforces gates, and makes decisions reviewable (Theme 2). If the ecosystem cannot explain why an agent did what it did, governance becomes theatre: rules exist on paper, but accountability collapses in practice.

And at scale, explainability stops being just transparency and becomes coordination. In multi-agent workflows, plans are how agents align expectations, avoid duplicate work, and hand off tasks without improvising themselves into conflict. Planning is not just how an agent “shows its work”; it is the social order that makes large fleets of agents manageable (Theme 3).

Layer 5: Observability and Traceability

Layer 4 is about what the agent says it will do and why. Layer 5 is about what it actually did, when, and in relation to everything else.

Trust is not sustained by intentions. It is sustained by evidence.

Observability is the discipline of instrumenting a system so its behavior can be monitored and understood. Traceability is the discipline of connecting events into coherent narratives: this action belonged to this task, which was triggered by this request, which delegated to these agents, which invoked these tools, which produced these artifacts. Without that connective tissue, you don’t have a system you can manage - you have activity you can’t explain.

In an agent ecosystem, traceability is not optional. Agents work asynchronously. They delegate. They retry. They communicate and collaborate across boundaries. Without strong correlation identifiers - task IDs, conversation IDs, step IDs - you get a fog of logs that cannot tell a story. And if you can’t tell the story, you can’t debug. You can’t audit. You can’t certify. The difference between a minor incident and an existential loss of confidence is often nothing more than whether you can reconstruct what happened.

For people, organizations create traceability naturally: email threads, ticketing systems, approvals, meeting notes, audit logs, and records management systems. Those artifacts are sometimes messy, but they exist. For agents, we have to build traceability deliberately, because the system will otherwise move too fast to reconstruct - and because agents don’t leave “paper trails” unless the ecosystem forces them to.

This is where “purpose plus proof” stops being rhetoric and becomes operational (Theme 1). Demonstration requires records, and records require observability. If you can’t show what an agent did, you can’t claim it behaved - even if the outcome looked fine.

This is also where trust in the ecosystem becomes tangible. Trusting the ecosystem means trusting that it captures reality faithfully: tamper-resistant logs, consistent schemas, clear retention, and the ability to reconstruct events under pressure during incident response (Theme 2). It’s the difference between “we think the agent behaved” and “we can prove the agent behaved.”

And at scale, observability is how trust stays alive over time. Drift happens. Policies evolve. Threats change. Without monitoring, you don’t notice drift until it becomes a breach. Observability turns trust into a living discipline - continuously assessed, continuously reinforced - which is the only version of trust that survives large fleets of agents operating across organizations (Theme 3).

Layer 6: Certification and Compliance

Now we reach the point where the trust stack stops being purely internal and becomes an external signal.

Enterprises do not only want to know that they have controls. They want to know those controls have been evaluated against a standard, in a repeatable way, with evidence. That is certification: not a claim of safety, but a structured basis for believing it.

This is where Underwriters Laboratories and the Canadian Standards Association stop being metaphors and start being models. UL and CSA scaled trust by creating standards and processes that could be applied across millions of products. They did not personally inspect every toaster forever. They created a system of standards, accredited labs, and certification marks backed by auditing and enforcement. That is federation in action: trust is defined centrally in principle but is executed in a distributed fashion in practice.

Agent ecosystems need the same structure.

Certification for agents means structured evaluation against declared purpose, policies, and operational constraints. You test the agent under expected conditions and adversarial conditions. You verify it stays within authorization bounds. You inspect trace data. You review whether its planning and explainability meet required thresholds. You assess resilience: how it behaves when it cannot access required resources, when prompts are ambiguous, when data is missing, when policies conflict. Certification turns “we think it’s safe” into “we have evidence it behaves within its contract.”

Compliance is the bridge between technical control and organizational obligation. Enterprises are governed by laws, regulations, and internal policies - privacy rules, financial controls, safety standards, industry constraints. Certification becomes meaningful when it can be tied to those obligations in plain terms: “This agent is certified to handle this class of data,” “This agent is certified for this regulated workflow,” or “This agent is not certified to operate without human approval.” That is what makes certification actionable in procurement, deployment, and audit.

This is the layer where federated trust becomes unavoidable (Theme 3). If you want thousands - eventually millions - of agents, you cannot have one committee certifying every agent by hand. You need standards. You need accredited certifiers: delegated groups that can certify within defined scopes. And you need attestation: machine-readable evidence that the agent is certified, by whom, for what, and until when - so other systems can verify trust without personal relationships.

Finally, certification cannot be a one-time sticker. Agents evolve: they gain tools, change prompts, update models, shift configurations. Certification has to be version-aware and event-driven. Significant changes trigger recertification. Violations trigger suspension or revocation. In the physical world we call this recalls; in agent ecosystems, it is simply the minimum discipline required to keep trust intact once autonomy is deployed.

Layer 7: Governance and Lifecycle Management

If certification is the trust signal, governance is the trust engine that keeps the signal meaningful over time.

This layer answers the question that most enterprises are really asking, even when they phrase it differently: who is accountable?

In human organizations, trust depends on governance structures: managers, compliance officers, audit committees, regulatory frameworks, and processes for escalation and discipline. People may be competent, but the organization is trusted because it can detect problems, respond to incidents, enforce standards, and improve itself over time. The institution is what turns individual competence into something society is willing to rely on.

Agent ecosystems require the same institutional backbone. Governance defines the rules and the mechanisms for enforcing them. It defines ownership - every agent must have an accountable owner. It defines change control - what kinds of modifications require review and recertification. It defines incident response - how to quarantine an agent, revoke credentials, roll back access, and investigate behavior. And it defines lifecycle - how agents are onboarded, operated, updated, recertified, and retired - so that trust survives contact with reality and time.

This is where trust in the ecosystem gets its fullest meaning. Trust in an organization - or in an agent ecosystem - is not the belief that participants are well-intentioned; it’s the belief that the system is governed under applicable rules and laws, that its controls are transparent, that behavior is auditable, that accountability is enforceable, and that the ecosystem can correct itself when it fails (Theme 2). Without that machinery, “trust” becomes a marketing word, because there is no credible consequence for violating it.

Governance is also where federation stops being theory and becomes operating practice. In a multi-party ecosystem, there is no single sovereign authority. You may have consortium standards. You may have regulatory overlays. You may have mutual recognition agreements - “we recognize certifications issued by these accredited bodies under these conditions” - that let trust cross organizational borders without collapsing into one-off negotiations (Theme 3). This is how industrial trust scales. It is how international trade functions. It is how the web works. And it is how large-scale agent ecosystems will have to work.

Lifecycle management matters because trust is most vulnerable at transitions. Onboarding is where misconfigurations slip in. Updates are where drift enters. Decommissioning is where zombie agents appear - credentials that still work after the agent is supposedly gone. A governed lifecycle makes trust durable by ensuring that identity, access, observability, certification, and accountability survive change, not just steady state.

Conclusion

The agent future will not be decided by model quality, “intelligence,” cost, or speed alone. It will be decided by whether enterprises can justify trust - first in individual agents, and then in the ecosystems those agents run in. That is what Agentic Mesh’s seven-layer trust framework is really doing: turning trust from a sentiment into a framework, or stack, built from identity at the bottom to governance at the top, so agents can be deployed with confidence.

At the agent level, the standard is simple and unforgiving: trust is purpose plus proof (Theme 1). A trusted agent is not one that sounds smart; it is one that fulfills a defined and transparent purpose and demonstrably adheres to its purpose and policies - no more and no less. “Demonstrably” means identity that can be verified, access that is scoped and often short-lived, behavior that is explainable through plans and rationale, and actions that are observable and traceable through auditable records.

But even perfect agent-level controls won’t carry the day if the surrounding system cannot be trusted (Theme 2). Enterprises rely on aviation, finance, and healthcare not because every participant is flawless, but because the ecosystems are governed: transparent enough to inspect, observable enough to monitor, auditable enough to reconstruct, and accountable enough to correct.

And because scale is the point, trust cannot remain bespoke or centralized (Theme 3). If we truly expect millions of agents across teams, vendors, and jurisdictions, trust at scale must be federated - standards, accredited certifiers, and machine-verifiable attestations that travel across boundaries, the way UL and CSA made safety legible across industrial supply chains. Without that scaffolding, the agent ecosystem stays a risk story; with it, the agent ecosystem becomes powerful and reliable infrastructure.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn. Questions and comments are welcome and encouraged!

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout an upcoming book, “Agentic Mesh”, with O’Reilly, and soon on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Coding agents have compressed the plan–build–test loop and made iteration dramatically faster and cheaper. The harder question is how to bring integrate Enterprise Agents – agents embedded in business processes – and apply the lessons from coding agents to accelerate business processes.

Introduction

On Feb 2, 2025, Andrej Karpathy tweeted: “There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good.”

That tweet captured a moment: a new, faster way of building software had become visible to everyone at once. What began as an improvisational style of prompting quickly matured into something more durable: coding agents. Today’s coding agents are integrated development tools that can read and modify large codebases, run tests, follow repository conventions, explain diffs, and operate inside the same feedback loops that make professional engineering work reliable.

Coding agents are changing day-to-day software engineering by shortening time-to-feedback and lowering the cost of iteration, and they’re quickly becoming part of the standard enterprise development toolchain. But enterprise agents are different: coding agents live inside an assistive loop with tight feedback (tests, review, rollback), while enterprise agents operate inside systems-of-record workflows where actions must be permissioned, auditable, and defensible, so scale, governance, security, and reliability become first-order requirements.

Coding Agents Supercharge Software Engineering

A year ago, it was already normal to ask an assistant for help. Now a different posture has emerged in the most advanced software engineering shops: developers increasingly iterate between planning and specification in English, then use coding agents to build code and initiate testing, run what was produced, and iterate (including going back to restating specifications in the plan and reviewing code based with this new knowledge and trying again). When it works, and it often does, it feels like design and implementation collapsing into the same tight loop iterating faster than human comprehension of the code produced!

The tangible benefit is speed: faster iterations, shorter time to feedback, and less friction moving from an idea to a software product. This is especially powerful at the start of a project, where the bottleneck is usually inertia. Tools such as Claude Code from Anthropic or OpenAI’s Codex push this further by giving developers a terminal-native agent that can edit files, run tests, and chain tool calls, making it plausible for a small team to ship a surprisingly capable prototype quickly. Case in point, 100% of Claude CoWork was created using Claude Code.

A common coding-agent pattern looks like this: a small team, bounded scope, and an iterative loop driven by a spec. The developer states a goal in model-friendly terms, requests an implementation, runs tests, refines the spec, and repeats. The codebase itself serves as a coherent corpus; the “right” code segments become the context. This works because artifacts are versioned, tests define success, and a human adjudicates trade-offs. The result: less time spent on syntax and scaffolding, and more on shaping behavior, product boundaries, and user outcomes.

Growing Pains are Real, but Rapidly Getting Better

Like all powerful tools, coding agents come with risks. The most visible one is the temptation to accept output that “looks right” without doing the work of understanding it. That risk shows up in many forms, including low-quality or overly verbose changes that clutter a codebase, pull requests that read like machine-generated filler, and small correctness issues that slip past casual review. You can think of this as a modern version of an old problem: copying code you don’t fully understand, now at higher volume and speed.

The key point is that these are growing pains, not indictments. They are the predictable side effects of a step-change in leverage. In experienced hands, coding agents amplify judgment: they compress time spent on routine work and expand time available for architecture, careful review, testing strategy, and design. In inexperienced hands, they can amplify overconfidence. That difference is not new to software; it is simply more pronounced when the tool can produce a lot of plausible output quickly.

This is why enterprises should not treat coding agents as a casual add-on. They should treat them as a capability that requires training, norms, and process. The goal is not to slow teams down; it is to make sure speed compounds rather than decays into maintenance debt.

Apprenticeship, Updated for the Agent Era

For enterprises, we think the right posture is adoption with structure. Coding agents absolutely belong in the toolchain, but the developer operating model needs to evolve around them. The most practical model is apprenticeship-like training for enterprise developers: explicit progression from assisted work to independent judgment, with review gates, shared standards, and clear expectations about verification.

In an apprenticeship model, early-career developers use coding agents as scaffolding while they learn the craft: reading code, tracing execution, understanding failure modes, and writing tests that genuinely constrain behavior. More senior developers model what “good” looks like in the agent era: using agents to accelerate exploration, insisting on small and reviewable diffs, demanding tests that encode intent, and treating unclear changes as a prompt to ask better questions rather than merge faster.

This training is all about professional software engineering discipline: matching existing engineering patterns to appropriate challenges, the right architectural abstractions on key components, clarity of requirements, testing harnesses and test-driven design, code review norms (and agentic assistance). Done well, enterprises get real productivity gains.

From Coding Agents to Enterprise Agents

If coding agents can accelerate software engineering dramatically, why not apply the same lessons to enterprise agents capable of business operations? Why shouldn’t a bank, insurer, or logistics accelerate operations? The opportunity is real.

Coding agents operate in a world where the primary artifacts are code, tests, and version control. Enterprise agents operate in a world where the primary artifacts are use cases, actions, policy, exceptions, and transparency. Businesses don’t operate with a code repository; it is scattered across policies, SOPs, training materials, ticket comments, emails, tacit knowledge, and lived experience. The success criterion is rarely as crisp as “tests pass.”

A coding agent’s “truth” is largely internal: does the code compile, do tests pass, does the UI behave, does the benchmark improve. Enterprise work is different. The “truth” is external and often adversarial: regulations, audits, contracts, counterparties, fraud, operational risk, reputational risk, and the simple fact that systems frequently disagree. Processes may run for weeks across teams and time zones, with exceptions that are not edge cases but the real work.

Importantly, none of this diminishes coding agents. It clarifies why the enterprise case requires additional engineering and governance. Coding agents can be extraordinarily reliable within their domain precisely because the domain has strong feedback loops and tight control of artifacts. Enterprise operations require building similarly strong loops, but around different primitives: transparent audit trails, evidence, policy, escalation, and approvals.

Introducing Enterprise Agents – A Different Type of Agent

Enterprise systems coming to the practical realization that agents are becoming true participants in end-to-end business processes, where multiple agents coordinate across steps, systems, and act to move work from initiation to completion. The distinction matters because the architecture and trust requirements are not the same.

Figure 1: Enterprise Agents and Coding Agents

Enterprise agents operate on a different surface area. They participate across multi-step business workflows that begin with an initiating event and end with an outcome that matters outside the developer toolchain. Software engineers would know this as the business process automation where business users and software designers describe multiple system components coordinate to hand work over and move through a work order, case file, through a sequence of steps and actions. The promise is compelling: compressing cycle time, reducing manual handoffs, and sustaining execution. That shift turns “agent actions” as process steps,” and raises the stakes.

What is Different for Enterprise Agents

That difference explains why enterprises will increasingly need specific governance to trust agents. One such example is a “Know Your Agent” (KYA) discipline. When agents become actors in operational processes, the primary risks are unauthorized tool use, hidden delegation, data misuse, and policy violations that are difficult to unwind after the fact. Trust must be engineered into the system: clear identity, explicit authorization boundaries, transparent purpose and methods, and traceability strong enough to survive audits and incidents. The practical claim is simple—agentic process automation only scales when accountability scales with it.

Still, enterprises should adopt the speed-and-iteration culture that coding agents have made practical, but they must transplant it carefully.

Consider enterprise agent architecture.

Enterprise agents differ from coding agents, which introduces distinct architectural considerations.

Figure 2: Architecture Considerations

Correctness, Observability, and Traceability

For coding agents, correctness is primarily a technical verification: does the resulting program behave as intended under review and testing? In this context, developers often measure success through metrics related to velocity and agility.

Enterprise agents shift the focus to socio-technical correctness, where every action must comply with corporate policy and satisfy rigorous controls. In operations, “feeling fast” is secondary to producing a defensible record that includes the decision, evidence, rationale, and a full audit trail. Success is measured by operational outcomes like cycle time, error rates, and audit findings to ensure that speed does not lead to downstream rework.

Security, Identity, and Authority

A coding agent generally operates as a personal assistant under the developer’s implicit authority within a sandboxed or local environment. This “human-in-the-loop” model allows for rapid iteration because the security perimeter is often restricted to the developer’s immediate workspace and repository.

In contrast, enterprise agents must possess an explicit identity with scoped permissions and a clear delegation model. They integrate directly with institutional security frameworks, such as Role-Based Access Control (RBAC) and compliance gating, to manage actions across multiple platforms. In the enterprise, authorization is not an optional add-on; it is a foundational architectural component that defines what actions are possible.

Memory, Long Conversations, and State Management

Coding agents rely on short-lived tasks and a coherent local repository to maintain context. They typically operate in tight cycles—ranging from minutes to hours—where the developer is constantly present to provide feedback and reconstruct state as needed.

Enterprise agents require durable, queryable memory that persists through long-running workflows lasting days or weeks. This “context engineering” must track not only what happened, but why it happened, who approved it, and which policies applied. Without this persistent state management, an agent becomes a liability that cannot reliably pick up where it left off in a complex business process.

Exception Handling and Resilience

In software projects, coding agents treat exceptions as bugs to be reduced or fixed through iterative re-prompting and manual tweaks. The goal is to reach a “happy path” where the code functions correctly within a limited, repo-centric scope.

For enterprise agents, exceptions are a standard part of the work because reality rarely fits a perfect process. These agents must treat exceptions as first-class paths, utilizing production-grade resilience patterns like circuit breakers and exponential backoff to detect errors, route them for evidence, and know exactly when to escalate. This architecture ensures transactional integrity, allowing the system to roll back safely if a single step in a complex workflow fails.

What Can Enterprise Agents Learn from Coding Agents

If coding agents are here to stay—and all signs point that way—then it is in an enterprise’s interest to adopt them deliberately and capture the upside. The basic math is hard to ignore when teams that shorten iteration cycles ship more, learn faster, and allocate scarce senior attention to higher-leverage work. The risk is not that competitors will adopt coding agents; it is that they will learn how to operationalize them—turning individual productivity gains into organizational advantage—while slower firms keep treating them as optional experiments.

One lesson transfers cleanly from software to business operations: spec-driven design is coming back, and the “plan” is becoming as important as the “code.” In the agent era, the spec is no longer a static requirements document written once and promptly outdated. It can be a living artifact that an LLM helps draft, challenge, clarify, and continuously refine. That matters because most project failures are not caused by bad syntax; they are caused by unclear intent, missing constraints, unstated assumptions, and ambiguous definitions of “done.” Helping with the spec—tightening scope, enumerating edge cases, writing acceptance criteria—may prove more valuable than helping with implementation, because it makes every downstream artifact easier to build and safer to change.

This is where the uncomfortable but accurate line lands. A colleague stated it like this: “You will eventually move faster than you can verify code as a human.” Coding agents compress the act of producing plausible code to near-zero marginal cost, which means the bottleneck shifts to verification: review, testing, and evidence that the change does what it claims without breaking what it shouldn’t. Enterprises should treat that quote as a design constraint. If verification cannot keep up, the organization will accumulate hidden risk, even if velocity looks strong. The only sustainable response is to invest in verification as an engineering capability—strong tests, tighter interfaces, clearer invariants, better observability, and a culture that treats “proof of correctness” (in practical, testable forms) as part of the deliverable rather than an optional afterthought.

This is where the diligence in creating a sound and detailed specification (with coding agent help, of course) pays dividends. Simply put, the specification becomes the bridge between speed and verification.

Conclusion

Coding agents are the future of software engineering. They are already delivering real productivity gains, and enterprises will increasingly treat them as part of the standard engineering stack. The right enterprise posture is to capture the upside while institutionalizing the practices that make speed safe: small diffs, strong review norms, test discipline, and apprenticeship-like training that turns agent leverage into durable engineering judgment.

For enterprise agents, the advice is parallel but broader. Borrow the iteration culture of coding agents and use coding agents aggressively to build the scaffolding of agentic process automation. At the same time, recognize that enterprise agents must be designed as business operators inside a controlled system: transparency, identity, policy, exception handling, durable memory, replayability, traceability, and collaboration are not optional features; they are the product. If you get those right, you can bring the capabilities of modern agentic tooling into the enterprise—without turning speed into operational risk.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn or respond to this article. Questions and comments are welcome and encouraged!

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hostsJohn Miller andEric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

The Minimum Viable Context is the goal: the right context, at the right time, with the right token budget. This is urgent as enterprises move from a handful of copilots to thousands of agents operating in parallel. What’s missing is a disciplined way to compile context from reusable building blocks—while elevating policy and decision boundaries as first-class citizens.

Introduction

The context window—the fixed slice of text (instructions, facts, retrieved material, intermediate results) a model can “see” at once—is now the scarcest and perhaps most consequential resource in AI systems. Today, it is probably fair to say it is also managed poorly. And the result is probably predictable: at times large language models confidently produce uneven and sometimes outright unpredictable outcomes results. Why? Not because the enterprise lacks knowledge, but because the decisive constraints weren’t loaded into the window at the moment a decision was made.

The hard lesson the industry seems to have learned is that context engineering is not primarily an information-retrieval problem. Instead, context engineering is an end-to-end memory management problem with a hard token budget.

Agents raise the stakes. According to some industry leaders, “there will be billions” of them inside a single enterprise – so, even if they are far off in their predictions and there are only millions or perhaps thousands of them in every firm – this means small context failures get amplified into systemic ones. And because agents act—executing plans, calling tools, updating systems—a missing constraint doesn’t just degrade an answer; it becomes a real-world side effect.

Now, the twist, or perhaps opportunity, is that agents are also in the execution path, which means they can capture decisions – effectively the digital exhaust from logging agent activities combined with some instrumentation – about how the business actually runs. And it can use these activity logs (sometimes called “decision traces”) to create a feedback loop letting agents learn from past successes (and failures).

What we really need is a way to capture the Minimum Viable Context that delivers to the context window the right concepts at the right time at the right token budget. We build out our MVC around a combination of existing and emerging ideas as well as new and innovative ones:

• Concept cards, built from knowledge graphs and ontology foundations, that capture meaning and “senses”, but also assign token budgets associated with their data.

• Policy cards, that capture “how a business runs” – its decision boundaries, rules, exceptions, and “if-then” logic that are enterprise embedded in all business processes.

• Context compiler, that dynamically decomposes a user request into concept and policy cards, acquires data optimized for a required token budget, and serves it for an agent’s LLM context window.

• Feedback loop, that captures agent exhaust as outputs and compares them to inputs created by the context compiler to create building blocks for a powerful feedback mechanism to help agents learn.

• Virtual Context Manager, that manages the end-to-end process from concept and policy card creation, context compilation, and the feedback loop.

This article lays out the architecture and the discipline for these components. For a full in-depth review of these concepts and the architecture, take a look at our YouTube video.

Problem Statement

The brain for agents – its LLM – is frozen at the time of training. The agent (actually its LLM) knows nothing about an enterprise’s private data. To provide information specific to the enterprise, we have landed on a a technique called retrieval-augmented generation (RAG): index the corpus, chunk documents into smaller pieces (often in a vector database or a knowledge graph), retrieve the “most relevant” passages, and paste them into the context window.

The core limitation is that chunking can be arbitrary: it breaks coherent source material into fragments that lose the original logic, decision boundaries, and intent. Even when retrieval lands near the right place, the returned chunks are often incomplete—missing the surrounding definitions, dependencies, and qualifiers that make a constraint operative—so the model is forced to infer what should have been explicit.

To address this shortcoming, teams naively respond by adding more chunks. But then the system can’t see the forest for the trees as attention skews toward the edges, key thresholds and exceptions get buried in clutter, and the model behaves as if the rules weren’t present. The core problem remains: the most relevant rules and policies that actually run the enterprise – exceptions, thresholds, if-then branches, and regime boundaries – are lost.

From a practical perspective, we find that relevance is conditional on intent and role; the same question asked by a compliance analyst versus an operations analyst implies different obligations, not just different facts. In effect, relying on chunk retrieval tends to lead to concept overlaps, producing answers that sound coherent yet are operationally wrong.

The Minimum Viable Context

What we really need is to deliver a Minimum Viable Context (MVC) whose definition is quite simple: the right context, at the right time, at the right token budget:

Minimum. Our objective is to have the smallest working set in the context window that still lets the agent work correctly. The size constraint is practical: the context window has a hard token budget, and loading additional material consumes capacity that may unnecessarily consume this scarce resource (and it will increase costs).

Viable. A viable working set for a context window includes the meanings (concepts) that must be pinned and the governing constraints (policies) that must be applied, including any exceptions and required inputs needed to execute those constraints. Viability is assessed under the same hard token budget: if the necessary constraints and bindings cannot fit, the system should treat that as a shortfall that requires verification, additional inputs, or escalation before acting.

Context. Working under a hard token budget, the context is a dynamic compilation of concepts and associated acquired data, policy information, and system information (tools, etc) that is served into the model’s context window.

Concept cards

As we have pointed out, the MVC is built upon a foundation of related components. Content cards are the quantum of disambiguated, token budget aware, knowledge, in the same spirit as old-style library cards that cross-referenced books by title, author, and subject to make retrieval precise and repeatable. Here, a concept card is simply a small YAML/JSON record that conforms to a strict JSON schema, so it can be validated, indexed, diffed, and assembled deterministically.

Figure 1 - Concept Card

A concept card captures meaning. Its job is to provide a stable, governed way to say what a term means in this enterprise. Concept cards include a stable identity (card ID and canonical name), an owner (the domain authority for that meaning), and a sense inventory, relationships to other concepts (cards), provenance, and data acquisition plans.

Senses are particularly important as the disambiguate complex or overloaded concepts. A sense is a discrete operational meaning of an overloaded term—an explicit “which meaning do we mean here?” option that the runtime can select.

“Customer,” for example, is a broad and almost intuitive topic, but it has different senses depending on its specific usage: in an AML/KYC workflow it may mean the screened subject; in sales it may mean the buyer or account in a CRM; in billing it may mean the paying account in a revenue system.

So, each sense is named, bounded, and anchored to enterprise usage: the identifiers it uses, the system(s) of record it maps to, and the cues the runtime can use to disambiguate (role, workflow stage, channel, jurisdiction, required fields).

Concept cards also capture relationships to other concepts, so navigation stays controlled and intentional. Instead of vague “related to” links, relationships are typed to express operational structure so the concepts can be traversed to adjacent meaning without expanding into generic “aboutness.” To do this, concept cards are built on a foundation of enterprise ontology or knowledge management (knowledge graph) systems.

Finally, concept cards are also operational by containing:

• Provenance, citing exact source spans (document sections, table rows, tickets, PRs, transcript turns) with version metadata so meanings can be audited and updated safely

• Data acquisition instructions, encoding how to acquire the underlying data for each sense—what system to query, which identifiers/fields to use, and what evidence is required—so “meaning” is not just descriptive text but a usable pointer to the enterprise data needed to apply policy correctly.

Policy Cards

Concept cards pin meaning (which entity and which attributes are in play); policy cards pin constraints (what rules apply and what actions they require); and together they let the runtime assemble a step-specific working set under a hard token budget.

Figure 2 - Policy Card

Policy cards are a key differentiator from approaches that focus primarily on content and concepts. In our approach, policies (cards) are a first-class citizen in context engineering.

Policy cards capture decision boundaries, the parts of enterprise knowledge that determine outcomes. They include thresholds, if-then branches, exceptions, overrides, and regime boundaries—what counts as “high risk,” when to escalate, when to deny, what evidence is mandatory, and which policy regime governs this case. They matter because they are the difference between a system that is merely informative and one that is operational: if an agent misses a boundary, it can take the wrong branch with high confidence and produce a real side effect.

Policy cards rely on concept cards to make their conditions unambiguous. Conditions reference concept card senses rather than raw words, so “customer” in an AML context can be bound to the screened subject concept card sense, while “customer” in sales can be bound to the account sense, and the policy applies to the correct entity. This is also where case state matters: concept sense selection is informed by role, workflow stage, channel, jurisdiction, and required fields, and the policy card’s scope must match the same state.

A policy card is a compact record of a decision boundary and the metadata needed to apply it. Representative fields include:

• Scope (jurisdiction, product, channel, lifecycle stage), authority tier (policy, procedure, guidance, workaround), and effective dates/version (what is in force now).

• Structured decision boundaries, including conditions (what must be true), outcomes/obligations (what must be done), and exceptions/overrides (what changes the default).

• Provenance and ownership, that link the policy back to accountable owners and originating sources (documents, attributes, systems of record, standard operating procedures etc).

• Action bindings, including which tool/system to call, required parameters, and what to do on failure.

The Context Compiler

The context compiler is the runtime component that creates and executes a context plan to produce the Minimum Viable Context. The context plan is built from several inputs: the user request, available concept and policy cards, the current case state (jurisdiction, product, channel, lifecycle stage, risk tier), and a hard token budget for the context window.

Figure 3 – Context Compiler

The context plan is created by an LLM through decomposition of a user request into a directed acyclic graph (DAG) representing the steps and parameters to identify and gather data. The DAG conforms to a strict JSON schema so it can be validated and executed consistently (plus this helps the LLM create consistent and repeatable plans). A typical step in the DAG contains the concept and policy card IDs (plus sense), the data acquisition method (which system/tool to query), the expected output shape, and the maximum token allocation allowed for the result.

The context plan is bound to parameters extracted from the user request and case state. The LLM extracts (in the same step when the context plan is created) the values needed to run each step—customer identifiers, account numbers, dates, jurisdictions, product codes—and plugs them into the step’s parameter fields.

Importantly, the next step – execution of the plan – is deterministic. The compiler runs the steps in dependency order, calls the specified tools or data sources, and gathers results. Two constraints shape what is acquired: relevance (the step must support the next decision gate) and token budget. Note that the step has a token allocation and may be truncated, summarized, or skipped if it exceeds its cap or becomes unnecessary once other results resolve the decision.

After acquisition, the compiler packs the acquired data and policies into a context manifest that is first logged and then stuffed into the context window in a stable order. It combines the user request, the acquired data (bounded by per-step budgets), the pinned concept senses, and the relevant policy cards. Policy cards are included for their decision boundaries—thresholds, exceptions, overrides, regime scope, required inputs, and action bindings—so they constrain the model before it acts. The context manifest, in effect, becomes the audit record that explains what the agent was thinking, and how it decomposed and interpreted the user request into a working set filled into the context window.

The output of compilation is an MVC: the smallest set of meanings, constraints, and supporting data needed to make the next decision correctly under the hard token budget. “Stop” is an explicit rule: the compiler stops adding material once MVC criteria are met, rather than chasing top-k retrieval or adding background text “just in case.”

As in most cases, we stand on the shoulders of giants and re-purpose existing ideas: A useful way to think about our context compiler is to look at how a database executes a SQL query. A prompt is like an SQL query: it expresses intent, but it is not an execution strategy. The context plan is like a query execution plan: it decides which “tables” to consult (concept and policy inventories, systems of record), the join keys (sense bindings, identifiers), the filters (scope and eligibility), and the cost constraints (token budgets) so the result is correct and bounded.

Agent Exhaust and the Feedback Loop

Agent activity logs capture execution outcomes. But these logs contain information – sometimes explicit and often implied – about the decisions. Foundation Capital defines these logs as decision traces which structures “the exceptions, overrides, precedents, and cross-system context that currently live in Slack threads, deal desk conversations, escalation calls, and people’s heads.” They continue, where “rules tell an agent what should happen in general... decision traces capture what happened in this specific case (‘we used X definition, under policy v3.2, with a VP exception, based on precedent Z, and here’s what we changed’)”.

The key point is that the agent is the executor, and the exhaust from its execution is contains logs and information that form the basis for decision traces. However, what is needed is a way to decompose agent exhaust into “decision cards”. Foundation Capital goes on to state that “context graphs” are the mechanism to capture decision traces.

We think a more specific approach is available to us: we suggest starting with the context plan, a concrete structured artifact which, in effect, is a detailed description of the inputs to an agent execution, to frame and map the agent’s output. And by comparing the inputs to outputs, we have the building blocks for a feedback loop.

Putting it all together: The Virtual Context Manager

The Virtual Context Manager (VCM) manages the end-to-end context engineering process. Its goal is explicit and operational: deliver in a repeatable way a Minimum Viable Context (MVC)—the right context, at the right time, under the right token budget.

Figure 4 – Virtual Context Manager

At a high level, the VCM operates in several modes.

• Background mode, where it manufactures and maintains the cards and the structures that make them governable. Card maintenance is a continuous distillation process. Once operational, the system detects ‘staleness’ via provenance links—triggering an automated refresh alert whenever a source document is updated, ensuring the card library evolves alongside the enterprise.

• Online mode, where it compiles the working set – the MVC - for the next step by executing a plan in deterministic code: pin meanings, filter eligible policies, resolve conflicts by precedence, pack under budget, stop at MVC, or fault into verification/escalation when MVC cannot be reached safely.

• Feedback mode, where the inputs MVC, composed of expected outcome and associated decision boundary, are combined with agent exhaust (logs, decision traces) that capture outcomes and decisions actually made, to create a before-after-optimize feedback loop.

Once again, an analogy helps our understanding: consider virtual memory in computers. In an operating system, the virtual memory manager (VMM) decides what must be resident in RAM now, what can remain on disk, and how to maintain a working set that lets the program make progress without constant stalls. In our case, the context window is scarce RAM, the corpus is disk, cards are the pages, and MVC is the working-set target. The VCM’s runtime component—the context compiler (VCC)—plays the role of the VMM: it decides which pages to map into the prompt for this step, under a hard budget, so the agent can execute without drifting or thrashing.

The Case for Explainability

Explainability is the ability to explain what an agent did, and why. It turns context loading into a transparent, logged process rather than an emergent side effect of similarity search. Each step produces an explicit context plan—structured, reviewable, and stored—showing what meanings were pinned, which policy regimes were considered eligible, what decision gates were expected, and what data bindings were required.

With explainability comes provenance. Provenance is made explicit in a concept or policy card by linking back to the original material it came from, down to the specific paragraph, table row, or ticket comment, in a specific version of the source.

And you can use explainability as the foundation for a compelling feedback loop: a concrete record of the agent’s execution path, mapped back to the context acquisition plan and the specific pages that were resident when each branch was taken. We think this is stronger than “observability” – rather, it is a reconciliation mechanism. You can see whether a bad outcome came from loading the wrong meaning page, selecting the wrong governing policy page, missing an exception, or failing to obtain required data before acting.

The Foundation for Trust

Trust is not a tone the model strikes; it is a property the system can prove. In a Virtual Context Manager, trust is the composition of four capabilities: provenance (where a constraint came from), explainability (what the agent did and why), measurement (how the system performs under budget), and feedback (how it improves when it fails). If any one of those is missing, you do not have a trustworthy agent—you have an improviser with better search. In this framing:

Trust = Provenance + Explainability + Measurement + Feedback

Provenance turns constraints into accountable artifacts. It lets the VCM choose between competing pages deterministically, detect when a page is stale, and page in evidence selectively when risk is high. Without provenance, policies degrade into “soft facts”: plausible today, unprovable tomorrow, and impossible to maintain as the corpus shifts. With it, the manager can treat policy pages as something closer to executable governance, not retrieved prose.

Explainability and measurement makes that governance operational. It produces transparent context plans for each prompt—the page table for what was mapped into working memory and why—then logs the agent’s execution against that mapped context.

Feedback closes the loop, and this is where trust becomes durable. Decision traces reconcile expected behavior (the plan) with actual behavior (the execution), and outcomes—human overrides, audit findings, reversals, downstream errors—become structured signals to refine future compilation. That is the hard-hitting claim: the VCM does not ask you to trust a black box; it gives you an audit trail, a set of counters, and a correction mechanism. Agents can act at scale only when trust is engineered as provenance + explainability + measurement + feedback, not asserted as a vibe.

Conclusion

The context window has become the scarce resource that determines whether agents behave like disciplined operators or confident improvisers. This article argued that the hard problem is not “better retrieval,” but memory management under a token budget: pin meaning, load only governing policies and constraints, to create a Minimum Viable Context by delivering the right context, at the right time, at the right token budget.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn or respond to this article. Questions and comments are welcome and encouraged!

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Policies and Decision Boundaries – First Class Citizens of the Agent Context Window

Enterprises run on thresholds and overrides—not just facts—and as we face an imminent explosion of millions of agents, wasting scarce context on “relevant background” is a liability we can no longer afford. To prevent a chaotic ecosystem of unmanaged improvisation, we must elevate policies to first-class citizen in the agent context window.

Introduction

A context window is the make-or-break payload that determines whether delivers a credible and accurate outcome. Unfortunately, today we manage this context window badly. We jam in “relevant” passages, but starve the model of the information about how the business runs – policies and decision boundaries - and then are shocked when it improvises policy, misses a threshold, or takes the wrong branch (with, apparently, total confidence).

Context engineering exists because the model’s training doesn’t contain your enterprise’s data—today’s products, procedures, exceptions, and risk posture. So, inevitably, we mismanage this scarce resource because we – incorrectly – treat context engineering like search: retrieve the top passages, paste them in, and hope relevance equals correctness.

That pattern works when the target is a noun—an entity, a record, a document, a definition—because nouns index cleanly and retrieval can usually get you “close enough.” It’s why the field has fixated on concepts: pin meaning, disambiguate terms, bind the right entity, pull the right attributes. Yes, concepts matter, but they’re not the missing ingredient.

We know – and the industry is starting to open their eyes – that the missing ingredient is what actually runs the enterprise: policies—the thresholds, branch points, exceptions, overrides, and regime-selection rules that determine what happens next.

But how does this impact agents? It is absolutely clear that we will soon have thousands—or millions—of agents in every enterprise. So, what may seem a trivial costs when agents are tied to single users, but inaccuracies and costs at-scale become an enterprise issue.

In this article, my co-author John Miller and I argue that policies must be treated as first-class citizens in context engineering. We define what a policy is in operational terms, explain why traditional retrieval systematically misses boundaries even when it retrieves “relevant” content, and show—using a simple bank account opening flow—how one missing clause turns a helpful agent into an unsafe operator.

The Scarcest Resource In the Agent Ecosystem: The Context Window

A context window is a bounded workspace measured in tokens. A token is a chunk of text that a language model reads and writes as its basic unit, sometimes a whole word, sometimes punctuation or whitespace. So, tokens are not quite the same as words or characters, but in rough terms (for English): 1 token ≈ 4 characters ≈ 0.75 words, so 100 tokens ≈ ~75 words and 1,000 tokens ≈ ~750 words.

Tokens they vary by language and content, and they behave as the model’s unit of attention and memory for its current request. A typical window includes three kinds of material: the task itself (what the user asked for), the retrieved or acquired information (facts, records, evidence), and the system instructions (tool descriptions, JSON schemas, allowable actions, and procedural guidance). In an enterprise setting, the context window is where you inject your information into a model that otherwise lacks knows nothing about your enterprise.

Below we show the anatomy of a context window as it has evolved from simple chat to enterprise RAG to agents. A model’s limited context window is broken into five parts (all of which have to fit into a limited token budget): a system prompt, retrieved context (RAG), conversation history, the current user query, and an output buffer—and shows how their relative shares shift across three settings: simple personal chat, enterprise search-driven RAG, and agents.

Figure 1: Anatomy of a Context Window

In personal chat, conversation history dominates the window (about 70–85 percent) while retrieved context is effectively absent; in enterprise RAG, that balance flips, with retrieved material swelling to roughly 60–75 percent and conversation history shrinking to a thin slice.

Agents sit between the two: they still carry some history, but they reserve a large block for retrieved context (around 40–50 percent) alongside a larger output buffer, reflecting the need to plan, act, and explain.

The message is blunt: as enterprises move toward fleets of agents—potentially thousands or millions—the governing constraint is no longer the prompt, but how much high-quality retrieved context can be packed into the window without crowding out everything else.

Now, let’s contrast the way agents use context . Today, retrieved context is dominated by concepts—nouns, objects, things—while policies and decision boundaries exist only as accidental fragments, buried ad hoc inside whatever documents happen to be retrieved. That means the agent can be well-informed and still take the wrong branch, because the constraints that determine whether it should proceed, stop, escalate, or require an override are not guaranteed to be present at the moment of action.

The “optimal” view makes the shift explicit: the retrieval budget is split intentionally, with about 60 percent reserved for concepts and 40 percent reserved for policies and decision boundaries, treating constraints as a first-class citizen rather than an afterthought. The argument is that predictability at scale depends less on retrieving “more knowledge” and more on reserving guaranteed space for the rules that govern outcomes—thresholds, exceptions, overrides, required evidence, and audit trails—so the agent’s behavior is constrained before it is confident.

Figure 2: Anatomy of the Agent Context Window

The truth is simple: policies are different from “more enterprise data.” Facts describe what is true. Policies describe what must be done, what is allowed, what is forbidden, and what requires escalation. Decision boundaries are the branch points inside that the business processes that run an enterprise: thresholds, if-then logic, exceptions, overrides, and regime selection. In operational work, a single sentence can flip the path—approve versus deny, automate versus escalate, proceed versus stop and file a report.

That is precisely why “top passages” retrieval is a poor fit: boundaries are compact, brittle, and often scattered across long documents, footnotes, internal tickets, email threads, and tacit practice. The model does not need ten pages of background. Sometimes all it is missing is the one rule that governs this step.

And that is exactly why policies and decision boundaries must become first class citizens in an agent’s context window.

Policies and Decision Boundaries

A policy, operationally, is a compact, explicit record of a decision boundary. It describes preconditions (what must be true), required actions (what must happen next), branch flips (thresholds and regime selection), and the exceptions and overrides that prevent the system from improvising when reality deviates from the happy path. It also carries scope—product, jurisdiction, channel, and risk tier—because policies do not apply universally. And it carries ownership, versioning, and effective dates, because policies drift continuously under regulation, product changes, and evolving risk posture.

Figure 3: Policies and Decision Boundaries

To call policies “first-class citizens”, we are making a very explicit engineering claim. By first-class boundaries, we mean that they are addressable at runtime (you can point to the exact rule you loaded), testable (you can validate behavior against it), versioned (you can reproduce past decisions), and auditable (you can explain which boundary fired and why).

In practice, this means policies are not merely “contained somewhere in the corpus.” They are structured enough to be reliably retrieved and injected into the context window when the decision is made. They are small enough to be loaded consistently under budget. And they are explicit enough that you can record, after the fact, which rule governed the outcome.

This is also why policies are hard. Much of policy is tacit: “how we really do it” lives in people’s heads, shaped by experience, escalation habits, and risk culture. Written policy is buried in SOPs and long documents as clauses and carve-outs rather than as discrete decision boundaries.

And policies are distributed across the enterprise, organized by process and org chart instead of by the decision points that matter. And sometimes they change frequently. To make policies operational, they also must bind to meaning.

So, a policy is is a constraint applied to an object. In enterprises, the same word often names different objects. “Customer” might mean the screened subject in an AML workflow or the account holder in a billing workflow. If the model binds the wrong sense, it can apply the right rule to the wrong entity with high confidence.

This is where concept work remains essential: concepts pin meaning; policies pin constraints. The two are complements, not competitors. But treating concepts as sufficient—while leaving policy implicit—leaves the system fragile at the exact moments when correctness matters most.

Policy Cards: Capturing Policies and Decision Boundaries

A policy card is a compact record (perhaps in YAML, shown below, or JSON format, governed by a JSON Schema) that can be loaded into the context window, evaluated deterministically, and audited after the fact.

Figure 4: Policy Cards

A strong policy record usually carries several key fields (in practice there are a bunch more) that make the boundary explicit and enforceable:

• policy_id: A stable, unique identifier so the boundary is addressable, referenceable in logs, and testable over time.

• scope: The regime selector: which product, channel, jurisdiction, customer type, and risk tier this policy governs (and, just as important, what it does not govern).

• preconditions: The exact facts that must be true for the policy to apply, written against explicit entities and senses (so the rule binds to the right “customer,” “account,” or “subject”).

• decision_boundary: The branch logic itself: thresholds, match-score cutoffs, confidence minimums, and other “flip points” that determine which path the agent must take.

• required_actions: The mandatory next steps when the boundary fires: block, escalate, collect additional evidence, file a report, notify a role, or proceed under a constrained mode.

• exceptions_and_overrides: The only permitted escape hatches: what qualifies as an exception, who may override, what alternative evidence is acceptable, and what must be captured to make the override legitimate.

• version_and_effective_dates: The governance spine: version number, effective date (and optional end date), change summary, and owner—so decisions can be reproduced and defended against “what policy was in effect that day?” questions.

Example – Bank Account Open

Consider a simple bank account opening flow. Our customer, Maria, wants to open an account. The typical steps are familiar: identity verification, KYC/AML screening, an initial deposit, notifications, and then the ongoing operational machinery—statements, limits, monitoring.

A RAG-style approach can retrieve pages of procedural guidance and relevant forms. It can find product descriptions and onboarding scripts. It can even pull Maria’s application record and supporting documents. None of that guarantees correct action if the governing boundary is absent.

The first boundary is around selecting the most applicable rules. If the account is chequing versus investment, different rules apply. If the channel is in-branch versus online, evidence requirements change. If the jurisdiction or residency differs, the governing policy regime changes. These are branch flips that are not optional; they determine what must be checked, what must be stored, and what must be reported. The agent cannot infer them safely from generic “best practices.” It must load the applicable regime boundary into the window and follow it.

Then come thresholds. If identity confidence is below X, we must escalate to manual review. If a sanctions or watchlist match score is at or above Y, we must deny and file the required report. If identity verification falls below a required confidence threshold—or comes back “partial,” “inconclusive,” or “document mismatch”—the workflow shouldn’t limp forward. It should block, step up to stronger evidence, or route to a defined exception path.

Exceptions and overrides are where “policy as a first-class citizen” becomes a safety mechanism. Maria can’t complete standard ID verification—her document is expired, her name doesn’t match perfectly, or she lacks one of the required proofs.

That should not trigger improvisation (“close enough”) or a quiet downgrade in rigor. It should trigger a defined exception workflow with explicit guardrails: what alternative evidence is acceptable, who must review it, what risk tier applies, and what must be recorded.

And if a bank manager can approve an override, the system must force the trail—rationale, evidence, and the specific boundary being overridden—because auditability is part of the control surface. Without explicit boundaries, you get silent improvisation; with them, the system knows when to stop, escalate, deny, or require an override record.

Conclusion

The operational claim is just plain and simple: more facts do not guarantee correct action; the governing boundary does. In agentic systems, missing a boundary is an operational risk with side effects in the real world. The decisive constraint must be present in the context window exactly when the decision is made. And that requires treating policies and decision boundaries as first-class runtime artifacts—addressable, testable, versioned, and auditable—rather than as text that happens to be somewhere in the corpus.

We expect to soon see hundreds, thousands, maybe tens of thousands of agents in every enterprise, and this incredibly magnifies the problem. Without first-class boundaries, behavior drifts across time, teams, channels, and jurisdictions in a way that is just too difficult to fully or easily explain, because the system is effectively improvising from incomplete constraints. With first-class boundaries, you can explain outcomes: which rule fired, which exception triggered, who overrode, and why. If enterprises are serious getting effective results from their agent ecosystem, then context engineering has to be explicitly designed around policies and decision boundaries—not just around the retrieval of more passages.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn or respond to this article. Questions and comments are welcome and encouraged!

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

KYA – Know Your Agent

The average enterprise will run more AI agents than employees within three years, but unlike employees, most agents have no verified identity, no access limits, and no audit trail. KYA - “Know Your Agent” applies the same verification and control framework that HR uses for workers - because agents now execute the same business processes employees do.

—

Introduction

Agents will be embedded in business processes with direct impact on operations, data, and compliance. This creates three engineering requirements: limit what the agent can do, record what it did, and explain why it did it.

KYC (Know Your Customer) and KYB (Know Your Business) provide a starting model through verified identity and risk controls. But in enterprises running thousands of agents, knowing your agent—its purpose, policies, and identity—becomes critical.

We think agents will operate more like employees than customers. They need onboarding, access rights, supervision, and review of what they did through audit trails. This means “Know-Your-Agent” (KYA) should follow a “Know-Your-Employee” (KYE) model: least privilege, time-limited permissions, and clear ownership.

This article describes what KYA is and how it works. The goal is to keep agent design simple: agent behavior that is transparent, safe and auditable at scale – we need to know your agent.

KYC, KYB, Welcome to KYA

KYC and KYB exist for a simple reason: when a bank or regulated firm lets someone open an account, move money, or access sensitive services, the firm needs confidence about who is on the other end and what risks they bring. KYC focuses on a person; KYB focuses on a company.

But both are built around the same steps: verify identity, understand risk, apply proportionate controls, and keep evidence that those steps were taken. The goal: reducing predictable failure modes—fraud, misuse, and regulatory breaches—before they happen.

Figure 1: KYC? KYB? Welcome to KYA

Know Your Agent (KYA) applies that same approach to agents that can take actions in business processes. But if an agent can pull data, trigger transactions, send messages, or change records, then “who is acting” matters just as much as it does for a human customer or business.

KYA starts with runtime identity: establishing which agent instance is operating, who owns it, and what version is running, so actions can be tied to a specific, accountable source. It also starts with risk: an agent can make unauthorized or policy-breaking moves because it is misconfigured, overly empowered, or operating on incomplete information.

KYA is also about controls and proof. In KYC/KYB, controls look like screening, due diligence, and monitoring; in KYA, controls look like limiting what the agent is allowed to do and watching what it actually does. The practical goal is to prevent “surprises”: the agent should only be able to use approved capabilities, within clear boundaries, and in ways that can be reviewed after the fact. And like KYC/KYB, KYA requires evidence including records that show what the agent was permitted to do, what it did, and why, so that audits, incident investigations, and reviews can be based on actual facts.

KYA is Built Upon Decades of “Know Your Employee” (HR) Practices

KYC and KYB are definitely useful models, but we think there is an even closer match: agents behave more like workers in your enterprise. We see an employee as an internal actor you onboard, empower, supervise, and hold accountable over time. We think the same applies for agents because they are being asked to participate in real business processes.

Figure 2: Is Know Your Employee (KYE) a Better Model for Agents (KYA)?

The fit is strongest in the way access is granted and controlled. With an employee, you don’t just confirm who they are; you decide what job they are allowed to do and what systems they can touch, and you change that access as responsibilities change. Agents need the same treatment, but tighter. You want a clear record of the agent’s owner and version before it runs, and you want its permissions to be narrow and temporary—activated for a specific task, then removed—because the biggest operational failures come from actors that can do too much for too long.

The same applies to policies and oversight. Human training works because people can be warned, corrected, and slowed down; agents operate at machine speed and will repeat a mistake consistently until something stops them. That means policies have to be enforced by the system and the organization needs a reliable trail of what the agent decided, what tools it used, and what data it touched. When an incident happens, the goal is a factual reconstruction that supports audit, remediation, and recertification. This is why the employee model is more realistic: it treats the agent as an internal operator whose authority must be bounded and whose actions must be reviewable.

Trust in KYA starts with a simple proposition: purpose plus proof. By default, an agent should never be “trusted”. Instead, it should only be trusted when its purpose is clearly and transparently stated and bounded, and because there is concrete evidence it will operate inside those bounds.

In practice, that means you can answer basic questions before the agent runs: what job it is supposed to do, what data and systems can it touch, and what checks prevent it from doing anything else. Addressing a full trust framework is beyond the scope of this article, but we offer a full article that describes this framework (shown in image below) here.

Figure 3: KYA – Fundamental Trust Themes

Second: Trusting a single agent is just not enough; you have to trust the ecosystem the agent lives in. Even a well-designed agent can be pushed into bad outcomes if the surrounding environment is weak. So, there is a real problem if identity can be spoofed, if permissions are too broad, if tool access is uncontrolled, or if actions are not recorded.

The “ecosystem” here is the set of shared services and rules that make agent behavior predictable: authentication, access limits, safe tool interfaces, and an audit trail that lets you reconstruct what happened when something goes wrong.

Third: in world of thousands of agents in any given enterprise, this is a scale problem: trust at scale must be federated. As the number of agents grows, no single team can manually review every agent, every change, and every action. Trust has to be built from repeatable standards that different groups can apply consistently, with shared evidence that can travel across organizational boundaries. That means capabilities that can be applied consistently across an enterprise become critical: common identity and permission models, standard ways to declare purpose and constraints, and consistent logging.

Enterprise Agents vs Coding Agents

Coding agents are taking the software engineering world by storm. So, we would be remiss in not explaining where they fit in KYA (spoiler alert: there is overlap, but also some very specific differences).

Coding agents are built to help an individual or a small team produce software faster: write a function, refactor a module, generate tests, explain an error, or draft a PR description. Their value is local and their blast radius is usually bounded by the developer workflow. Even when they make mistakes, the failure mode is often visible quickly—code doesn’t compile, tests fail, a reviewer catches the issue, or the change never ships. In practice, coding agents live inside a culture and toolchain designed to absorb iteration: version control, CI, peer review, and staged deployment. That scaffolding does not eliminate risk; Instead it narrows the consequences and creates natural checkpoints.

Enterprise agents operate in a different environment. They sit closer to business processes than to code, and they tend to cross boundaries: data domains, systems of record, teams, jurisdictions, and approval chains. Their outputs can become actions that, for example, open accounts, issue refunds, update customer records, route shipments, or generate filings. That makes the critical question about whether the organization can constrain it, attribute its actions, and explain its decisions to auditors, customers, and regulators.

This is one reason KYA matters so much for enterprises. Coding agents can often be made “safe enough” through developer guardrails and human review because the workflow already assumes trial and correction. Enterprise agents, by contrast, must be governable in the way regulated processes are governable: identity that holds up under scrutiny, explicit authorization, clear purpose and decision boundaries, traceability of actions and evidence, and lifecycle controls that prevent silent drift. If agents are becoming operational actors inside the business, then KYA bridges capability and risk.

Lessons Learned

KYC and KYB are useful starting points because they teach the right instinct: if something can touch money, customers, or regulated data, you need verified identity, risk controls, and audit-ready evidence. But agents behave less like external customers and more like internal operators, which makes KYE the closer model: onboarding, scoped access, time-boxed privileges, enforced rules, supervision, and accountability. If you treat agents like employees rather than customers, you naturally design for controlled authority and traceable actions instead of one-time screening at the boundary.

Why This Matters

KYA matters because agents participate fully in business processes, and, soon, at scale a small mistake becomes a large incident. When thousands of agents can touch data, tools, and workflows, the blast radius is no longer a single bad output; it is unauthorized actions repeated quickly across many systems. KYA is the discipline that keeps that authority bounded and accountable. Still, we can learn from decades of experience managing employees. We see KYE – Know Your Employee – practices as the ideal starting point for an kickstarting and enterprise’s KYA journey.

Conclusion

KYA is the practical work of making agents safe to run inside real systems. It starts with knowing exactly which agent is acting, what it is allowed to touch, and what rules it must follow, and it ends with being able to reconstruct outcomes from evidence rather than recollection. In that sense, KYA is less about model capability and more about operational design: narrow permissions, clear purpose, enforced constraints, and records that make behavior reviewable. If those elements are missing, the organization is relying on luck; if they are present, the organization can expand agent responsibility with measured risk.

The near-term reality is that scale will arrive first when a few high-value agents will be deployed broadly, then reused and copied until the fleet grows faster than governance. The real issue is that agents likely will quietly accumulate authority and scale through the most natural of motivations: convenience. The engineering response is to treat every new agent, tool, and version change as a change in operational risk, and to make that risk legible and bounded before the fleet becomes too large to reason about.

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn or respond to this article. Questions and comments are welcome and encouraged!

Subscribe now

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

A Practical Agent Trust Framework

Enterprises run on trust. We propose an innovative agent trust framework spanning identity, access control, observability, certification, and governance, so enterprise agents can be relied upon – and trusted - in production.

—

Introduction

Most agents built today remain science experiments that never leave the lab. Time and time again we see that trust – or more specifically the lack of trust – is the primary obstacle to getting these agents into production.

There is a pattern that seems quite consistent. A team builds an agent that works well in testing, it handles edge cases, produces good outputs, and delivers clear value. But then security asks how to manage credentials and verify identity; Compliance asks how to audit decisions and trace actions; Risk management asks how to enforce boundaries on what the agent can actually do versus what it could do if compromised or misused.

The end result, far too often, is that the agent stays in the lab, not because it fails, but because the organization cannot run it under the same level of trust required for any other enterprise application.

In this article we present a seven-layer agent trust framework to close that gap. The framework extends existing security and compliance controls to agents by defining how identity, authorization, observability, and governance work when the actor is an agent participating in a business process, when behavior depends on prompts and models that change, and when decisions must be explained with verifiable evidence.

The Agent Card and the Agent Skill

An agent card defines “what” an agent can do. Of course, it includes the agent’s identity, role, metadata and version, as well as its goal and available capabilities. An agent skill defines “how” an agent works and what capabilities it can use. It typically specifies what inputs the agent accepts and what outputs it produces, including structure, required citations, confidence reporting, and failure behavior (skills are a recent and very well received approach that are implemented in a markdown file).

The agent card and agent skill is an obvious starting point for capturing key attributes that outline its trust boundary. But we think this is necessary but not sufficient. Which is why we offer a more comprehensive and practical agent trust framework.

A Practical Agent Trust Framework

Our trust framework starts the agent card and agent skill since they are commonly available and have some of the basic but useful information. But we suggest they are but a few of the many artifacts and considerations required for an agent trust framework required by an enterprise.

Now, we don’t start from scratch. In fact, our trust framework is based upon decades of experience we have as technology engineers and executives establishing trust for enterprise applications, which we now extend and enhance for the unique needs of agents and the ecosystem they run in.

Figure 1: A Practical Agent Trust Framework

Layer 1: Identity and Authentication — Who Is Doing the Work?

Identity and authentication are the foundation because they determine whether the system can reliably attribute actions to a specific actor. A production-grade approach assigns each agent a stable logical identity and each running copy a distinct runtime identity, then binds the two with verifiable credentials so the platform can prove which deployed instance is acting on behalf of which approved agent and version.

Authentication must cover each path where actions occur: agent-to-agent messages, tool calls, and data access. If authentication is weak, the rest of the safety controls degrade because audit logs and traces cannot be trusted; you lose the ability to answer basic operational questions during an incident. This layer also requires standard hygiene—short-lived credentials, rotation and revocation, and environment isolation—because agents are production services with changing code, changing tools, and a larger risk surface than static applications.

Layer 2: Authorization and Access Control — What May the Agent Do?

Authorization is how an enterprise turns organizational boundaries into enforceable rules (roles, permissions) for an agent. The design principle is “zero-trust” or deny-by-default: the agent can only use explicitly approved tools, data domains, and delegation targets, and everything else is blocked. Permissions should be time-boxed—granted only when needed, for the shortest practical window, then automatically revoked—because common failure modes include being steered into new actions, reaching for the wrong tool, or behaving differently after a prompt/model change. Short-lived privileges limit damage by preventing standing access from accumulating unnoticed.

Layer 2 is enforced at three control points. The tool gateway validates every tool call against an allowlist and constraints such as permitted parameters, rate limits, data sensitivity, and whether the permission is still valid. The data gateway scopes read/write access to specific domains and objects and can constrain queries, with access expiring on task completion or timeout. The delegation gateway treats agent-to-agent handoffs as privileged actions: delegation is allowed only to approved peers, with explicit, temporary delegation rights rather than implicit, long-lived authority.

Layer 3: Purpose and Policies — What Should the Agent Do, and When Must It Stop?

Layer 3 defines the operating boundaries that sit above permissions: what the agent is intended to do, what outcomes are out of scope, and the conditions that require it to stop or escalate. Enterprises rely on decision boundaries such as thresholds, exceptions, required evidence, approvals, so an agent needs an explicit purpose statement and a set of rules that constrain behavior in edge cases. A workable purpose is specific enough to implement and test: it states allowed actions, prohibited actions, and whether the agent is advisory or allowed to execute.

Policies are the enforceable expression of those boundaries and should exist as runtime rules. Some policies are mechanical and can be blocked directly (for example, disallowing a tool call or data domain); others require structured checks that can be audited (for example, requiring independent evidence before escalation). The engineering goal is to make these rules measurable and reviewable: the system can enforce what it can, and it can reliably capture traces for what requires judgment, so investigations focus on whether stated boundaries were followed rather than debating intent after the fact.

Layer 4: Task Planning and Explainability — How Did the Agent Decide?

Layer 4 treats “explainability” as an audit requirement. The core test is whether the agent can show how it reached a decision using checkable inputs: what evidence it used, which policy limits applied, and which tools it invoked. To make that possible, the agent should produce a structured task plan before acting, especially before making tool calls. A plan is an engineering control point: it can be inspected, blocked, or routed for human review when it crosses defined thresholds or tries to use capabilities outside its permissions.

The explanation then becomes a structured record that ties the outcome to the plan and to the facts. It should state the objective, the evidence considered, the policy rules applied, the decision taken, and the main alternatives rejected, including any uncertainty and where authority ends. User-facing explanations can be brief; audit-grade explanations must reference specific artifacts and actions so another system or reviewer can verify the chain from evidence to decision to tool use. This does not necessarily replace detailed traces, but it creates a coherent map that makes traces usable during incidents, audits, and recertification.

Layer 5: Observability and Traceability — What Happened in Production?

Layer 5 is about making agent behavior observable in production and explainable after an incident. Standard metrics are just not enough because the work is a sequence of steps: the initial request, the plan, each tool call, the data returned, any delegation, and the final action. Traceability links those steps with stable correlation IDs and immutable logs so the organization can answer basic questions with evidence: what the agent saw, what it did, and what it was allowed to do.

This is where an Agent Skill becomes operationally useful. It defines measurable expectations—latency, error rates, policy violations, tool usage limits, escalation rules, and acceptable outputs—and it enables monitoring for change over time. When tool calls spike, permissions expand, escalations drop, or outputs drift, those are detectable signals rather than surprises. The same traces also separate root causes (model, prompt, tool, data, or governance), which is required to improve agents safely without widening blast radius.

Layer 6: Certification and Compliance — Trust But Verify

Certification turns an agent’s declared behavior into a test plan. The Agent Card and Agent Skill define the claims—purpose, allowed actions, required inputs/outputs, and operating boundaries—so certification can verify them with repeatable capability tests, safety tests, policy checks, and adversarial testing. The objective is to establish a measurable baseline and detect regressions when the model, prompt, tools, or data change.

In an enterprise, certification also scopes where an agent may run and with what authority. The same agent can be approved for internal advisory work but blocked from external execution, allowed on synthetic data but not production data, or permitted in one jurisdiction and restricted in another when policies differ. Compliance then becomes an integration problem: the agent must operate inside existing controls for access, approvals, logging, retention, and incident handling, with constraints and traceability designed in so audits rely on evidence from normal operation rather than after-the-fact reconstruction.

Layer 7: Governance and Lifecycle Management — Trust That Survives Change

Governance and lifecycle management exist because agent systems change continuously, and risk grows when that change is unmanaged. An agent should not run in production without a verified identity, a current Agent Card and Agent Skill, a named owner with operational responsibility, and a defined retirement path. The lifecycle includes onboarding, versioning, access management, and decommissioning, because unused or unowned agents are a common source of security and compliance exposure.

Ongoing governance is standard change control applied to agents: reviews are triggered when tool access expands, policies or methods change, escalation behavior shifts, or observed behavior deviates from expected bounds. Incident response must support rapid containment—halt the agent, revoke credentials, roll back versions—and factual reconstruction from logs and traces. Recertification must be tied to meaningful changes, so trust is maintained through controlled updates rather than assumed to persist indefinitely.

Lessons Learned

The trust gap blocking agent deployment is not primarily technical. Organizations already know how to manage identity, enforce access controls, maintain audit trails, and handle compliance for production systems. The problem is that most agent implementations skip these steps or treat them as future work. Teams focus on capability first and governance later, which works in the lab but fails at the security review. The lesson is straightforward: if you design agents without identity from the start, without enforceable boundaries on tools and data, and without structured logging and version control, you will rebuild them when production requirements arrive. Starting with trust requirements built in costs less than retrofitting them after the architecture is fixed.

Why This Matters

Agents are shifting from assistants that full participants in business. When an agent can query databases, update customer records, approve refunds, or route support tickets, it becomes part of operational infrastructure, and the organization becomes accountable for what it does, whether actions were authorized, and whether decisions can be explained under audit. Without explicit trust, this does not work.

This matters now because agents work in testing but most cannot deploy to production because they lack the governance controls required for systems with real authority. The framework presented here defines a practical path from prototype to trusted production system by applying established security and compliance principles to autonomous actors that make decisions, use tools, and change behavior when models or prompts update. Organizations that build these controls in from the start will deploy agents faster and with less risk than those that treat governance as something to retrofit later.

Conclusion

Trust is the difference between a promising demo and a production deployment. The framework described here is a starting point. Each enterprise is different in their implementation, but the considerations outlined here still apply. We think this is a structure for building agents that can be operated, audited, and governed like other enterprise systems. The goal is to close the gap that keeps agents in the lab by making trust measurable, enforceable, and maintainable over time. Organizations that apply these principles early will deploy agents faster and with more confidence than those that treat governance as an afterthought. The capability exists. What remains is making it trustworthy enough to use.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn or respond to this article. Questions and comments are welcome and encouraged!

***

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Agentic Process Automation: Next Generation Process Management

Today, business processes powered by RPA and BPA are brittle, constrained by ambiguity, edge cases and inconsistent data formats. Agentic Process Automation lets agents operate as full participants in business processes, executing bounded work under guardrails to fill the process whitespace between SaaS platforms.

—

Introduction

Most enterprise process automation disappoints because real business work is messy: it crosses siloed systems, depends on judgment, and breaks whenever policies, data formats, or exceptions change.

Agentic Process Automation (APA) is a new way of automating business processes using modern agents. APA new control model that preserves and build upon governed process flows, its stages, SLAs, approvals, and audit requirements, but instead moves detailed execution planning into runtime, where agents operate as bounded participants under explicit policy, identity, and tooling constraints.

APA is based upon a foundation of:

• Explicit knowledge engineering using structured process knowledge, rules, and context artifacts)

• A managed ecosystem of specialized agents with stable identity, naming, OAuth2/RBAC, secure communications, and full traceability, which we call Agentic Mesh

• Well defined and reusable skills (based upon “skill.md”, a skill is a small, packaged unit of execution capability that an agent can reliably invoke to do a specific kind of work)

• Standards such as A2A, MCP

In this article, we show how APA, backed by an standards-based and skills aware agentic mesh and explicit knowledge engineering, can plan, coordinate, and verify end-to-end execution while remaining auditable and safe.

Agentic Process Automation

Agentic Process Automation (APA): a standards-based approach to business process automation in which governed AI agents use explicit knowledge artifacts to plan, coordinate, and execute multi-step work across people and systems.

Figure 1: Agentic Process Automation Architecture

Agentic Process Automation is the process manager. It is where an organization defines its process stages, what “done” means at each stage, the required evidence, the approvals, the SLAs, and the audit record that must exist when the work moves forward. APA does not remove structure; it makes the structure executable by agents.

Within that process layer, agents do the work. An agent receives a case, interprets inputs, plans the next steps, and then executes them by calling the right tools and producing the required outputs. Different agents can own different work units such as intake, identity, KYC, provisioning so the end-to-end flow advances through clean handoffs with a structured state update rather than informal, brittle coordination.

APA relies on knowledge engineering to make that agent execution reliable. The “knowledge artifacts” are structured process knowledge: concepts and definitions, policies, rules and decision boundaries, and the minimum context required to perform a stage correctly. This is the prerequisite for consistent behavior: it tells the agent what counts as acceptable evidence, which policies apply, what exceptions exist, and what output format is required so downstream stages and reviewers can trust the result.

That execution runs inside a managed ecosystem we call Agentic Mesh. The mesh provides stable agent identity and naming, secure communications, and governed access to enterprise systems via OAuth2 and RBAC, so agents can only do what they are allowed to do. It also provides durability and traceability: work can be long-running, state can be preserved across steps, and every action can be reconstructed with “who did what, using which tool, under which policy.”

Agents invoke skills which are small, reusable units of execution that do one kind of work predictably, such as verifying an identity, screening a name, or creating an account record. Skills are the bridge between abstract process intent and concrete execution, and they are the main mechanism for reusing process knowledge across products, channels, and regions.

A “skill.md” file is the contract for one of those skills. It states what the skill is for, what inputs it expects, what outputs it must produce, and the constraints it must follow, so an agent can call it reliably and auditors can understand what it did. The result is repeatability: the same skill can be used in many processes, and improvements land in one place instead of being re-implemented repeatedly.

Last but definitely not least, APA becomes easier to scale when it leans on standards. A2A standardizes how agents exchange tasks, messages, and state across boundaries, while MCP standardizes how agents connect to tools and data sources. Together, these standards reduce bespoke integration work, increase portability, and make it practical to build a library of skills and governed agents that can be composed into many processes without rebuilding the plumbing each time.

Filling the Whitespace Between SaaS Platforms

Enterprise SaaS platforms like Salesforce, ServiceNow, Workday, and SAP cover the standardized slices of work that most organizations share. They excel at common support functions—tickets, HR workflows, CRM records, finance transactions—and taken together they account for roughly 20% of total business process value.

Figure 2 – Agentic Process Automation – Bridging SaaS

The remaining 80% of value is the work that makes a company itself: the cross-functional, policy-heavy, exception-prone processes that span multiple systems, teams, and vendors. This is where competitive advantage lives—how a firm sells, serves, fulfills, manages risk, and adapts to regulation or market shifts. It is also the “whitespace” between SaaS platforms, where organizations end up building bespoke connectors, handoffs, and glue logic to make end-to-end processes actually run.

Agentic Process Automation is aimed squarely at that 80%. Instead of treating each SaaS system as a silo, APA provides the execution layer that plans, coordinates, and moves work across them—using governed agents and explicit process knowledge to keep the process coherent from intake to completion. The result is that the unique, high-value work becomes easier to automate and improve, without having to rebuild the surrounding SaaS landscape.

Enabler: Knowledge Engineering

Knowledge engineering functions as the translation layer between enterprise reality and agent execution. The raw inputs that govern a business process are distributed across structured systems—CRM, ERP, service platforms, data catalogs, and semantic layers—and across unstructured or tacit sources such as SOPs, tickets, chat threads, emails, recordings, regulatory guidance, and expert interviews. These sources contain the definitions, constraints, and operational “gotchas” that determine whether a process is safe and compliant, but they are not organized in a form that an agent can reliably consume at runtime.

Figure 3: Knowledge Engineering and Agentic Process Automation

Agent-enabled knowledge engineering becomes a key enabler of Agentic Process Automation by turning “filling the context window” into an engineering discipline. Instead of treating context as an ad hoc prompt-building exercise, it defines how enterprise knowledge is captured, normalized, and packaged so agents can execute bounded work in a repeatable way. The objective is operational: produce Minimum Viable Context (MVC) that is sufficient for safe execution while remaining constrained enough to be stable under scale, change, and token limits.

Agent-enabled knowledge engineering converts the sprawl of enterprise knowledge into modular, testable artifacts designed for compilation. Concept Cards represent the stable meaning of the domain: entities, attributes, allowable states, canonical identifiers, reference data, and the relationships that support consistent interpretation across teams and systems. Policy Cards represent enforceable constraints: decision boundaries, required evidence, escalation triggers, approval requirements, and prohibitions tied to specific contexts. In APA terms, these artifacts supply the “what things mean” and “what rules apply” substrate that allows an agent to plan within guardrails rather than improvising from loosely related documents.

Those cards are then connected through a knowledge graph that functions as the semantic backbone for APA execution. The graph is an addressability and linkage layer that connects concepts to the policies that govern them and binds both back to their authoritative sources. This structure constrains retrieval and reduces ambiguity: identity concepts link to verification policies, risk entities link to escalation rules, and every linkage carries provenance. In practice, the knowledge graph is what makes MVC assembly tractable, because it provides deterministic pathways for selecting the right concepts and policies for a given stage without scanning the entire corpus.

At runtime, a context compiler acts as the control plane that converts this engineered knowledge base into an actionable MVC for the agent. A request—initiated by a user prompt or a system event—becomes an input to compilation, and the compiler selects and assembles the smallest set of concept and policy cards required to interpret the case correctly, execute permitted actions, and satisfy audit requirements. This compilation step is the APA hinge: it makes context delivery systematic and repeatable, which is a prerequisite for predictable behavior across many agents, many cases, and many process stages.

The compilation step also enforces the separation between durable knowledge and real-time facts, which is essential for APA in production settings. Definitions, policies, and procedures change, but on slower cadences than case evidence, account state, vendor responses, and risk signals. The compiler therefore pairs curated knowledge artifacts with targeted data acquisition, pulling only the required evidence to resolve the current task. This is where token budget awareness becomes an engineering constraint rather than a limitation: modularization (cards), linkage (graph), and selective assembly (compiler) ensure the agent receives bounded, policy-aligned context, allowing APA to scale without turning the context window into an uncontrolled dumping ground.

Enabler: Agentic Mesh

Agentic Process Automation requires more than capable agents. It requires an operating environment that makes agent plans safe, coherent, and operable when execution spans many stages, many tools, and many long-running cases. That environment is the enterprise-grade agent ecosystem: a shared layer that supplies stable primitives for identity, communication, control, and traceability so agent behavior remains bounded and repeatable under real-world variability.

Figure 4: Agentic Mesh and Agentic Process Automation

The ecosystem is built from three distinct layers, each with a different job. Enterprise-grade agents are the workers: they execute bounded units of work, produce artifacts, and drive cases forward. The ecosystem layer is the common substrate that provides common services required by every agent, standardizing naming, interaction patterns, policy enforcement, and lifecycle management. Vertical solutions become domain packages such as banking onboarding, claims, procurement where the specialized semantics and procedures vary, while the underlying rails remain consistent.

The capability set starts with the basics of distributed coordination: who is acting, and how they talk. Identity turns every agent and user into a first-class principal with stable identifiers that survive environments and show up uniformly in logs, permissions, and audit trails. A communications fabric provides the interaction backbone—requests, delegation, events, and status streams—so multi-agent work behaves like one system instead of a collection of point-to-point integrations. With A2A-style normalization, “task,” “status,” and “error” retain the same meaning even when transports differ.

Execution depends on controlled access to tools and durable state, so the next capabilities focus on how work touches the enterprise and persists. Tooling interfaces (such as MCP-style contracts) provide a governed bridge into systems of record, with explicit scopes and enforceable boundaries around what an agent may call and what evidence it must attach. Long-running sessions and conversational memory support the operational reality of approvals, timeouts, retries, and resumable progress. Shared workspaces act as the durable case file: evidence bundles, decision packets, and intermediate state remain available across handoffs and restarts.

Scaling also requires an engineering surface that makes the ecosystem buildable, repeatable, and maintainable. A marketplace makes capabilities discoverable so teams reuse agents and tools instead of cloning patterns and hard-coding endpoints. A control plane provides fleet-level governance—deployment, configuration, policy distribution, and runtime posture—so the platform can be operated with consistent controls. Creator workbenches close the loop by providing the build/test/observe cycle agents require, treating them as software components with instrumentation, test harnesses, and versioned releases.

Those capabilities exist to deliver enterprise attributes that are evaluated in production, not in demos. Secure and zero-trust operation means every action is bound to an authenticated identity and constrained by least-privilege authorization, with enforcement at the platform boundary rather than in handwritten conventions. The result is predictable constraint: even if an agent misinterprets intent, the allowed action space remains narrow, observable, and revocable.

Visibility and accountability form the next set of attributes because enterprises need to manage agents as operational assets. Discoverability ensures agents, tools, and their contracts can be found and understood as part of a catalog rather than tribal knowledge. Observability provides measurable signals across execution—latency, error rates, throughput, and failure modes—so operations teams can detect drift and regressions. Explainability and traceability add the forensic layer, enabling reconstruction across agents and tools: which principal acted, what evidence was used, which policy boundary governed the step, and what side effects occurred.

The final attributes describe whether the system holds up under load and failure. Reliability is defined as correctness under partial failure: durable task semantics, safe retries, and resumable execution that avoids duplicate side effects. Operability means the ecosystem can be controlled at fleet scale through standardized telemetry and consistent management surfaces. Trust and scalability emerge when these guarantees remain intact as the number of agents and processes grows—so adoption increases throughput and coverage rather than increasing integration debt and control risk.

Now, all of this may seem overwhelming or complicated – the truth is that each of these components, capabilities, and attributes are useful but not mandatory. You need to pick what is important to your enterprise’s risk appetite.

Example: Bank Account Open Process

Bank account opening is a useful reference process because it looks linear at the surface, yet it is implemented as a chain of interpretation-heavy stages that span multiple systems, policies, and evidence types. APA succeeds here when the work is made explicit and reusable: knowledge engineering captures the concepts, rules, decision boundaries, and evidence requirements for each stage, and packages repeatable actions as well-defined skills that agents can invoke reliably. Under the hood, the agents operate inside a lightly managed mesh—stable identity, governed tool access, durable workspace state, long-running task handling, and traceability—so each stage can be executed as a bounded work unit: the agent receives the minimum context it needs, calls the right skills, gathers required facts, takes permitted actions, and produces an auditable case packet for downstream stages.

Application Intake

Intake becomes a normalization and case-construction step, where an intake agent converts mixed-format inputs—forms, attachments, free text, and external documents—into a structured dossier with provenance. Knowledge engineering provides the intake ontology (field definitions, document types, validation rules) and the intake policies (what is mandatory, what can be deferred, what triggers escalation). Those requirements are expressed through skills so the agent is executing a known playbook rather than inventing a method. The mesh layer adds the basics that make this safe and repeatable: authenticated access to source systems and document services, a shared workspace to hold the evolving case packet, and traceable outputs that distinguish what was provided, what was inferred, and what remains unknown.

Identity Verification

Identity verification is treated as evidence assembly under explicit decision boundaries rather than a single pass/fail event. Knowledge engineering defines identity concepts (name/address normalization, acceptable ID types, matching tolerances, jurisdiction-specific rules) and the policies that govern what evidence is sufficient and when uncertainty must be escalated. The agent then applies those requirements via a small set of skills—“verify_id_document,” “resolve_identity_record,” “reconcile_mismatches,” “request_additional_evidence”—each producing structured results that can be reviewed. The mesh layer provides governed calls to internal records and third-party verification services, durable storage of artifacts and outcomes in the workspace, and traceability that ties each reconciliation step back to the evidence and policy that justified it.

KYC Processing

KYC processing becomes a policy-governed investigation that turns noisy signals into structured decisions. Knowledge engineering supplies the semantic layer for entities, watchlist concepts, risk factors, thresholds, and required documentation, along with the due diligence rules that determine what must be checked and what triggers escalation. Those checks are executed through reusable skills so the same logic can be applied consistently across products and channels. The mesh layer keeps the work coherent across vendors and internal systems, preserves the evidence and rationale in a durable case record, and ensures the final output is audit-ready without reconstructing the story from scattered logs.

Account Setup and Initial Deposit

Provisioning and initial funding are tool-driven tasks with bounded recovery behavior and durable state. Knowledge engineering defines the procedural requirements (product configuration, required fields, funding rails, holds, constraints by channel) and the decision boundaries that govern retries, fallbacks, and approvals. Skills encapsulate those steps so they are repeatable and testable. The mesh layer contributes least-privilege access to core systems, long-running task semantics for timeouts and partial completion, and a workspace-backed execution record that captures what was attempted, what succeeded, what failed, and what pending state or compensating action remains.

Notifications, Statements, and Ongoing Servicing

Ongoing servicing is handled as constrained, policy-aware interaction tied to a durable case state rather than isolated messages. Knowledge engineering defines service intents, permitted actions, and the policies that govern what can be done self-service, what requires approval, and what triggers risk review, plus the evidence needed to complete common requests. Skills provide consistent execution paths across channels and teams. The mesh layer provides authenticated communication channels, governed tool access for updates, resumable workspace context so conversations and cases don’t fragment, and traceability that records what was communicated, what was changed, and which policy boundary authorized the action.

Lessons Learned

APA rises or falls on knowledge engineering, because knowledge is the fuel that turns “agent autonomy” into reliable execution. When concepts, policies, procedures, and evidence requirements are captured as modular artifacts—definitions that don’t drift, decision boundaries that are explicit, and provenance that is preserved—agents can plan and act with discipline rather than improvisation. In practice, this is what makes Minimum Viable Context (MVC) real: a context compiler can assemble the smallest set of concept and policy cards needed for a specific stage and case posture, so the agent consistently interprets inputs, gathers the right evidence, and produces outputs that map cleanly to audit and control requirements.

APA thrives when it is built on standards, because standards turn one-off integrations into reusable capabilities. A shared interaction model for agent-to-agent and agent-to-tool work—paired with consistent identity, authorization, and message semantics—reduces friction at every handoff: fewer bespoke adapters, fewer edge-condition misunderstandings, and fewer “special cases” that quietly multiply over time. The payoff is both efficiency and effectiveness: efficiency because teams can compose and reuse agents, tools, and knowledge artifacts across processes, and effectiveness because outcomes become more consistent, traceable, and improvable as policies and knowledge evolve without forcing a redesign of the entire automation.

Why This Matters

APA matters because it turns automation into a repeatable operating capability rather than a one-off project. When agents can interpret intent, assemble the right knowledge, and execute across systems under clear policies, organizations stop treating each workflow as bespoke engineering and start treating execution as composition. That shift is the foundation for cost control: fewer hand-built integrations, more reusable components, and a smaller marginal cost to automate the next process step, variant, or exception. Over time, the savings compound because improvements land in shared knowledge artifacts and standardized interfaces, not in scattered scripts that have to be rediscovered and reworked.

It also matters because APA is built for speed and agility. Markets, regulations, products, and internal policies change continuously; the organizations that win are the ones that can adapt without pausing to rebuild their automation stack. With APA, change can be absorbed by updating the governing knowledge—policies, decision criteria, required evidence, and system mappings—so agents can execute the new rules immediately across many processes. The result is faster cycle times for operations and for change itself: teams can launch new products, adjust controls, or expand into new channels with less lead time, because the execution layer is designed to recompile context and behavior as standards and knowledge evolve.

Conclusion

Agentic Process Automation reframes enterprise automation around the hard part of real work: the whitespace between SaaS platforms, the messy middle where inputs are incomplete, records disagree, policies are contextual, and exceptions are normal. What is clear is that the next gains in business process automation will come less from drawing better workflows and more from embedding agents directly into business processes where judgment is executed, constrained, and audited.

That shift changes what “automation” means in an enterprise: from brittle RPA/BPA tools and scripts that follow a predefined route to Agentic Process Automation where agents can plan within guardrails, gather the right evidence, ask for what’s missing, and escalate only when policy requires it—leaving an audit-ready trail either way. Agentic Process automation is a new control surface for process execution, one that treats ambiguity as a design input and makes exception handling measurable, governable, and improvable.

***

This article was written in collaboration with John Miller. Feel free to reach out and connect with the authors - Eric Broda and John Miller on LinkedIn or respond to this article. Questions and comments are welcome and encouraged!

If you liked this article, then you may be interested in a few more things...

• Looking for more?
  👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

  🎧 Follow co-hosts John Miller and Eric Broda on The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.