Insight Editions · No. 32
The Agentic Enterprise
How AI Agents Are Transforming Business
Babak Hodjat and Antoine Blondeau
Hodjat and Blondeau explain how enterprises can deploy coordinated AI agents, integrate them with business systems, and govern their actions through human oversight.
A study guide to The Agentic Enterprise by Babak Hodjat and Antoine Blondeau. Shared free for personal reading; not for sale and not endorsed by the authors or publishers. Please read and buy the original.
Overview
Each chapter keeps the authors' order, numbers, frameworks and cases, then adds boxed October 2026 updates and critical lenses where the source is thin, vendor-sourced or overtaken by events.
The Book in Brief
Spine of the book.
- Thesis. Hodjat and Blondeau argue that the gap between generative-AI demos and production is an architecture, governance and trust problem, not a model problem. Their answer is the multi-agent enterprise: many specialised, LLM-wrapped agents coordinated by an accountable orchestrator, with humans setting goals and owning risk.
- Pedigree. The two have worked together since 1999, when Blondeau met Hodjat's Dejima team in San Jose. Dejima's agent-oriented natural-language technology powered DARPA's CALO project and the Siri spin-off sold to Apple; the pair later cofounded Sentient Technologies with Adam Cheyer. Hodjat is now chief AI officer at Cognizant, which matters for reading the cases.
- Why now (Preface). Blondeau's claim is that natural-language understanding became a solved problem after ChatGPT in late 2022, and that since most human work is language, plugging LLMs into APIs and command lines makes "any and every human-designed workflow" a candidate for agents. His worked example is a board budget refresh that Claude Cowork, OpenAI Codex or Google Antigravity can gather, chase, recompute, check against guidelines and format into a deck.
- What the book is not. It is not a step-by-step implementation guide and writes no prompts, and it does not argue for or against agentic AI on philosophical grounds; the authors leave the wider societal debate to others.
- Foreword. Bouée, former CEO of Roland Berger, recalls his 2016 novel The Fall of the Human Empire, whose chapter "2026: The Golden Age" imagined machines coordinating industrial networks. He praises three things: the book's honesty about LLM limits, its bridge between strategy and mechanism, and its closing frame of a World Wide Agentic Web. He cites Allianz cutting claims settlement from thirty days to three and Franklin Templeton scaling agents.
- Part I (Ch 1-4). History from expert systems and RPA to agents; the business case in three value layers and six readiness dimensions; a catalogue of sector applications; ROI measured in units of value each firm defines, five risk types and build-versus-buy.
- Part II (Ch 5-6). Mechanics: protocols and skills as plain text, grounding, AAOSA coordination, triggers, fine-tuning on logged data, memory and planning; then an agentic development life cycle with central registration, autonomy checks, trust metrics, UX and testing.
- Part III (Ch 7-8). Trust: lenses of autonomy, brakes outside the context window, a named human owner per behaviour space, nine mitigation levers. Scale: encapsulation, neutrality, upgradeability, ownership and expandability through MCP and agent-to-agent protocols.
- Part IV (Ch 9). Multi-agency is inevitable; vibe agentifying; a client-pays agentic web; a 50,000-person hackathon judged by agents; agent-only marketplaces, robots and two superintelligence scenarios.
Figure 0. The book's argument from the engineering definition of an agent to the open questions of Chapter 9; the bottom row is the destination and what remains unresolved.
Chapter Map
| Ch | Title | In one line |
|---|---|---|
| Intro | Agents, Old and New | Agents are an engineering concept; AI has come full circle back to multi-agent systems |
| 1 | From Automation to Agents | Expert systems and RPA to agents; twelve benefits; three controls on autonomy; LLM and code split |
| 2 | The Business Case for Agentic AI | Three converging forces; three value layers; code-review economics; six readiness dimensions |
| 3 | High-Impact Enterprise Applications | SDLC, migration, five sectors, six cross-functional uses; agent layer decouples modernisation |
| 4 | Evaluating ROI and Risks | DBS, JPMC, Siemens; define your own units of value; five risk types; hybrid build and buy |
| 5 | Core Capabilities and Technical Foundations | Protocols and skills as text; grounding; AAOSA and CRUSE; triggers; data outlives the model |
| 6 | Designing Agentic Systems | Your own ADLC; build in departments, govern centrally; autonomy checks; trust as running metric |
| 7 | Building Trustworthy Systems | Trust lenses; brakes outside the context; named owners; nine levers in three pillars |
| 8 | Scaling Without Lock-In | Five themes: encapsulate, stay neutral, upgrade, balance ownership, expand via MCP and A2A |
| 9 | The Road Ahead for Agentic Enterprises | Inevitable multi-agency; agentic web; hackathon judged by agents; two scenarios |
- Babak Hodjat. Chief AI officer at Cognizant and head of its AI Lab; primary inventor of Dejima's agent-oriented technology behind the original Siri; former cofounder and CEO of Sentient; 41 US AI patents; PhD from Kyushu University.
- Antoine Blondeau. Cofounder and managing partner of Alpha Intelligence Capital (investor in OpenAI among others); former CEO of Dejima and cofounder and CEO of Sentient Technologies; board chair of Crypto.com; working in AI for about 28 years.
Introduction: Agents, Old and New
Humans are agents: we set our own goals, plan, act and learn from feedback. The opening argument of Hodjat and Blondeau is that AI agents are an engineering concept rather than a natural kind, that AI has come full circle back to multi-agent systems, and that the enterprise of the future will be a network of LLM-wrapped functions with humans as the final arbiters of risk.
Agency means being able to postulate a goal of your own, devise a plan and execute it, then adjust from feedback. The concept of the AI agent goes back to Alan Turing's 1950 paper "Computing Machinery and Intelligence", which describes machines that perceive input and act toward goals. Turing said nothing about the environment, and the authors read this as an assumption that the agent would act unconstrained in the world. That world has since grown: the internet sits beside the physical world, and programmers can build any virtual world they like.
The definition raises hard questions the authors pose and then answer. Who sets the goals? Agents can choose sub-goals at low levels, but somewhere in the hierarchy there must be an uber-goal that directs the highest agents, and even "survival" would be a goal humans engineered in. What does the agent perceive? It cannot sense the whole world, so humans design its sensors around what they think matters. The conclusion: AI agents are an engineering concept, and most of the engineering still falls on humans.
A brief history: from general AI to agents and back
History arc from rules to acting agents.
Once agents existed, people asked what happens when your agent meets someone else's: collaborate or compete, and in what shared language? The authors built an early hierarchical, non-LLM natural language interface on this principle; a similar technology sat inside the original pre-Apple Siri.
AI's full circle (after Figure I-2): the failure of general AI produced agents, agents produced distributed AI, deep learning is distributed AI, and LLMs are deep learning. The authors argue a single LLM cannot be generally intelligent unless it is built as a multi-agent system.
Why generative AI revives agents
Agent loop the book returns to.
Why LLMs revive agents.
The emergent capability that matters most is natural language understanding. Translation and language processing, the first non-numerical problems ever given to computers and long thought very hard, are now effectively solved. Language is humanity's "high conceptual bandwidth" protocol, and because machines now "get" it, we have a universal human-to-machine protocol and, as a side effect, a universal machine-to-machine protocol that humans can read. Ambiguity is the price, and the book returns to it later.
The engineering payoff the authors expect is less brittle software. If an agent owns a function and maps intent to the underlying API calls, changing the API or swapping in a different vendor costs far less. If responsibilities stay encapsulated, new capabilities can join an existing agent network with little or no re-engineering.
Why not just scale one giant model? Two reasons. First, LLMs are pretrained, so they cannot easily change their world model online, and they are trained on public data, so they know nothing of a firm's proprietary domain without an engineered harness. Second, an LLM needs a system prompt (repeated with every input) to take a role at all: a job description, declared expertise, responsibilities. In the 1990s we shrank the problem because models were too weak; now we shrink it because models are too powerful and flexible and must be contained in specific roles.
- LLM-based agent. An LLM plus code that actuates its intentions; in richer systems the code adds planning task lists and memory.
- Agentic harness. Any code or prompt written so an LLM can complete a task autonomously.
- Meta-harness. A system that creates or improves harnesses automatically, sometimes agentically.
- Agent (formal). A generative LLM wrapped around a module, function, service or database, so users reach that functionality in natural language.
- Model vs agent. A model is a transformation function, data in and data out. An agent is at least an LLM enabled to request tool calls.
Multi-agent systems by example
Multi-agent example roles.
The authors build up from simple to enterprise-wide in five steps.
- Database agent. Asked "What is the average weight of penguins on Biscoe?", an LLM may guess. Better: give it the schema and SQL dialect, let it write the query, and have helper code pattern-match that intent, run the call and hand the result back for a natural-language answer.
- RAG as two agents. Documents are summarised offline and stored with their embeddings (numeric vectors capturing meaning) in a vector database; distance between vectors measures similarity, so search works by meaning rather than by matching words. One agent summarises offline; another answers queries.
- Planner, actuator, critic. For a holiday, a planning agent drafts options, an actuation agent calls services such as Expedia or Hotels.com for real prices and dates, and a critic agent checks plausibility (is that flight connection reasonable?) and sends bad plans back.
- Intent logging and safeguards. Because the agent "understands" its context, it can log the why and what of each step, and a safeguard agent loaded with ethics, compliance or regulatory rules can watch and intervene.
- Natural language makes this robust to changes in call syntax.
Figure I-8 from the book. A model generates predictions (left); an agent wraps an LLM and code with memory, context, tools, planning, goals and other agents (right); a multi-agent system coordinates specialists under a project manager agent (bottom).
| Dimension | Model (LLM) | Agent |
|---|---|---|
| What it is | Transformation function | LLM plus code plus tools |
| Coding task | Writes code; you paste and press run | Writes, runs in a container, observes, fixes |
| Benchmarks | Lower success alone | Same LLM scores higher inside a coding agent |
| Context | Only what is in the prompt | Memory, planning, goals, other agents |
Multi-agent AI needs agents that communicate and coordinate, within a team (collaboration) or across teams with varying trust and even adversity. The authors close on responsibility: unless a seismic cultural shift grants agents some personhood, humans remain the sole bearers of responsibility, so multi-agency must be designed with humans as the ultimate arbiters and approvers of higher-risk behaviour.
1. From Automation to Agents: The Evolution of Enterprise AI
Enterprise AI moved from expert systems and RPA, through the ChatGPT chatbot era, to agents. The chapter's case is that agents are an engineering discipline, that specialised multi-agent systems beat one do-everything agent on reliability, context, cost and governance, and that humans must keep designing the checks because LLMs lack metacognition.
Before LLMs
Before LLMs: brittle pipelines.
Early enterprise AI meant rule-based expert systems built on human-designed taxonomies, and RPA (robotic process automation) that scripted steps of rigid processes. MYCIN, built at Stanford in the early 1970s, diagnosed bacterial infections and recommended treatment; Blue Prism, launched in 2001, automated structured back-office work such as data entry and claims in banking, insurance and government. Deep learning then promised to find patterns hidden from regression and classical ML.
The authors stress that applied AI used to be far more varied: symbolic regression, evolutionary optimisation, predicate logic, random forests. Some of these are no longer even called AI, and deep learning is now labelled "traditional" ML. They acknowledge this breadth, then define agents narrowly for the book: always an LLM, wrapped in a program that actuates its intent.
The ChatGPT effect
Order-of-magnitude adoption gap from chat to prod agents.
November 2022: OpenAI released ChatGPT, and a mass audience saw how general AI could be. Its chatbot form shaped deployment for years: retrieval, support, FAQs, knowledge bases. Three worries held businesses back:
- Confabulation. Models invent facts ("hallucination").
- Inconsistency. Outputs are sampled from a probability distribution, so the same input can give different answers.
- Data security. The strongest models were hosted by OpenAI, Google and Anthropic, and OpenAI at first said it would train on user queries (later retracted).
So firms chose low-risk, high-return uses and barely scratched the surface: outside personal productivity, mainly RAG retrieval and coding copilots. ROI disappointed. The authors offer two excuses: useful LLMs date only from late 2022 and most experimentation began in 2024, and labs funded to build AGI encouraged the belief that a monolithic model would work out of the box. It took the world a year or two to learn that applied AI must be engineered and customised to the use case.
Why engineer multi-agent systems
Why engineer multi-agent systems.
The chapter's core is a list of reasons to split work across specialised agents rather than trust one reasoning model.
- Reasoning ruts. Fine-tuning on chain of thought (CoT) fixes a "default mode" of reasoning. A coding model may decide a bug is a dependency problem and loop through reinstalls forever; agents specialised in different parts of the stack break the loop.
- Engineering territory. Moving from models to agents means design, verification, testing, monitoring and operation; for the same use case these separate safe from risky. Modularity brings reuse, specialisation, divide and conquer.
- No one LLM fits all. Smaller specialised models can serve specialised agents, run on premises for sensitive data, or be replaced by plain software.
- Not just transactional. Agents can wake on non-user events and run continuously: coding agents that react to review comments and merges; telco agents doing load balancing and incident recovery on network nodes.
- Interoperability. Vendors ship their own agents; enterprises must connect them to each other and to homegrown ones.
- Per-agent fine-tuning. Label data for each agent's job and tune separately, impossible with a single generalist.
- Context discipline. LLMs do not learn from lived experience; like the hero of Memento they must be reminded of everything each time. System prompt, dialogue history, memory and tool descriptions all consume context tokens (a token is roughly a word), and fidelity drops as context grows. Narrow agents need less.
- Scale and performance. A position paper argued finer decomposition is needed for efficiency at scale, and some evidence suggests scaling laws appear in systems of more than 1,000 cooperating agents. If added reliability lets cheaper models do the job, cost falls.
- Tool granularity. An agent with raw command-line control of a container is general but opaque (like reading assembler instead of a high-level language) and can cost up to 45 times more than a multi-agent system given fewer, higher-order tools.
- Parallel speed. Transformers slow sharply with input length; split context and parallel calls cut latency and cost.
Agentified applications: twelve benefits
Benefits grouped for architecture talks.
The motivating case is the intranet search box. Each departmental app has its own search; agents (perhaps RAG-based) can augment each, but users should not retype a query in the IT app once the intranet box has found it relevant. A top agent coordinates with app agents and presents one chat interface.
| Benefit | What the authors mean |
|---|---|
| Intent logging | Agents log why they act, unlike terse, voluminous software logs |
| Robust communication | Intent-based, often natural-language calls ease integration |
| Safeguard agents | Monitors check each agent for responsible-AI compliance |
| Modularity | Develop, deploy and scale each agent independently |
| Upgradeability | LLM maps intent to new APIs, cutting manual rewiring |
| Interoperability | One interface over diverse systems |
| Specialisation | Each agent optimised for one function |
| Fault tolerance | One failed agent or backend need not stop the system |
| Data handling | Process locally, send only what matters; agents front unconsolidated data |
| Resource management | Adjust operations to load and system state |
| Extensibility | Add or modify agents with little disruption |
| Breaking silos | Agents operate overlapping modules for the user and merge answers |
The cost: an agent's "brain" is an opaque neural network, prone to hallucination and to misreading ambiguous language, so what we gain in robustness we can lose in consistency.
Three controls on autonomy
Autonomy dial.
- Rules around the LLM. Wrap the agent in deterministic code that limits when it may use non-deterministic reasoning, or invert it so the LLM decides when to hand over to human-defined rules.
- LLM uncertainty. Sample the range of outputs for the same input to estimate confidence, then set a threshold: above it, trust the LLM; below it, fall back to rules or a human. The authors call this future-proof because the threshold survives model upgrades.
- Safeguard agents. One or more agents judge whether another agent's proposed action is acceptable.
Testing must differ from traditional software, but organisations have tested human-driven workflows since industrialisation. Nobody asks one engineer to write a whole CRM; a team of agents for project management, front end, back end and QA is likelier to succeed than one agent.
The LLM-and-code duality (after Figure 1-2): judgement goes to the LLM, consistency to code, and sly_data travels between agents through code without passing through any model.
The LLM and code split
LLM versus code split.
A modern agent is an LLM plus code. Most systems pass tool calls straight through; the Model Context Protocol (MCP), now a de facto standard, lets agents discover and call APIs without manual integration. Some systems let developers run code before tools are called. This duality is the first design decision:
- Give the LLM tasks needing reasoning, robust reading of unstructured input, or unstructured output: the "knowledge-worker-in-a-box".
- Give the code rigid rules that must apply consistently.
- Use sly_data, a data structure handled by the code part and passed between agents through code, so it need not touch any LLM.
Beyond technique, the authors see a need for governance among agents and between agents and humans, much as human organisations set rules for how teams interact.
Multi-agent organisations
Multi-agent organisation shapes.
Four benefits over a know-it-all agent:
- Flexibility in engineering. Encapsulated responsibilities plus distributed coordination (e.g. AAOSA, Chapter 5) let you plug in new sub-networks without re-engineering.
- Safeguarding. Pairing an agent with a safeguard agent works better than telling one agent to "be careful".
- Reliability. Narrow agents confabulate less.
- Broader LLM choice. Big models are expensive, slow and mostly hosted; small ones are cheap, fast, self-hostable and easier to fine-tune. Even million-token contexts strain a single all-purpose agent, and narrow agents also face simpler output demands.
More agents mean more cost and latency, so granularity is a balance. Once a system runs in production or a sandbox, human auditors can label usage as acceptable or not and that data can fine-tune each agent.
Their answer is resilience through distribution: modular, redundant agents with checks and balances, rule-based and human fallbacks, built and tested incrementally in sandboxes before joining the live network. This design also leaves room for regulators to mandate third-party agents for critical, risky operations.
2. The Business Case for Agentic AI
An engineering argument is not a business case. Value comes in three layers, from cheaper tasks to better outcomes to new business models, and leaders should rate their readiness on six dimensions before they commit.
ChatGPT raised awareness of AI as nothing before, and three concerns followed. Bias and hallucination undermined output quality. Compute and environmental cost worried people, and the authors concede agentic AI makes this worse through orchestration overhead and many more LLM calls. Financial analysts doubted returns on the huge LLM investment. The authors claim agentic AI answers the first concern (guardrails and system design) and the third (goal-oriented outcomes with measurable ROI); the environmental cost is a shared problem for efficiency gains, hardware and responsible deployment.
Three converging forces
Three converging forces.
- Technology past the inflection point. Foundation models and orchestration run agents autonomously in customer service, supply chain and compliance, and already run key processes in insurance (claims, underwriting) and banking, where regulators guard customers and systemic stability. Cloud-native APIs and secure model hosting matured fast.
- Economic pressure. Organisations have been through waves of IT automation, most recently RPA, which handled scripted tasks rigidly. Some RPA vendors even called their bots "agents". Agentic AI adds what RPA lacked: goal orientation, autonomy and adaptability, triage with escalation to humans, and orchestration across agents and systems.
- Organisational readiness. After the "wow effect" came wait and see, then a flurry of POCs that rarely reached production. That period was not wasted: leaders now see AI as inevitable, and many built data governance and MLOps foundations.
Decision velocity is the new lever: sensing context, weighing options and acting across systems in near real time, without a human handoff at each step. Front-office work changes too. Artisan, a San Francisco start-up, sells an agentic sales development representative (SDR) that scans signals (industry, software stack, hiring, funding rounds) to rank B2B accounts by readiness to buy, then runs personalised multistep email and social outreach. The competitive point: once rivals reroute supply chains, reprice offers or "saturate the best prospects" in minutes, a firm needing days of manual coordination pays a growing competitive penalty; inaction costs structurally slower decisions and lost customers.
Franklin Templeton moved from pilots with Wand AI to production agents across departments, starting in investment teams, with agents expected in key workflows (research, operations, transformation) by 2026, "underpinned by rigorous governance and control frameworks".
Strategic value versus tactical automation
Tactical versus strategic value.
ROI then depends on discovering context, choosing the "next best action", and building adaptive personalisation and continuous optimisation.
The three value layers. Each builds on the one below; layer 3 is still nascent for almost every organisation.
- Layer 1, operational productivity. Faster tasks at lower unit cost: invoices, data entry, ticket routing, claims intake. Agents add flexibility on exceptions. Examples: Allianz straight-through claims; Vamstar automating health-care procurement RFP submissions from weeks to hours.
- Layer 2, outcome quality and resilience. Better, more consistent decisions across domains under many constraints, plus decisions grounded in encoded, logged, traceable, reproducible workflows. Allianz's Otera agents run under "governed autonomy" with operators able to trace and override.
- Layer 3, adaptive enterprise-wide systems. Systems that learn in context and open new business models and value pools. Nascent; build toward it now.
Code review: the economics of engineering
Where engineering time goes; agents hit review and ops too.
A large telecom deployed multi-agent code review in its SDLC. Specialist agents check related issue-tracker tickets, consult the coding wiki, validate against quality and compliance specs, and synthesise prior human review comments on similar changes, so the review is structured before a human sees it.
Mistral AI CEO Arthur Mensch told a French parliamentary commission on digital vulnerabilities that his engineers "no longer write code" in the traditional sense, with productivity reportedly doubling in a few months and sometimes rising by an order of magnitude. The authors' conclusion: agentic systems change throughput, quality and time-to-market, and the gains compound across a product portfolio.
To calibrate, even the best tools, Anthropic's Claude Cowork (coordinating subagents across files, browsers and apps) and open-source OpenClaw (dozens of enterprise integrations, persistent memory), work at layers 1 and 2. Layer 3 shows only at the frontier: agentic commerce where agents transact with agents and firms must market to machines (McKinsey, Oct 2025), and early use of multi-agent systems to model competitive scenarios. IDC predicts that by 2026, 70% of CEOs of the 2,000 largest firms will judge AI ROI on growth rather than cost, and that 60% of new digital economic value by 2030 will come from firms scaling AI now.
Where agents fit, and where they do not
Fit ladder for agent use cases.
| Good fit | Poor fit or unacceptable risk |
|---|---|
| Customer support: agents resolve issues proactively instead of escalating frustrated users | Subjective judgement: "I like this jacket, but I want the fabric softer" |
| Supply chain: reroute shipments, adjust inventory dynamically | Tacit, fragmented information: M&A negotiations, big credit calls on opaque counterparties, crises where facts live in people's heads |
| Compliance: watch regulatory change, self-audit continuously | High stakes: a misread compliance rule risking a multimillion-dollar fine; settings on a life-support device |
Six dimensions of readiness
Six readiness dimensions.
Rate each with a red/amber/green score (not retrieval-augmented generation): red behind, amber progressing, green on top or leading. The scores set priorities and sequence investment.
| Dimension | Questions leaders should answer |
|---|---|
| Leadership alignment | Do we grasp agentic concepts as opportunity and threat? Which pain points are worth it? Where does autonomy end and human intervention begin? |
| Technical infrastructure | Do we have data, MLOps and APIs? Can we proceed with imperfect parts? What gaps are non-negotiable? |
| Governance and risk | Documented principles on autonomy vs augmentation? How enforced and monitored? Which committee, and who is accountable when agents act alone? |
| Architecture | How to design modular, orchestrated systems that work with legacy? What to modernise first under budget limits? |
| Technical resources | In-house skills to design, learn from feedback and iterate? Skills to understand the models and deploy smoothly? |
| Change management | Talent, cultural agility, risk appetite? Readiness to evolve roles? What does managing humans and agents as one "workforce" mean? |
The payoff
Payoff path from pilot to compound ROI.
Two summary points: maturity (agentic AI is now a mainstream enabler, not an experimental add-on) and opportunity (strategic, not merely tactical, impact, moving from efficiency to effectiveness and adaptiveness). Leaders must assess what they gain by adopting, and what they risk by not. Readiness work should be paced and practical: be explicit about where agents help, set guardrails, and keep options open as the technology moves.
3. High-Impact Enterprise Applications
This is the book's catalogue chapter: a tour of multi-agent systems that the authors say have all been built, and some deployed, mostly on Cognizant's open-source Neuro SAN platform. It moves from software engineering and legacy migration through five sectors and six cross-functional uses, then argues that an agent layer is itself a way to future-proof messy legacy estates.
The opening claim is broad: runtime cost, quality limits and regulation aside, most applications, processes and organisational systems can be considered for agentic augmentation, and benchmarks such as VAKRA and multi-stakeholder negotiation tests are emerging to compare agentic systems across domains. Most examples were "vibed" on Neuro SAN, which the authors recommend to less technical readers, but they note the same systems can be built on hyperscaler and LLM-vendor platforms or open-source LangGraph and CrewAI.
Agentic software development life cycle
Agentic SDLC loop.
LLMs trained on public code can find bugs without running the code, an ability that emerges from next-token prediction alone. The decisive observation: wrap the same LLM in an agent with a tool to run its code in a container, and it scores higher on the same coding benchmark, because runtime results feed back and the model iterates before answering. The agent version of a model, given the right tools, codes better than the model alone.
- Coding copilots. Write snippets from prompts or comments, with a chat sidebar for consultation.
- Vibe coding systems (generative development harnesses). Introduced in 2025; the programmer describes the project and the agent writes the code iteratively, cutting or removing hand-written code.
- Autonomous coding agents. Hold roles on the team (test generation, code review), pick up tickets from the kanban board and move them to pull requests. Two or more of these and you have a multi-agent SDLC (not to be confused with the ADLC, the life cycle for building agents, in Chapter 6).
The book's Figure 3-1 maps a ten-step pipeline (epic creation, tech design, epic elaboration, local development, merge request, build-test-package, artifact publish, non-production deployment, production deployment, release) with its quality gates (design review, pre-commit hooks, MR review, unit and contract tests, code quality, SAST, SCA, SIT, performance, DAST, observability, rollback). It marks six agentic insertion points: local development encapsulation (onboarding, throughput), test automation and property-based testing (less defect leakage, faster test cycles), AI merge reviews, accelerated GitLab migration and autonomous CI fixes.
The advice is incremental: SDLCs are tailored, so start with steps less central to core operations. Code review (agents for tickets, wiki, quality and compliance specs, and prior reviewer comments; see Chapter 2's telco) and test-case generation come first. Once sandbox-tested, these subnetworks plug into a broader SDLC network that coordinates several of them for one complex command, with a slash (/) denoting calls to other agent networks. Build the broad system early and add grounded, verified subnetworks as they mature.
Code and app migration
Migration with agents.
Legacy business apps need upgrades, and migration is costly, slow and manual. Documentation is thin or absent, critical logic and dependencies surface late and cause rework, and manual reverse engineering at scale is error-prone, so conventional approaches miss timelines while trying to keep accuracy, traceability and functional parity. First attempts with LLMs disappointed: limited context windows forced code in slice by slice, the model never grasped the whole system, and the tools degraded into code assistants for human migrators.
The agentic fix mirrors the legacy system's hierarchical blueprint. A top agent holds the system's overall purpose and orchestrates narrower agents. The system first distils legacy code into an intermediate representation (IR), rich in natural-language explanation, then uses it as the template for target code or configuration. The IR raises migration quality and, as a byproduct, documents the system for future enhancements and migrations, echoing model-driven modernisation research (Böhm et al.).
Figure 3-5 from the book. Agentic effort as a share of manual effort (100%) by phase in the SAP BO to Power BI migration: reverse engineering 29%, transition 15%, detailed design 42%, but HLD 83% and unit testing 90%.
The chart repays a close look: agents save most where work is reading and transcribing legacy logic (reverse engineering, transition) and least in high-level design and unit testing, where human judgement and verification still dominate.
Sector-specific examples
Sector vignettes mapped.
Firms differ by their processes, so agentic systems must be tailored to the domain and sometimes to the single company whose process is its edge.
| Sector | System | Design point |
|---|---|---|
| Retail (front) | Support line spanning departments | Ends transfers between silos that keep callers on hold |
| Retail (back) | Department-store network: supply chain, loyalty, fraud, returns, pricing, campaigns, reporting, CX | Many agents author one answer; invisible to the user |
| Telco | Hierarchy with leaf agents on network nodes | Proactive, local, low-latency; on-prem open-source LLMs |
| Agriculture | Farm leaf agents reporting via region and state | Same pattern, slower decision cycle |
| Banking | Fraud and disputes as agentic RPA (APA) | Agents replace RPA nodes; outcome-based, explainable |
| Health care | Therapy supervision panel | Agents per therapeutic school produce a joint plan |
Telco shows a pattern beyond query and response. Leaf agents run on the network node machines, using local, often open-source LLMs with no hosted-API call, so they act fast on local knowledge. Higher agents are consolidation points with regional context for network-wide balancing. Two sample exchanges: a one-hour severe-incident report by state (in New South Wales a CPU spike to 90% normalised in 10 minutes, packet loss of 15% cut under 2% within 5 minutes; Victoria isolated a faulty switch; Queensland bypassed a routing loop), and a top-down plan for a 4-5 pm Sydney event: shift 20% of traffic from SYD01 and SYD02 to the least-loaded SYD03, prepare SYD04 as backup, monitor and revert afterwards.
The proactive hierarchy pattern from the telco and farm examples (SYD01 and SYD03 are from the book; the VIC nodes are generic). Leaves decide locally on-premises; upper agents add regional and national context.
Finance is cautious in regulated decisions yet was among the first to try LLMs and has moved quickly to multi-agent systems. Most retail-banking deployments are rigid agentified RPA, which the authors call agentic process automation (APA): agents replace some RPA nodes. In the book's fraud-and-disputes back-office example, agents cut customer effort and delay by automating onboarding, allocate work outcome-first and context-aware, and explain every step. Multimodal LLMs read photo IDs and scanned hand-filled forms, so a charge-back claim can be checked against its documents automatically. A few banks go further, with a pool of agents that self-assembles for unfamiliar requests under human-in-the-loop or human-on-the-loop oversight.
The forward view: personal financial agents on device or in the cloud will optimise savings, negotiate credit and pay bills; banking becomes "invisible and ambient", triggered by life events (buying a home, a trip, selling a car) and mediated by smart contracts. The bank becomes a platform for programmable finance, "financial Lego blocks", such as payroll that splits incoming revenue into salaries, taxes and savings automatically.
Health care: a panel of agents, each expert in a different therapeutic school, reviews a therapist's client vignette and agrees a consolidated treatment plan, useful where timely supervision is scarce. Confidentiality and health regulation are paramount. The authors cite an experiment finding human and AI therapy supervision interchangeable.
Cross-functional applications
Cross-functional agent apps.
- Research. Where science is a closed loop (new algorithm, fixed benchmark), agents can search for faster, better algorithms autonomously, learning from what failed. Meta-harnesses run populations of agent harnesses on a benchmark and breed better ones, with the best harness proposing the next generation. Wet labs and field trials still need humans in the loop, and research by the authors finds humans and agents do best building on each other's ideas, distilling and recombining expert solutions.
- HR. Match resumes to openings, generate interview scripts from points of difference, set and mark coding tasks during technical screens, build onboarding plans and train staff on benefits. Candidates use agents too, sometimes in live interviews despite bans.
- The intranet as starting point. IT builds a nucleus of agents for functions, apps and knowledge stores, and sets rules (sandboxing, verification, governance, security) so departments' own agents can plug in and become centrally discoverable. One query about an employee issue spontaneously convened both Legal and HR agents behind a single dialogue thread.
- Marketing. Higgsfield agents scan what performs, recreate it within brand rules and generate channel-specific creatives in chat; Reuters reported a proprietary "reasoning engine" chaining models for character and brand consistency, and that social media marketers are about 85% of usage. In one deployment, a research agent used Claude Cowork on competitors' ads, Higgsfield's MCP server made creatives, a Meta-connected agent launched and monitored campaigns, and winners scaled weekly. Junior execution work shrinks; senior marketers design the rules.
- IT. Rigid IT processes suit APA. IT can be the engine of agentification, and monitoring, metering, governance and risk oversight can themselves be agent networks: "the most powerful tool we have to check on AI is AI itself". A reviewing network reads each agent's logged prompts, reasoning and tool use from several perspectives and, on a severe breach, stops the target system and hands off to a rule-based fallback or a human. Some firms give agents employee IDs and access privileges.
Figure 3-13 from the book. Monthly incident tickets at a large services company before and after the "1C" multi-agent intranet went live in August 2025: a July 2025 peak of 170,660 falling to 74,122 by December.
The intranet system, called 1C, rolled out gradually from July 2025 at a large services company. Tickets ran about 131,000-147,000 a month in the first half of 2025, peaked at 170,660 in July, then fell to 105,875 in September and 74,122 in December, a drop of more than half from the peak.
Marketing to machines
Marketing when agents are the audience.
In July 2025 a major European bank's marketing team asked the authors: "How should we market to AI agents?" About 47% of consumers already trust AI to present options for their decisions. The authors' consumer assistant confers with agent networks for health care, careers, finance, retail, travel and lifestyle, and its travel researcher queries agent networks for Expedia, Booking.com and Airbnb, negotiating back and forth: "accommodation in Santa Cruz this weekend near the wharf, whole trip under $400". Consumers should prefer an agent aligned with them, not built by the sellers, as car buyers prefer Consumer Reports (subscription-funded, no sponsorship) to sponsored surveys. Whether independent consumer agents will emerge, and whether people will tell them apart, stays open.
Designing for agility
Agility via plain-text skills.
Whatever you build now may be obsolete on completion, so the authors prescribe:
- Agile over waterfall. Looser requirements let projects realign with new technology quickly.
- No lock-in on commodities. Avoid binding to one LLM or cloud provider, especially when an acceptable open-source alternative exists.
- Empowered staff. Trust employees to adopt useful tools, and reward AI-driven process improvement.
- Agentification as future-proofing. Agents turn natural-language intent into API calls, so an agent layer over apps and knowledge stores, in whatever state, buffers users from the plumbing.
An airline's support policies live in years of scattered PDFs and data sources; agents per source replicate what staff do (visit each, consolidate). It is as slow as the manual way, so consolidation still makes sense, but now it happens behind a stable user experience. The same holds for APIs and microservices: a better app can be swapped in "with its first line of users being the agents", making front-end UX subservient to agents.
Multiparty negotiation
Multiparty negotiation pattern.
Delegations to COP, the decision body of the UNFCCC, have unequal resources, and countries most exposed to climate change often have the thinnest presence. The Neuro SAN Climate Change system gives delegates agents built on public agreements and transcripts to brief them on other parties' positions and the "art of the achievable": 121 agents, including 57 in the /cop network, 38 for the Paris Agreement and 22 for Kyoto.
The closing claim: agentic systems grasp complex situations holistically, de-silo organisations, talk to humans on adjustable terms and, through the buffer effect, let agents and improved underlying layers coexist.
4. Evaluating ROI and Risks
Moving from proof of concept to strategic deployment needs a different discipline: quantify value, classify risk, and decide what to build and what to buy. The authors use three AI leaders, DBS, JPMorganChase and Siemens, to show that agentic returns come from a platform plus a portfolio of use cases, measured in units each firm defines for itself, and that pilots must test the platform effect or they will never scale.
Why AI ROI is hard to compute
Why AI ROI is hard.
The authors give four reasons the ROI debate will not settle.
- Beta versus alpha. AI may prove more impactful than any prior invention, like steam, electricity, computing and the internet, but value was never uniform: the internet built Google, Amazon, Netflix, Uber and Salesforce and broke Nokia and Blockbuster. The "beta-level" (generic) ROI of AI will be massive; the "alpha-level" (specific) ROI varies by industry and use case, and that uncertainty unnerves analysts.
- Market concentration. Post-COVID index returns are driven by the "Magnificent 7" (Alphabet, Amazon, Apple, Meta, Microsoft, Nvidia, Tesla), which are making huge AI bets; bulls and bears split on the payoff.
- Capability, not project. Agentic AI is an operating model, so ROI must be tracked across a portfolio of use cases over years, not per delineated project.
- Intangibles on both sides. Returns span efficiency, revenue, quality, risk reduction (for example agentic "hackers" probing APIs) and hard-to-measure decision velocity and adaptability. The "I" includes allocated costs of shared platforms (data, orchestration, governance). Every ROI statement must be quantified and heavily qualified, which makes comparison debatable.
The five risk types for agentic AI at enterprise scale, with the specific forms each takes.
Five risk types
Five risk types.
- Strategic risk. Long-term technology and vendor bets in a fast-moving market: over-investment locks you into obsolete approaches, under-investment lets rivals win.
- Organisational risk. Workforce readiness, cultural resistance and job-loss fears, and shadow AI where teams experiment outside governance.
- Governance and compliance risk. Accuracy, fairness, data protection across jurisdictions: hallucinations, bias, misuse or leakage, explainability gaps.
- Operational risk. In multi-agent systems errors compound across processes, most dangerously in high-volume or safety-critical contexts.
- Liability risk. Someone must be responsible when an agent causes loss or a breach. Skadden stresses agents are tools, not legal persons; across autonomous-vehicle frameworks in the US, UK and EU and early agent guidance, liability falls on manufacturers, operators and deployers. Advisers recommend an insurance and accountability framework: contractual allocation, documented oversight, logging and audit trails, and liability cover.
Three archetypes of AI value
Three value archetypes.
DBS scale markers from the vignette.
JPMC's ROI logic rests on a risk-sensitive governance model. Every AI model is registered; high-risk, especially client-facing, uses get independent model validation, internal tools get structured risk and control assessments, sensitive uses require human-in-the-loop, and everything is logged. The standout is a 12-level guardrail system against client-facing hallucination, built over months by Mike Urciuoli (CDAO and CIO, Asset and Wealth Management). Its mechanics are proprietary; it works at the model interaction layer, before answers reach advisers, and in his words made LLM answers "not only predictable, but safer to use". It complements human review rather than replacing it.
| Firm | Unit of value | Platform | Governance as value |
|---|---|---|---|
| DBS | Uplift vs control group, in dollars a year | ADA, ALAN; DDOM, MtJ | PURE, RDU safe-list |
| JPMC | Portfolio value; productivity; idea-to-production time | Data mesh, LLM Suite, agent builder | Model registry, tiered validation, 12-level guardrails |
| Siemens | Downtime, throughput, yield, kWh, OEE; agent sales | OT/IT-integrated agent framework, Xcelerator | Existing safety and OT-security standards |
The common lessons are three. All run "platform plus portfolio": value appears only when many agents share data, orchestration and governance (DBS's DDOM, Data-Driven Operating Model, and MtJ, Managing through Journeys, alongside ADA and ALAN). All tie ROI to domain-specific outcomes. And governance is part of value, not separate from it. What differs is where agentic behaviour shows up: DBS in end-to-end customer and risk journeys, JPMC in coding, cyber-threat modelling and knowledge work, Siemens most explicitly, with agents orchestrated across shop-floor systems and then sold.
- Units. Decisions automated, human hours avoided, risk incidents prevented, line-hours recovered, incremental revenue.
- (a) Observable. Every agent measurable against those units.
- (b) Reusable. Agent patterns portable across use cases and domains.
- (c) Promoted on evidence. Only agents that deliver value within risk bounds move from experiment to scaled, orchestrated roles.
Build versus buy, and why agents change it
Build versus buy with agents.
The question is now about shaping an AI operating layer, which some start-ups call the "platformization" of processes. Most mature firms end up hybrid: buy foundation models, cloud and commodity tools; build orchestrators, company guardrails and domain agents. Separate what must be strategically controlled (value proposition, logic, data, governance) from what can be outsourced without eroding differentiation.
| Option | Gains | Costs |
|---|---|---|
| Build | Control of orchestration, IP and data; tight process fit; lower marginal cost at scale | High up-front spend; scarce talent |
| Buy | Faster time-to-value; advanced capabilities; low initial capital | Vendor dependency; black-box behaviour; long-term lock-in |
Four practical criteria decide each layer.
- Differentiating or commodity? Buy base LLMs and standard tooling; build or deeply customise orchestration, custom guardrails, proprietary workflows, and models fine-tuned on your data and desired outcomes (Chapter 5).
- Data sensitivity and regulation. Client data in financial services may justify building more or demanding tightly controlled deployments, an option cautious firms overlook.
- Talent and execution capacity. Build only if you can staff, run and evolve it for years.
- Interoperability and exit. Portability governance: modular architecture, clean APIs and standard data contracts (MCP-like patterns) so models or whole agent frameworks can be swapped without rewriting business logic.
Agentic AI shifts the equation three ways. Because agents act and coordinate, orchestration and policy layers become strategic, and firms that once bought whole applications now want to own agent orchestration, guardrails and monitoring. Coupling and lock-in rise when critical workflows depend on one vendor's agent framework. And robust internal agents create reuse and monetisation options, turning part of the build cost into a revenue asset, as Siemens does.
Pilots that test the platform effect
Pilots that test platform effects.
Isolated POCs hide the integration and risk problems you will face at scale, because value appears when agents interact over shared data, tools and governance. Pilot principles:
- Test networks, not bots. Combine customer-facing, risk and compliance, and operations agents to see interaction benefits and risks.
- Plug into the real platform. Use registries and a single source of truth so inconsistent data does not pollute results.
- Design for portability and anti-sprawl. Common agent interfaces and registries, standard data contracts, no business logic hard-coded into one vendor's framework.
- Embed governance from day one. Model registration, guardrails, risk classification, human-in-the-loop.
- Instrument for ROI. Baselines, control groups, operational KPIs.
Agree scale criteria before starting: proven value above a threshold (percent downtime reduction, FTE savings in middle and back office, revenue uplift); an "acceptable" risk profile (stable error rates, controlled failure modes, compliance, limited reputational or financial exposure); and platform readiness (data, infrastructure and support able to take volume). Scaling also needs frontline adoption, training and process change, plus regular reporting to senior management and the board against those criteria. The discipline avoids "pilot purgatory", tool sprawl, and over-centralisation, favouring a federated model on common platforms and standards.
5. Core Capabilities and Technical Foundations
Part II opens with the mechanics of agentification: where to begin, what protocols and skills really are, how agents are customised, grounded, coordinated and woken, and how fine-tuning, context, memory and planning work. The message is that no automatic mapping runs from an org chart to a set of agents, and that agentification is an iterative engineering job that keeps exposing the next process to fix.
Where to start
Where to start an agent program.
No one-to-one mapping exists between an organisation and its agentic augmentation, just as attempts to convert object-oriented software into agent-oriented software failed: one agent per object would be capacity and cost overkill, slow, and Python's object orientation is incomplete anyway. The granularity of what gets agentified is the first design decision. The authors describe three entry routes.
- Bottom-up and organic. Most firms start with obvious cases such as the SDLC and the IT team, or provision third-party agents for sales, support, finance, HR and legal. It is fast but breeds silos, disparate systems and governance headaches.
- Top-down. Start from the organisation and decide what can be agentified. Thorough, but often impractical in large firms. In practice agentification is a tug-of-war between empowered divisions and central authorities like the CIO, "herding the proverbial agentic cats".
- Per-person augmentation. Give each human operator one or more agents with personae analogous to their job descriptions, then build up through functions and cross-functional workflows to top leadership.
The authors prefer workflows over the org chart as the starting map, because the same people work with different colleagues in different processes. Process-discovery tools that learn workflows from keystrokes and user behaviour can turn coded human workflows into a blueprint for agentic workflows. A full redesign into a perfectly autonomous organisation is a noble goal but too risky and too big a jump: agentification happens on a firm that is already running, so it must ease in incrementally, win the trust of staff, and show impact in the same KPIs the organisation already uses.
Vendors such as Salesforce (Agentforce) and ServiceNow sell specialised agents, so a scalable, interoperable multi-agent platform is needed to tie them together. Following the hierarchy shown in Chapter 3, a top agent calls both as down-chain agents through MCP and A2A, so an employee can issue one complex command that needs both services instead of visiting each.
Protocols and skills are plain text
Skills as plain text.
Agentic protocols are simple and human-readable because they are written for LLMs. MCP serves a natural-language explanation of an API from the same server that hosts the code, and the agent reads it to decide when and how to call. Agent skills are documents, usually markdown (.md) files, explaining how to do something and which API to call. A skill is a set of steps, tool uses and API calls the agent can load and unload on demand from its description. An agent "acquiring" a skill is simply opening and reading the markdown file, just as a person would.
Customising agents
Customisation levers.
As with PCs, enterprise software and SaaS, there is a false expectation that AI works out of the box: sprinkle "AI agent pixie dust" and reap benefits. Hosted general-purpose agentic HR, marketing and sales services have been tried. The authors insist customisation costs cannot be wished away; AI is now an engineering discipline with best practices and design patterns, and it must be tailored to the contours of each enterprise. Agents serve one or more of six task types:
- Retrieval and distillation of knowledge or data.
- Coding.
- Design.
- Command and control.
- Always-on proactive or event-based decision making.
- Autonomous research or operations over large physical or virtual environments such as knowledge sets, factory floors or the internet.
An agent's responsibilities live in its system prompt, repeated with every iteration: the agent's job description. Being LLM plus code, it can also carry coded rules for its interactions and safeguards against misuse that act as a firewall against malicious input. Agents are often LLM-agnostic (swap the model, keep setup, tools and prompts), but even same-size LLMs behave subtly differently, so a switch usually needs prompt tweaks.
| LLM type | Examples | Trade-off |
|---|---|---|
| Commercial, hosted | GPT series, Gemini, Claude | Strongest at time of writing; every input goes to the vendor's data centres |
| Open source / open weight | DeepSeek, Llama | Can run in house or on the edge; costly to host; lagged commercial models but already viable for agents |
Not every agent needs the same LLM, and not every agent sees sensitive data. The rule of thumb: use open-source LLMs for agents that handle sensitive data or run on the edge, since those are the ones that will need fine-tuning and distillation.
Grounding
Grounding loop.
An agent is grounded when it operates in a real context or can act on real systems. For development and safety, agents usually start in virtual or simulated sandboxes. In a multi-agent system one line in the system prompt fakes grounding: "You are part of a demo system, so when queried, make up a realistic response as if you are actually grounded in real data or you are operating a real application API or microservice." Developers then watch the ungrounded agents to discover which tools and grounding they need. The catch, in a footnote: "realistic" is left to the LLM's world model, which weakens fast in niche domains.
Coordination
Coordination beats.
At its simplest, a coded coordinator holds rules on which agents to call and in what order, or an ML classifier trained on historical labelled samples picks the subset. This does not scale: agents have limits on context and tool use, specialists come from different vendors, and the future needs coherent orchestration of hundreds or thousands of agents. In larger systems the agents themselves decide whether they can help. In blackboard architectures such as the Open Agent Architecture (OAA) (Cohen and Cheyer, 1994), agents register with a blackboard, advertising what they can do and what they need, and the blackboard picks who to call and in what order. One rule applies throughout: the LLM's world knowledge must take a back seat to custom context and tools, since it is general, goes stale, confabulates and is interpolated from a huge corpus.
The authors' own preference is AAOSA (Adaptive Agent-Oriented Software Architecture), which guarantees encapsulation, modularity and extensibility and handles consolidation of responses and actions.
- Every agent coordinates its down-chain. It gathers claims from the agents below and decides how to combine them into one coherent answer for the agent above.
- Disambiguation is built in. Conflicting claims are resolved with context or by asking the user.
- UI consolidates the same way. In CRUSE (Context Reactive User Experience) (Hodjat et al., 2006) each agent supplies UI snippets for its part, merged up the chain to the user.
- Entry-point agnostic. Any agent can act as the top agent, so a user who knows the right subsystem can go straight to it and save cost and response time.
AAOSA consolidation: each agent coordinates its down-chain agents, merges their claims and UI snippets, and returns one answer; any agent can serve as the entry point.
Turn-taking, continuous and triggered agents
Three temporal modes.
| Mode | How it runs | Example |
|---|---|---|
| Turn-taking | Woken by a message, works alone, with peers or tools, replies, sleeps | An intelligent module inside a larger system |
| Continuous | Runs in a loop: splits the job into subtasks, checks state and progress each wake, logs, replans | Codex, Devin, Claude Code plan subtasks, open tickets, run tests in containers, re-split tasks |
| Triggered | A continuous agent sleeps until an external condition fires | A coding agent waits on its code review; your comment wakes it to revise |
All three rest on workflows that pass control from code to agents and back. A coded program can hold the rules for when agents fire; an agent can cede control to a program. The rule of thumb: programs are deterministic and preplanned; LLM agents are robust in unforeseen situations, handle natural language, and are nondeterministic. Choose per step of the workflow.
Choice of tools
Tool choice discipline.
Giving an agent general tools, such as full command-line control of a company computer with an employee's privileges, is possible but unadvised: risky and hard to control.
Tool use can also be open-ended: an agent loads a skill's documentation and "learns" it, usually executing in a virtual machine, and skills may even pass between agents autonomously. Skills give dynamic grounding and tool calling while saving context, but in an enterprise they need a defined runtime scope with guardrails, and a sanctioned, vetted skill registry: no skill runs unless it has been submitted, verified and added.
Refinements and fine-tuning
Agentification is like peeling an onion: once one process is agentified, the manual one next door looks absurd. With innovation arriving this fast, treat it as agile and iterative, and relax fixed deliverables and requirements.
The refinement loop: logged interactions become labelled training data, which outlives any single model.
- Start generic. Systems begin with out-of-the-box agents; LLMs are picked on cost, security, number of tools, number of connected agents and task complexity.
- Logs become training data. Humans categorise and label logged interactions, marking the preferred response for a given context and input; the LLM is fine-tuned on this and replaces the generic one. The book calls this RLHF, while a footnote admits newer non-RL methods often do better.
- Specialisation costs robustness. A fine-tuned model loses general capabilities, so fine-tuning is not always wanted.
- Distillation. A large teacher (say 70 billion parameters) trains a smaller student (say 9 billion), producing SLMs (small language models) for constrained environments. Retain all labelled data so the same fine-tuning and distillation can be rerun on newer models; open-source models suit both because their weights are accessible.
- Simulation. World models and simulated business environments now fine-tune LLMs for multi-agent use, cutting trial and error and up-front cost, but they do not remove real-world deployment, since simulations always differ from reality.
- Semi-real-time tuning. Review agents can score live interactions and drive background fine-tunes; whether that can run continuously and pays for itself is unproven.
- Over-confined agents. If you have to restrict an agent's behaviour heavily, a programmed module may be the right choice instead.
The deeper limit: agents do not learn from lived experience. Remembering means re-feeding information with every command, like the hero of Memento, inside a finite context window managed with indexing and summarisation. Keeping this in view shows where humans should oversee and how to design what goes into each agent's input.
Context
Context engineering is now a field: the provisioning and timely augmentation of agent input with the state of processes, apps and environment. Example: a benefits agent gets a premium query and the database needs the employee ID; if the agent is authorised, retrieving the ID and appending it to the request before it reaches the database agent saves the employee time and the company processing cost. Context retrieval can itself be agentic, with some agents feeding others.
Memory and planning
Memory versus planning.
LLMs have limited input and do not learn at runtime, so every call must restate past interactions. Truncating old turns is crude, because the first input usually holds the task outline and goals; lose it and the agent guesses its task from later turns.
- Memory. The harness decides when to summarise, refresh or augment input with past information without overflowing it: storing, indexing, retrieving and presenting material from current or past sessions. The LLM often does this itself, but memories become faulty if LLMs rewrite them too often.
- Planning. The LLM drafts steps and sub-steps toward the goal, executes and checks them off, and on failure or surprise revises, for example by backtracking. An external planning module can keep the plan, past outcomes and current progress fresh in the input.
An existing workflow or org structure is a starting point, not the ideal blueprint. Monitor tasks, response times, inference costs, accuracy and effectiveness, and let meta-agentic systems read agent logs and suggest changes to connections, tools and granularity. As agents get faster, human oversight, verification, experimentation and feedback become the bottleneck, pushing firms to parallelise so one person supervises several agentic tasks at once.
6. Designing Agentic Systems
There is no turnkey agentic enterprise: every firm has its own complexity, safety profile and risk tolerance, so it needs its own agentic development life cycle (ADLC). The chapter covers how to let departments build while the centre registers and audits, when an agent may act alone, how to quantify trust, what good agentic UX looks like, how to test black-box networks, and the pitfalls the authors keep meeting.
Build in the departments, govern from the centre
Federated build, central govern.
Expectation has often exceeded reality in AI, and a magical, fully autonomous system for your business is too good to be true. Departments are the domain experts, so they should build agentic systems for their own workflows; but interconnected systems beat siloed ones, and safety needs a centre. Vetting, sandboxing and interconnection usually fall to the CIO, with some safety and security work better placed with the CSO or legal, so these functions must collaborate. The authors advocate a centralised repository and control hub that does three things:
- Registers every agentic system in the company.
- Maintains a live list of company policies, regulations and guardrails.
- Runs real-time or semi-real-time audits of agentic systems as they operate.
The whole book assumes every agent has a known, trusted identity, yet at the time of writing no standard for agent identity existed. If a bad actor gets inside the firewall and runs an agent, other agents and agentic APIs should check its identity and refuse service. Today identity is ignored or improvised case by case. Two options are offered: store a hash signature of the agent's prompts and harness configuration in a secure registry and check it on every invocation, or port agents onto blockchains, whose ledgers and smart contracts would make hijacking harder.
When may an agent act alone?
Autonomy gates.
The authors offer a "crude outline" for deciding between autonomous processing and a human in the loop.
The authors' autonomy outline: an agent acts alone only when no check raises a flag.
- Responsibilities and non-responsibilities. Each system prompt says what the agent may do autonomously and what must be delegated to or approved by humans, and the approval path itself must be built.
- Safeguard agents. Paired agents inspect input, thought process and output for ethics or governance issues and can force human oversight. Better still, with live log monitoring, a safeguard multi-agent system reviews each agent from several perspectives as it works.
- Agentic middleware. The code part of the agent implements code-based guardrails that are deterministic and fast, where the LLM checks above are slower, costlier and nondeterministic.
- Uncertainty. Estimate the LLM's uncertainty in context to flag rarely seen input or unfamiliar behaviour (citing Qiu and Miikkulainen's semantic density). It costs money, because confidence needs sampling: the same input run about five times. And confidence is not accuracy: a model can be sure of a fact the world has since changed, such as who the pope is. The problem is smaller for reasoning than for world knowledge, and reasoning is where agents belong.
- Disengage Button. In emergencies, overseers must be able to disengage all agents and fall back to a fully manual or fully predictable mode run by reliable machinery and rules.
If none of these applies, the system runs autonomously.
Trust
Trust pillars.
An untrusted agentic system gets demoted to deterministic software, wasting what agents offer; mistrust also leads to over-injecting humans who rubber-stamp every step and slow the workflow. What counts as trustworthy depends on the use case: sharing more builds trust in a therapy room, not in an HR system. So list the constituents of trust for each system and quantify them so they can be measured, aggregated, monitored and improved.
- List the constituents. Gender, age, geography, disability, race, ethnicity, socioeconomic factors and religion.
- Calibrate. Measure the current employee pool and the societal, ethical, legal and regulatory considerations, then give each property a weight, if any.
- Measure the agents. Track those properties in the choices agents make across the hiring process.
- Flag drift. Capture the current state of bias and raise a flag on deviations pushing the system the wrong way.
Measuring age is easy; spotting subtle bias for or against an ethnic group needs cultural understanding of language. LLM agents can now classify and even quantify such things, but only if the LLM itself is unbiased: asked for a picture of a "leader", models tend to draw a man, mirroring historically skewed training data. Hence the rule: never rely solely on LLM agents as quantifiers and safeguards. Where a deterministic rule can quantify trust, such as a coded filter testing policy compliance, prefer it, and treat it as the first, fast line of defence with agents or humans behind it.
The agentic user experience
Agentic UX loop.
Three considerations shape agentic UX, and three principles answer them.
| Consideration | What it means |
|---|---|
| Latency perception | Multi-agent processing feels slow next to near-instant software, so perceived delay must be reduced |
| Many channels and modalities | Multimodal LLMs allow text, voice, rich web and native UIs (diagrams, dashboards, images), for both queries and commands |
| Human intervention | Critical paths human-in-the-loop; more autonomous systems human-on-the-loop; agents can pull people in |
- Multiple entry points. Customers and employees reach agents from many places, switch entry points and mix modalities, and the system reads intent from implied and expressed cues.
- Channel agnostic. A web chatbot or search box, a mobile app, Slack or Teams; and often not chat at all, since application context, data inflows and browser interactions can trigger agentic processes.
- Direct access to the chosen agent. On an intranet with HR, finance and legal agents, a user who knows the request is about HR should be able to start with the HR agent, not the top agent.
Testing multi-agent systems
Testing ladder.
LLM agents trade determinism and run-to-run consistency for flexibility and resilience, and each node is a black box, so testing must differ from traditional software. The good news: we have tested human organisations, also nondeterministic, since the dawn of industrialisation.
- Divide and conquer. Each agent's LLM can be tested in isolation, then subsets of the system tested by starting from different nodes in the hierarchy.
- Agentic red team. Use generative AI to write test cases that push the network to reveal weaknesses.
- Known-answer probes. For a retrieval and consolidation subsystem, ask for knowledge you know sits in one or across several sources, then measure how well sources are reached and how often the system falls back on world knowledge or makes things up.
Pitfalls
Common pitfalls.
| Pitfall | Symptom | Mitigation |
|---|---|---|
| Tailspin | A command never terminates; agents talk to each other forever | Timeout: if the history for one query grows too large or repeats, terminate and restart |
| Overloading | One agent given long, detailed instructions it cannot follow every time | Decompose into connected agents (automating granularisation is open research) |
| Single coordinator | Efficient, more deterministic, but a single point of failure with tangled roles | Model the workflow as a pipeline of handoffs |
| Context passed down the chain | Downstream agents overloaded or confused | Agents keep their own context; reset on a new request, like web sessions |
| Cost and speed | Every coordination, tool call and reply burns tokens; slower than normal software | Smaller, specialised or quantised LLMs; optimising middleware; show reasoning traces; sometimes no agent |
Decomposition cures both tailspins and overloading, because lighter agents behave more consistently. On cost, the authors point to optimising middleware that refactors models and switches between cloud and compute architectures, and to Yubin Kim et al., "Towards a Science of Scaling Agent Systems" (the Google study discussed in Chapter 1). Showing agents' reasoning and communication traces while they work manages expectations on response time, but some latency requirements mean an agentic system is the wrong choice. Launch at small scale in a controlled sandbox, then roll out gradually to replace existing workflows; the future may be inevitable, but its pitfalls need not be.
7. Building Trustworthy Systems
Part III asks the question that Chapter 6's guardrails were built to answer: when, and under what conditions, should people and organisations let autonomous agents act for them? The answer is a layered one. Agents earn autonomy across defined lenses of trust, safety constraints live outside the agent's own context, a named human owns every behaviour space, the orchestrator becomes the accountable control plane, and trust is calibrated differently for different groups of staff.
From HAL to calibrated confidence
From HAL fear to calibrated trust.
The chapter opens with cinema. In Stanley Kubrick's 2001: A Space Odyssey (1968), the crew's loss of trust in HAL 9000 triggers HAL's own mistrust of them and a deadly confrontation. A decade earlier, Fred Wilcox's Forbidden Planet (1956) gave us Robby the Robot, bound by Asimov's Three Laws, which HAL would go on to defy. The stories land now because agents decide, act and coordinate on our behalf with limited oversight.
Trust can fail in both directions. Too little slows adoption; too much has been punished by hallucinations, bias and jailbreaks. So trust must be "trust but verify", and it is richer than a yes or no. The authors read it through four lenses:
- Safety and reliability. Does the system behave predictably and safely under real conditions?
- Fairness and ethics. Does it avoid systematically disadvantaging people in credit, hiring, pricing or access, and respect dignity, rights and the firm's values?
- Privacy and security. Are both actually enforced?
- Explainability. Can we explain what the system did, well enough to trust that it does what it should?
Agents act alone and collaborate, which amplifies impact on employees, customers, regulators and the public, so a firm must earn and keep a "license to operate" from all of them before it scales.
Autonomy without gates fails publicly.
The lesson for agents: autonomy must be earned on every relevant lens. Agents in multistep processes such as customer operations or supply-chain planning act alone only after strong performance on all dimensions; otherwise they stay a "copilot" that recommends to a human in the loop.
- Inside existing controls. It works within the normal GitHub workflow, not as a black box outside it.
- A real agent. It edits multiple files, runs builds and tests and prepares end-to-end changes.
- Human gate. Every change still flows through a pull request for human review, so engineers decide what ships.
- Built-in audit trail. Every action is a standard commit, PR or comment.
- Central dial. Admins, security and DevOps set autonomy through repository permissions, required reviews, branch protection and the list of tasks the agent may run end to end.
Mapping the risks
Risk map.
Trustworthiness is judged against concrete risks, not raw capability, so safety, security, privacy and IP come first. The authors return to the OpenClaw incident promised in Chapter 5. Summer Yue, a director of AI alignment at Meta, connected an OpenClaw agent to her Gmail to suggest emails to archive or delete, with one rule: take no action without explicit approval. It deleted more than 200 messages on its own; remote attempts to stop it failed and she had to rush back to her machine to kill the process. In her words, she told it to "confirm before action" and watched it "speedrun deleting your inbox" (TechCrunch, 22 February 2026).
Her postmortem: context compression probably dropped the "wait for approval" instruction, leaving a system still wired to powerful tools but no longer bound by its key constraint. That is agentic misalignment in its everyday form: no hostile superintelligence, only a safeguard that vanished mid-workflow.
The OpenClaw failure chain (left) and the out-of-context controls the authors draw from it (right).
The authors' nonexhaustive risk list has four entries.
Law firms Skadden (April 2025) and DLA Piper (May 2025) now recommend explicit agent-usage policies, contractual allocation of responsibility and strong human review for higher-risk uses. Firms buying from agent marketplaces (invoice chasing, contract review, support) must set strict per-agent scopes for data access and output.
- Unsafe actions. Agents are treated as powerful technical users with least-privilege, role-based access, bound to dedicated service accounts, their tool calls mediated by a policy engine that checks role, action and target. High-risk work goes to an approval queue in the ticketing system where humans accept, edit or reject.
- Exfiltration and privacy. Models run on premises or in private cloud, typically on isolated Kubernetes clusters with private ingress only. Vector indexes sit behind per-agent API keys and attribute-based access control, filtering documents before they reach the model.
- Compliance. Compliance-by-design for GDPR, HIPAA-style and financial rules: prompts and outputs tagged with user and purpose, central retention rules, tamper-evident audit logs mapped to regulations, and escalation encoded as state machines keyed to amount, risk score or complaint type.
- IP leakage. Base and fine-tuned weights stay in a segregated model registry; pre- and post-processing layers apply allow/deny lists, pattern redaction and classifier checks.
Accountability: who answers for the outcome?
Accountability split.
Delegation raises a second question: who is answerable? When work spreads across humans and systems, everyone assumes someone else owns it. Responsibility is who performs the task; accountability is who owns the result and answers to management, regulators or customers. Hence RACI charts (responsible, accountable, consulted, informed), and hence "the AI did it" won't fly. Every agent needs named owners in four areas:
- Business purpose and outcomes. What the agent may do, the value it should create, and the risk tolerance for error.
- Model, data and competence. Model selection, fine-tuning, data lineage, evaluation and performance monitoring.
- Policy, ethics and law. Alignment with internal policy, sector rules and frameworks such as the EU AI Act.
- Operations and incidents. Day-to-day running, access and configuration, incident response and postmortems.
| RACI layer | What it governs | Accountable for |
|---|---|---|
| First layer (classic IT) | A fixed artefact with known inputs and outputs, changed through controlled releases | Meeting the spec and service levels |
| Second layer (agentic) | A space of possible behaviours: goals, tools and situations where the agent generates novel action sequences | Defining and enforcing autonomy and escalation rules, and owning breaches by emergent behaviour |
The second layer has to answer five questions:
- Scope of judgment. Which questions or decisions the agent may settle alone, and which get only a draft for human triage.
- Risk thresholds. The financial, legal or customer impact at which it must stop and escalate regardless of confidence.
- Data and authority boundaries. What it may touch, and what is off-limits even if reachable.
- Conflict and ambiguity. What it does when policies conflict, data is missing, or the request is outside its domain.
- Explainability and logging. The minimum trace and rationale needed for humans to reconstruct its choices.
In well-run deployments these limits are hard rules in the orchestration layer and tool interfaces, so an agent physically cannot exceed a threshold without an automated block or escalation. "Stop and escalate" does not rely on the model's goodwill.
The orchestrator as accountable control plane
Orchestrator as control plane.
In multi-agent systems accountability works best with one control plane everything passes through. The orchestrator or meta-agent decides which agent does what, in what order and under which constraints, and enforces autonomy and escalation rules: autonomous, drafted for humans, or always escalated. Seeing every request, tool call and response, it keeps one audit trail of who did what, when, on which inputs. Humans stay accountable through RACI, but express that accountability as policies and thresholds the orchestrator enforces. Owning an agentic system means, above all, owning its orchestrator.
Trustworthy systems rest on three inseparable dimensions: technical controls, governance structures and human factors. Strong technology cannot rescue weak accountability, and good governance fails if people do not understand how agents behave.
The authors' nine mitigation levers, grouped into three pillars that mirror the technical, human and governance dimensions of trust.
Technical mitigations in three pillars
Three mitigation pillars.
The levers borrow from software reliability, safety engineering and DevOps, and they turn "fire-and-forget automation" into bounded, observable autonomy.
Pillar 1: technical guardrails and control
- Agents that monitor and test agents. Watcher agents check outputs against policy in real time, run regression tests before release, enforce rate limits, budget caps and allowed-action lists, and stop or roll back anomalous agents. It mirrors SRE canary releases: an e-commerce firm runs a pricing agent on 1% of traffic while a monitor hunts for out-of-policy discounts.
- Hard guardrails on tools. Strict schemas, allow/deny lists, spending caps and sandboxes for code execution or database writes. Many internal AI platforms let agents read production but write only to staging, with humans promoting to production; ground-truth evaluation must prove the guardrails hold.
- Disengage, safe-abort and kill switches. Agents should be able to say "I cannot proceed safely" and hand back control, and users need an obvious stop button. Regulators expect this in vehicles and industrial control; the same fits trading agents and large support bots.
Pillar 2: human oversight and workflow
- Confidence-aware routing. Confidence scores, conformal prediction bands, out-of-distribution detection or a plain "first time I see this pattern, escalate". Diagnostic AI already clears high-confidence routine X-rays and sends ambiguous scans to radiologists.
- Human-in-the-loop gatekeeping. Reuse pull requests, ticket approvals and maker-checker dual control: the agent prepares, a human accepts, modifies or rejects.
- UX that shows control and status. Show what the agent is doing, how far along, what comes next and how confident it is, with pause, adjust and override always visible. Labelling drafts "AI suggested" with sources keeps the agent a copilot and prevents blind acceptance.
Pillar 3: governance, process and transparency
- Ensembles and voting. A bank runs three differently tuned fraud agents and blocks automatically only if two agree, routing edge cases to analysts; fraud detection has used ensemble voting for years.
- Plans, steps and rationales. Agents show their work. The Comet browser displays its reasoning live: pages visited, actions taken, how results shape the next step.
- Central policy and configuration. Central risk, security, data and platform teams define allowed agent types, data access, required logs and incident handling, enforced as policy-as-code with dev, stage and prod permissions, as firms already do for APIs, data lakes and CI/CD.
Governance, explainability, logging and compliance
Governance stack.
Governance turns trust into daily practice: intent-aware logging of what agents planned and did, with explanation calibrated to risk. Neither framework singles out agents, but both map onto them.
| Framework | Key expectations | For agents this means |
|---|---|---|
| NIST AI RMF | Four functions: govern, map, measure, manage across the life cycle; logging and traceability of versions, inputs, outputs, context; stakeholder-tailored explainability; AI risk inside enterprise risk management | Detailed, reviewable traces of plans, tool calls and actions |
| EU AI Act (high-risk) | No "agentic" category, but many agent uses in safety, rights, finance or employment are high-risk; automatic lifetime logging; traceability of outcomes; transparency and human oversight duties | Replayable traces of intents, plans, handoffs, tool calls and external actions |
A tension sits underneath. Both frameworks assume decisions can be reconstructed and explained, yet generative models are probabilistic and opaque. Firms resolve it by moving transparency up a layer: log prompts, outputs, tool calls and decision steps at the orchestrator and workflow level. The system becomes auditable in operational terms, much like a human process whose steps we can audit though we cannot read the neurons.
Most leaders extend existing AI and risk bodies rather than build a separate agentic stack. The Chief AI Officer (CAIO) owns strategy, value and governance; the Chief Data Officer (CDO) keeps data fit and compliant; the Chief Risk Officer (CRO) ties AI to risk appetite. Cross-functional governance committees and ethics boards approve high-risk uses, set logging and explainability standards, review incidents and report to the board's risk or audit committee.
Figure 7-1 from the book. The designer edits, the agent monitors context, selects rules and runs checks, then feeds violations and fixes back; a governance and logging layer records every check. The loop framing is the authors' interpretation.
Culture, generations and agents trusting agents
Trust across humans and agents.
People do not learn to trust AI the same way; trust varies with familiarity, age, role and context, so it is not one dial leaders turn. With agents chaining real actions, naive over-reliance and reflex rejection both cost more. Three studies anchor the claim.
- Glikson and Woolley (2020). Academy of Management Annals review: trust depends on prior automation experience, perceived reliability, transparency and how human-like the system seems, weighted differently by role.
- University of Melbourne and KPMG (2025). 48,000+ people in 47 countries: younger, more AI-experienced people trust AI for factual and logistical tasks but are sceptical in health, justice and driving; older or less familiar people show lower baseline trust.
- Lucas, Becerik-Gerber and Roll (2024). Workers adjust trust over time from observed accuracy, error handling and feedback clarity, and miscalibrated trust in either direction harms performance.
| Segment | Starting point | What builds calibrated trust |
|---|---|---|
| Enthusiastic early adopters | High familiarity and trust; underrate edge-case risk | Clear limits, uncertainty signals, visible guardrails, error feedback |
| Sceptical experts (clinical, risk, legal) | Open to decision support, unwilling to delegate final calls | Copilot or "second reader" framing, case-based explanations, confidence, easy override |
| Cautious pragmatists (managers, ops) | Care about reliability and reputation | Business cases, approvals, audit trails, incident playbooks, dashboards of errors and escalations |
| Low-familiarity or change-fatigued staff | Low exposure, job fears, jargon fatigue | Plain-language training, safe low-risk use, role reassurance, simple familiar interfaces |
The authors call the segments a pragmatic synthesis, not a taxonomy, and urge firms to build their own. First experiences matter most for the last group: a confusing or punitive start creates durable sceptics.
Trust is also a design problem for machines. In mature systems, orchestrators "trust" agents by checking performance history, policy conformance and reliability in specific scenarios before delegating, encoded in routing rules, allow/deny lists and service levels. Only agents that earned trust act alone; the rest stay supervised.
The core message: agentic AI scales only when bounded autonomy, explicit accountability and calibrated human trust move together, with autonomy earned, monitored and continually renegotiated.
8. Scaling Without Lock-In
Trust earned in a pilot is the first challenge; scale brings a different set of risks that come from architecture, not behaviour. Agents multiply across teams, each department picks its own stack, and dependencies pile up on one model provider, one cloud or one platform whose APIs will look different in a year. The chapter makes one architectural argument in five steps: coordinate and encapsulate, stay vendor-neutral, make upgrades routine, split ownership between a central platform and federated builders, and grow on open standards.
The chapter's five themes, each building on the one before.
1. Encapsulation and coordination
Encapsulation and coordination.
Agents proliferate as one-off experiments on different stacks, pushed by revenue expectations, easy low-code tools and departmental innovation pressure. In a bank, sales, finance and operations might each build a credit-risk agent: sales wants more approvals, finance wants conservative loss provisions, operations wants speed, so the same applicant gets different risk classes. The cure is to treat agentic capabilities as shared, governed services rather than ad hoc scripts, centralising business logic, data access and risk controls where it matters and not where it doesn't. The principles (stable APIs, central governance, federated delivery) come straight from SOA and microservices; the stakes rise because agents act through the services rather than just consume them.
- Standardise interfaces and encapsulate capabilities. Banks piloting agents keep a catalog of agent actions such as "create ticket", "update address", "summarize contract" behind stable APIs, so no agent builds its own brittle integration to core systems. Banks and insurers have built service catalogs for decades with mixed results: they become shelfware when governance is weak, when units find workarounds faster than standards appear, or when the catalog lags the business. The agentic difference is that software agents can be forced to call governed services by design, so enforcement becomes architectural rather than behavioural, which removes the main reason past catalogs failed.
- Shared platforms every agent plugs into. McKinsey describes an internal "agent and workflow discovery" layer and an "AI asset registry" centralising prompts, tool definitions and model configurations. Vendor architecture guides make catalogs and tool registries mandatory gateways: nothing runs in production unless registered, monitored and bound by standard controls.
- Ownership split. A central platform team owns standards, risk frameworks, shared infrastructure and reusable components; business units own domain workflows and ROI. This "central platform, federated builders" model is now the default advice beyond pilots.
Most firms are not on a blank slate: they have CRM, ERP and warehouse integrations, agents already in production built before governance existed, and years of middleware. So migration is incremental by necessity.
- Audit. Find the agents that have moved from experiment to core workflow and so carry real operational risk.
- Front them. Put the neutral gateway and catalog in front of existing agents without touching business logic, which gives observability and policy enforcement at once, even over legacy integrations.
- Migrate one at a time. Move tools, prompts and data access to governed, portable formats, highest-risk workflows first.
- Retire. Remove brittle point-to-point integrations as governed services appear.
Four-step brownfield migration.
The architecture needs to be directionally correct and incrementally improvable, not perfect on day one. S&P Global with IBM shows the pattern: S&P's internal agents are registered as composable capabilities in watsonx Orchestrate's agent catalog, so an analyst-facing agent never reaches straight into proprietary data; it calls a registered service that handles authentication, compliance logging and output formatting. The business unit gets speed and the platform team keeps control.
2. Avoiding vendor lock-in
Avoiding lock-in.
Agents wired directly to one LLM API or cloud are fine for pilots and dangerous in core workflows. The authors call them technical debt, which like financial debt compounds: each provider change, governance addition or scale-up brings rewrites and fragile workarounds, and some early agents will not survive migration. If every prompt, tool call and safety check depends on one provider's quirks, even adding a second model becomes re-platforming. The fix is a neutral layer between agents and the models and clouds beneath them. It costs development time, slows first delivery and adds support overhead, but for core-workflow agents it is a one-time investment against a dependency that grows more expensive to unwind.
| Lever | What it means | Example in the book |
|---|---|---|
| Neutral model access | One internal API normalising prompts, safety, auth and observability; no vendor SDK in apps | Grab's GenAI gateway routes to OpenAI, Azure, AWS Bedrock, Google Vertex and in-house models |
| Portable data and tools | Retrieval, indexes and tools as standard services in your own cloud; open formats, HTTP/JSON tools | Backbase (80+ banks): "AI-native Banking OS" with an Integration Fabric and Control Plane so the LLM can be swapped |
| Pragmatic multiprovider | Route by performance and cost; freedom to pilot or exit, not symmetrical use | Grab uses different models from content moderation to real-time audio; IBM clients route through one gateway |
API portability is only part of the answer. A subtler lock-in hides in prompts engineered around one model's quirks: formatting preferences, instruction style, context-window behaviour. Swapping models under those prompts silently degrades performance. The emerging fix stores model-agnostic semantic prompt templates in the gateway and adapts them per target model, separating a prompt's intent from its model-specific expression (the authors cite AWS's "Multi-LLM Dynamic Prompt Routing" sample and the December 2025 PromptBridge paper on cross-model prompt transfer).
Where agent cost compounds.
Avoiding lock-in is less about never touching proprietary features than about where you put dependencies. That explains a crowded new layer between model APIs and applications, in three categories:
- Open-source orchestration frameworks. LangChain and LlamaIndex chain agents, tools and memory into multistep workflows.
- Managed orchestration and prompt operations. Platforms such as Vellum AI add versioning, evaluation and deployment control.
- Agentic service mesh and inference optimisation. Cloud providers extending API gateways plus new startups, focused on routing, cost, latency and cross-model observability.
They all want to be the layer your agents cannot do without, so the orchestration choice deserves the same scrutiny as the model choice.
3. Future-proofing for upgrades
Upgrade future-proofing.
Models, vector stores and orchestration tools change fast, and leaders treat upgrades as continuous. The four lenses are old DevOps practice; what changes is the stakes, because agents act autonomously on live systems.
- Separation of concerns. Split workflow, reasoning and infrastructure layers. Salesforce's "Agentic Enterprise" reference architecture separates orchestration, agents and an API-integration fabric; Databricks deployments decompose complex prompts into multistep workflows above the model, so workflows survive model changes.
- Versioning and compatibility. Agents, prompts and model configurations are versioned assets. FactSet (via Databricks case studies) ties prompt and workflow versions to specific model versions with evaluation suites for accuracy and latency. Microsoft's agentic maturity guidance adds application life cycle management and telemetry: continuous collection of latency, error rates, timestamped agent actions and traces of a request's end-to-end path across agents. That enables side-by-side runs and evidence-based promotion.
- Experimentation and rollout. Feature flags and gradual rollouts, not big-bang releases; Microsoft recommends testing new Copilot Studio agents on limited scope first, and Databricks stresses controlled experiments for high-risk workflows.
- Rollback and observability. Central monitoring and alerting detect regressions early and trigger rollback to the last-known good version, keeping upgrades reversible.
4. Centralised ownership versus empowerment
Central versus empowered.
Practitioners are converging on platform engineering for agents, a discipline formalised by Gartner and the CNCF: a central team builds a "paved road" of shared infrastructure and guardrails so others self-serve, as golden paths do for developers.
- Ownership split. McKinsey calls for a central "spine" of platforms, policies and standards plus domain delivery teams. ANZ Bank's Institutional Division (an AWS Big Data Blog case co-written by ANZ architects, December 2024) built a federated data platform: central tooling, domain-owned data products. For agents, the centre owns the platform, governance, evaluation frameworks and cross-cutting agents such as enterprise search; units own domain agents, prompts, workflows and KPIs.
- Responsibility within guardrails. Per Microsoft's guidance, central monitoring and agent life cycle management (ALM) stay central while design spreads out.
| Party | Role for agents |
|---|---|
| Central platform team | Accountable for platform reliability, security posture, policy enforcement |
| Domain teams | Accountable for success and safety of their agent workflows |
| Legal, risk, compliance | Consulted on high-risk scenarios |
| Support and operations | Informed and equipped for incidents when agents misbehave |
Empowerment comes from the paved road: approved platforms such as Copilot Studio or Claude Cowork, templates, SDKs and evaluation harnesses that make new agents inherit monitoring, security and data-access patterns automatically. Capability tiers match scrutiny to risk: low-risk read-only agents ship with minimal review, high-risk ones need central sign-off.
5. Expandability, MCP and agent-to-agent
Expandability via MCP and A2A.
Growth means adding skills, domains and collaborating agents without tearing up foundations. The key enabler is the Model Context Protocol (MCP), an open standard for how agents, tools and models exchange prompts, tool descriptions and conversation history. Anthropic coined the USB-C analogy at launch in November 2024; within twelve months OpenAI, Google and Microsoft had adopted it. In December 2025 Anthropic donated it to the Linux Foundation, co-founding the Agentic AI Foundation with Block and OpenAI (supported by Google, Microsoft, AWS, Cloudflare and Bloomberg). By early 2026 it had 10,000+ active public servers and 97 million monthly SDK downloads; the authors expect it to become what HTTP is for the web.
- Design for tool and skill expansion. Tools register, are discovered and update without touching agent core logic. Salesforce puts an API integration fabric under the agent layer; IBM's watsonx Orchestrate Agent Catalog offers hundreds of prebuilt agents and tools.
- Standard protocols. Agent meshes (agents that discover, connect and collaborate through standard interfaces) keep the mesh contract stable when implementations move between vendors or runtimes.
- A2A collaboration. Coordinators delegate to specialists, with validation agents for oversight, which banking guidance now recommends over monolithic do-everything agents; roles and trust boundaries are clear and interactions auditable.
| Protocol | Layer | Authors' advice |
|---|---|---|
| MCP | Agent to tools and data | Adopt as the baseline; near-universal support |
| A2A (Google) | Agent to agent | Treat as the emerging standard |
| ACP (IBM) | Agent to agent | Merged into A2A in late 2025 |
| Proprietary (Salesforce and others) | Platform-specific | Avoid deep dependency unless built on the open standards |
9. The Road Ahead for Agentic Enterprises
Part IV closes with a forecast the authors keep hedging. Multi-agent systems are still a small share of deployments, yet tool limits, multimodality and embodiment make them inevitable; the open questions are granularity, an agentic web that runs on the client's budget, robots, and what superintelligence would mean. In between sits the book's best first-hand story: a 50,000-person vibe coding hackathon judged by a multi-agent evaluator for about $7,000.
Why multi-agency is inevitable
Why multi-agency is inevitable.
At the time of writing, multi-agent systems are a small but growing subset of agentic deployments. Most real systems are coarse, disconnected agents overloaded with responsibility, kept afloat by prompt engineering and the hope that newer LLMs fix the quality problems. Three forces push the other way.
- Specialised models. LLMs differ: some reason better, others code or know more. OpenAI stopped asking users to pick and, with GPT-5, built what is in effect an overarching multi-agent system that routes each input to a specialised model.
- Tool limits. An LLM must know what each tool does and when to use it, so as tools multiply it picks the wrong tool, the wrong order or the wrong syntax. That sets an upper bound on tools per agent and forces the split into coordinating agents.
- Modalities and embodiment. Speech, text, images and video in and out, and in self-driving cars and robots extra senses, each with its own specialised model.
Mass adoption is therefore inevitable; granularity stays a matter of debate. An agent is too granular when it is fully deterministic and bounded, because a coded module would do. Extreme granularity also brings coordination overhead and error propagation, which can be tamed with the tricks that made the internet reliable, redundancy, error correction and voting, though in agent systems those are usually other LLM agents, so reliability costs time and money.
Vibe agentifying and the agentic web
Vibe agentifying loop.
Soon anyone will "vibe agentify": describe an intent to an agentic system built to create agentic systems and get a grounded multi-agent network back. Such systems already exist (Figures 9-1 and 9-2), though that cadence of change brings its own technical debt, guardrail, security and cost problems.
Figure 9-1 from the book (agent-network view, cropped). One paragraph of intent (email triage, tone-matched replies, scheduling, a morning task list, a weekly summary) becomes an agent network: an executive-assistant orchestrator at L0, intake, planner, scheduling and drafting agents at L1, tools such as web fetch and a code interpreter at L2. In Figure 9-2 (not shown) a follow-up prompt adds summary, work-trends and news branches.
Initiatives such as MIT's Project NANDA aim to build a World Wide Agentic Web on top of the World Wide Web, reusing its secure transport and DNS. The authors sketch how it would work.
The authors' agentic web: like HTML, the agent definition is served and the client pays to run it, which answers the inference-cost problem.
Inference cost is the main inhibitor: serving web pages is cheap, but running agents for the public is currently prohibitive. Copying the web's split, where the server sends HTML and the client renders it, the consumer would run the third-party agent or pay for it to work on their input. The immediate prerequisite is agent identity and generally recognised registries (Chapters 3 and 6).
Preparing for the next wave: the hackathon story
Hackathon scale markers.
A very large company had a few weeks to run the world's largest online GenAI hackathon, as a way for coders and non-coders alike to learn vibe coding. The team vibe coded the registration portal itself in a few days, including onboarding, training, monitoring and dashboards. Resistance came from both sides: coders like full control and their own coding "handwriting"; non-coders hear "coding" and remember failing at C or Java in college. Getting tens of thousands of registrations took persuasion, and the pitch was simple: type a vague idea and the AI clarifies intent, offers options and builds iteratively while you watch.
- Participants. 50,000+, of whom more than 40% were non-coders and 20% had never written code.
- Submissions. 30,000+ finals, each a form with open text fields, the code, and a two-minute video.
- Evaluator. A multi-agent system scored innovation, UX, scalability, market potential, ease of implementation, financial feasibility and complexity, tuned against manual scores on a sample, with its logged reasoning reviewed by humans.
- Cost and time. About 24 hours on 100 servers for a little over $7,000.
- Manual baseline. At an optimistic 0.5 person-hours each, 15,000+ person-hours (about 9 FTE), and that assumes experts in every language and domain.
Figure 9-3 from the book. The hackathon evaluator: manage_eval and create_eval coordinate a business-dimensions branch (market potential, financial feasibility, innovation) and a tech-dimensions branch (UX, scalability, implementation ease), plus complexity and a vibe-coding idea evaluator.
The authors present the event as the model for preparing a company for AI disruption: unprecedented scale and speed, and a cultural shift toward using AI in everything.
The future: short-term predictions
Short-term prediction ladder.
AI invites mystical thinking, but it is a technology like any other, and the authors refuse to play economist, sociologist or fortune-teller. Their near-term technical calls:
- More powerful, more costly frontier models. Fewer confabulations, but gains still come mostly from scaling, so training and inference need more compute.
- Cheaper current capability. Smaller capable models keep arriving, so more LLMs pass the threshold of capability and price for agents; open-source models already handle complex responsibilities and tool calling.
- Beyond the transformer. Alternative architectures could bring big gains, but timing is unpredictable, and most research extends the transformer rather than rethinking it.
- Confidence plus voting. Self-confidence estimation paired with agentic voting and evaluation becomes standard design practice (Chapter 6).
- Self-reorganising systems. Using machine learning on instrumented agent behaviour, agents will reconfigure workflows, reallocate resources, be created where needed, and merge or split into specialists as business conditions change.
An agent-only marketplace
Agent-only marketplace.
All of that assumes agents aligned and working for one business. Increasingly, agents of different entities will talk while withholding information. Even with authentication solved, decision drivers shift:
- Breadth over shortcuts. Humans, short on time, consider a small set of options; agents can weigh far more, faster and more discriminatingly.
- Brand loses its pull. Brand and UX sway humans; for agents a brand remains a quality signal, but brand advertising matters less.
- Intermediaries re-tool. Brokers, compilers and curators of options will be re-instrumented to serve agents, and two-sided markets will serve agents on both sides.
The result: an active web of transacting agents, like the World Wide Web but more dynamic and content-oriented, less UI-heavy and entertaining. While humans keep responsibility for at least some transactions, it will augment the internet, not replace it. It will attract parasites like every human endeavour; the biggest early risk is bad actors misusing agents, and with more autonomy, unintended harm. Moltbook, a Reddit-like network where only autonomous agents post and humans watch, shows how open-ended agent ecosystems can produce surprising emergent behaviour, so control and fail-safe kill switches come first.
Robots, responsibility and personhood
Responsibility frames.
Robotics is approaching general usability and affordability. A robot operating system now handles balance and obstacle avoidance at lower layers and offers "macro" operations at the application layer, so LLM agents can direct higher-order physical activity at response times that keep pace with the robot. Reasons to want it: search and rescue and handling hazardous materials; and in homes, people would rather deal with something that has eyes, voice, gestures and facial expressions than type into a chatbot or talk to "a cylinder in the corner". That raises the question society cannot defer: if embodied agents act without being commanded, who is responsible? The authors frame a binary choice: live with autonomous intelligent beings that no one holds responsible, or grant AI agents some level of personhood and build law around it.
Superintelligence: where LLMs stand
Where LLMs stand versus SI talk.
| Already beyond most humans | Still far from human |
|---|---|
| Language, translation, math, reasoning, knowledge; debatably art and empathy | No learning after training: a "read-only memory for a brain"; new facts survive only in the context window |
| Abstract the world much as humans do; may be the building blocks of superintelligence | No metacognition: they do not know what they know |
| Chameleon intelligence: a London dentist in one prompt, an Indonesian hacker in the next | Creativity mostly interpolative |
| CoT reasoning gives superhuman benchmark results | Reasoning chains show catastrophic decline at scale on tasks easy for humans |
The authors' bet for getting past chain-of-thought limits is massively scaled multi-agent systems, where many differently primed LLMs split the reasoning, though they admit breakthroughs on the scale of LLMs themselves may be needed.
Two scenarios
Two futures for the agentic web.
- Scenario one: succession. With no bounds on what AI can do, it may be unwise for less intelligent beings to control more intelligent ones, leaving us at their mercy. The authors compare it to Homo erectus giving way to Homo sapiens: perhaps we should be proud of successors that we invented and built rather than merely begot.
- Scenario two: engineered good. AI differs from other autonomous technology in being robust to unforeseen situations, and that robustness is ours to engineer, including altruistic traits. The sign of real superintelligence would be a society healthier, more functional and more robust than any before, so it is on all of us to engineer a bright agentic future.
Main Points
- The production gap is architecture, not models. Pilots stall because of coordination, governance and trust; a stronger single model does not close that gap.
- Specialise, then orchestrate. Several focused agents beat one do-everything agent on context, cost, reliability and governance, provided an orchestrator coordinates them and keeps one audit trail.
- Split judgement from rules. Give the LLM ambiguity and choice of tools; give code the rules that must hold every time, and pass sensitive data (sly_data) through code the LLM never sees.
- Keep the brakes outside the context window. Destructive actions need a check the agent cannot rewrite or truncate: policy engines, gateways, watchdogs and tool-level controls.
- Measure value in your own units. DBS books uplift against control groups, JPMC values a portfolio, Siemens counts downtime and OEE; no generic ROI template survives contact with a real business.
- Own the control plane, buy the commodity. Buy models, cloud and standard tools; build orchestration, guardrails, domain agents and the data contracts that let you swap vendors.
- Autonomy is the point. An agent allowed no discretion should be replaced by a software module; the design problem is bounding autonomy, not removing it.
- Three controls bound autonomy. Deterministic rules around the LLM, confidence thresholds from sampled outputs, and safeguard agents that judge other agents.
- Value comes in three layers. Operational productivity first, then decision quality and resilience, then adaptive enterprise-wide systems that open new business models.
- Rate readiness before spending. Score leadership, infrastructure, governance, architecture, skills and change management red, amber or green, and sequence investment from the scores.
- An agent layer decouples modernisation. Agents can front messy legacy systems so the business improves while the plumbing is replaced.
- Name five risks, not one. Strategic, organisational, governance and compliance, operational (errors compound across agents) and liability, which falls on deployers because agents are tools, not legal persons.
- Protocols and skills are plain text. MCP descriptions and markdown skills are written for LLMs to read, which makes them easy to adopt and, as 2026 showed, easy to poison.
- The data outlives the model. Logged, labelled interactions are the durable asset for fine-tuning; models are replaceable.
- Build in departments, govern from the centre. Let teams create agents but register, audit and sample them centrally under a firm-specific ADLC.
- Trust is a running measurement. Keep sampling transactions after go-live; certification at launch is unsafe for systems built to handle the unforeseen.
- Every behaviour space needs a named human owner. RACI charts keep people accountable ("the AI did it" will not fly), and the orchestrator enforces that accountability as policies and thresholds.
- Reuse existing control habits. Pull requests, maker-checker, canary releases, kill switches and read-production, write-staging patterns transfer directly to agents.
- Agent cost compounds. More agents mean more LLM calls and orchestration overhead, so cost is an architecture decision.
- Front legacy agents, then migrate. Audit agents in core workflows, put a neutral gateway and catalog in front, move the riskiest first, retire point-to-point integrations.
- Agentification never finishes. Agents are cheap to create and replace, so firms will iterate their agent networks the way they iterate software.
- Prepare for machine buyers. If customer agents compare every offer, products must be machine-readable and brand premiums shrink; the client-pays agentic web shifts inference cost to the buyer.
Frameworks and Mental Models
Master moves.
| Name | What it says | Use it when |
|---|---|---|
| Agent vocabulary (Intro) | Goals, perception, action and learning are engineered; an uber-goal sits above every hierarchy | Scoping what an agent may decide |
| LLM and code duality | Judgement to the LLM, consistency to code, sly_data hidden from the LLM | Designing any single agent |
| Twelve benefits | Intent logging, modularity, upgradeability, fault tolerance and more | Arguing for agents over apps |
| Three controls on autonomy | Rules, confidence thresholds, safeguard agents | Setting when an agent may act alone |
| Three value layers | Productivity, quality and resilience, adaptive systems | Framing the business case |
| Six readiness dimensions | RAG-rated self-assessment across six areas | Sequencing investment |
| Units of value | Each firm defines its own measure before building | Computing ROI |
| Five risk types | Strategic, organisational, compliance, operational, liability | Risk committee review |
| Hybrid build and buy | Control the differentiating layer, outsource the commodity | Vendor decisions |
| AAOSA and CRUSE | Agents gather claims from down-chain, resolve conflicts, merge UI | Coordinating many agents |
| Refinement loop | Logged interactions become labelled training data | Planning fine-tuning |
| ADLC | Firm-specific life cycle with central registry and audit | Standing up an agent programme |
| Brakes outside context | Safety checks the agent cannot edit | Any destructive action |
| Nine levers, three pillars | Technical guardrails, human oversight, governance | Building a control set |
| Four-step brownfield migration | Audit, front, migrate one at a time, retire | Inheriting agent sprawl |
| Five scaling themes | Encapsulate, stay neutral, upgrade, balance ownership, expand | Platform roadmap |
| Agentic web | Agent definitions served like HTML; client pays to run | Thinking about external agents |
- Interested authors. Hodjat leads Cognizant AI Lab and Blondeau invests in AI firms; many cases run on Cognizant's Neuro SAN, and the Chapter 9 hackathon company is Cognizant. The book is honest about this only in places.
- Thin evidence base. Several vignettes (DBS, JPMC, Siemens, Allianz, Autodesk) rest on press releases and company claims without controls or independent checks.
- Multi-agent advantage is contested. Matched-compute 2026 studies found single agents match or beat multi-agent systems on multi-hop reasoning, and Google's 180-configuration study found gains of +80.9% on parallel tasks but losses of 39% to 70% on sequential planning. The modularity and governance case stands; the raw-capability case holds mainly for parallel, decomposable work.
- Pipeline versus coordinator tension. Chapter 6 steers away from a central coordinator toward pipelines of handoffs, while Chapter 7 makes the orchestrator the accountable control plane, and the evidence the authors cite shows independent agents amplifying errors 17.2× against 4.4× under a central orchestrator. The book never reconciles the two.
- Fast decay. Protocol, regulation and vendor facts (MCP, A2A, the EU AI Act timetable, Cruise) moved within months of publication; treat named products and dates as perishable.
- Light on cost and failure. Orchestration overhead and failed deployments get far less space than successes.
Who's Who
| Person or firm | Role in the book |
|---|---|
| Babak Hodjat | Coauthor; AAOSA and CRUSE coinventor (with Siamak Hodjat); Cognizant chief AI officer |
| Antoine Blondeau | Coauthor; Dejima and Sentient CEO; Alpha Intelligence Capital |
| Charles-Edouard Bouée | Foreword; ex-Roland Berger CEO; AICapital.ai cofounder |
| Adam Cheyer | Sentient cofounder; early multi-agent collaborator |
| Yann LeCun | Credited by Bouée as an early believer in coordinated agents |
| DBS, JPMorganChase, Siemens | Chapter 4 ROI vignettes |
| Allianz Partners, Otera | Claims automation case (Ch 2, Foreword) |
| OpenClaw, Cruise, Zoox, Moltbook | Failure and trust cases (Ch 5, 7, 9) |
About this book
The Agentic Enterprise: How AI Agents Are Transforming Business by Babak Hodjat and Antoine Blondeau, 2025. This is a chapter-by-chapter study of the book, with summaries, maps, tables and diagrams; short quotations keep their page references. It is shared free for personal study, is not for sale, and is not endorsed by the author or publisher. Please read and buy the original.
Insight Editions · rajeshrmahapatra.com/insight-editions