Posted on

B2B Agentic AI Workflows

EDI, Event-Driven Architecture and the Ancestors of Agentic AI

Recent conversations at customer AI Roadshow in Dublin got me to thinking about the days when I was IT Manger for a start-up retail business. I was introduced to EDI. Electronic Data Interchange — the ability to send a structured purchase order from one company’s system to another without a human typing it in. It was, genuinely, transformative. Before EDI, someone had to pick up the phone, read out an order number, and hope the person on the other end wrote it down correctly.

EDI removed the human from the data transfer. That was the revolution.

But here’s what EDI couldn’t do: think.

The First Generation: EDI — Moving Structured Data Between Systems

EDI was brilliant at one thing — moving a known, structured message from point A to point B, reliably, at scale.

A purchase order goes out. An invoice comes back. A shipping confirmation follows. Every field in its place. Every transaction logged. The pipes worked.

What EDI required, though, was that both sides agreed on the format in advance. EDIFACT. X12. Fixed-width files. The message had to be perfectly structured, perfectly mapped, and perfectly expected. If something fell outside the agreed schema, the transaction failed. There was no interpretation. No judgement. No handling of the unexpected.

EDI moved data. It didn’t move meaning.

And it was entirely reactive. Something happened upstream — a human placed an order, a warehouse confirmed a shipment — and EDI carried the news downstream. The system itself initiated nothing. It waited.

The Second Generation: Event-Driven Architecture — Systems That React

Event-Driven Architecture was the next evolution. Instead of scheduled batch transfers between agreed parties, EDA introduced the idea of a continuous stream of events — things that happened — flowing through a system in real time.

A sensor reading changes. An event fires. A customer clicks “buy”. An event fires. A stock level drops below threshold. An event fires.

Systems subscribed to the events they cared about and responded accordingly. Kafka, RabbitMQ, AWS EventBridge — the plumbing of the modern enterprise. EDA made systems faster, more loosely coupled, and far more responsive than the batch-and-transfer world of EDI.

But EDA still had a fundamental constraint: the responses were pre-programmed.

When the stock level drops below threshold, the system does exactly what it was told to do — raise a replenishment order, send an alert, update a dashboard. The logic was written by a developer, tested, deployed, and fixed. The system reacted, but it didn’t reason.

If the stock drop happened because of an unusual combination of factors — a supplier delay, a seasonal spike, and a logistics disruption all at once — the pre-programmed response might be exactly wrong. The system would fire its rule. The rule would execute. And nobody would know it was the wrong call until the consequences arrived.

EDA moved meaning. It still couldn’t interpret it.

Now the Grandchild – The Third Generation: Agentic AI — Systems That Reason

This is where we are now. And this is why it’s different.

Agentic AI in business promises to not just just move data. And not just react to events. But reason across context, construct execution plans appropriate to situations, and take action — using tools, calling systems, adapting when the outcome isn’t what was expected.

The same scenario that would have broken an EDI transaction or misfired an EDA rule — the supplier delay, the seasonal spike, the logistics disruption, all at once — is exactly the kind of multi-signal, ambiguous situation an agentic system can handle. Because it holds all of that context simultaneously. It weighs it. It decides.

What makes this possible is the LLM at the centre of the agent. The LLM is the part that EDI and EDA never had.

Natural language understanding means that events described in unstructured form — a technician’s note, a customer complaint, a supplier email — can now trigger workflows. Not just structured data events. Any signal. Reasoning across context means the agent doesn’t just react to one event; it holds multiple events simultaneously and reasons across them. The order, the stock level, the maintenance alert — connected. Dynamic planning means that instead of following a pre-defined decision tree, the agent constructs a plan appropriate to the specific situation, novel exceptions included. And natural language output means the agent doesn’t just act — it explains. The shift supervisor gets a recommendation in plain English with the reasoning visible. Trust is built.

Tool selection is the final piece. The LLM decides which tools to call and in what order. The workflow isn’t hardcoded. It’s reasoned.

EDI moved structured data between systems. EDA moved events between systems in real time. LLMs move meaning.

The Family Tree

It helps to see this as a lineage, not a replacement.

GenerationTechnologyWhat it movedWhat it couldn’t do
1stEDIStructured data between agreed partiesHandle the unexpected
2ndEDAEvents between loosely coupled systemsReason about what they meant
3rdAgentic AI
B2B Agentic Workflows		Goals, plans and actions across systems and across organisationsStill being discovered

Each generation inherited the infrastructure of the one before. Agentic AI runs on top of the event streams that EDA built. EDA ran on top of the integration patterns that EDI established. You don’t throw away the pipes. You add a brain.

The Democratisation Wave

There’s a second story running alongside the technical one, and it matters just as much.

EDI required specialists. You needed someone who understood EDIFACT schemas, VAN networks, and trading partner agreements. It was powerful, but it was not accessible. The people who could build EDI integrations were a small, expensive, specialist group.

EDA democratised some of that — cloud-native event brokers, managed Kafka, serverless functions. A competent developer could wire up event-driven workflows without a decade of integration experience. But it was still firmly in the hands of engineers.

Agentic AI is doing something different. It’s democratising the building of intelligent workflows to people who have never written a line of code.

n8n, Make, Zapier AI — visual workflow builders with LLM nodes — mean a marketing manager can build an agentic workflow in an afternoon. Microsoft Copilot Studio puts a drag-and-drop agent builder on top of the M365 data layer without IT involvement for every use case. Salesforce Agentforce puts CRM-native agents in the hands of sales operations teams, not engineers. ServiceNow puts ITSM agents in the hands of process owners who understand the work. And DataRobot — an AI and ML platform that has evolved rapidly into agentic territory — allows data teams to build, deploy, and govern agents on top of existing model infrastructure. For organisations that already have a mature ML practice and want to extend it into agentic workflows without starting from scratch, it is particularly powerful.

These are just the established names. The startup ecosystem is moving fast — new agentic workflow builders are appearing monthly, each with their own approach to orchestration, tool calling, memory, and governance. The space is genuinely exciting. It is also, right now, genuinely fragmented.

Which brings us to the standards problem.

The Standards Problem — And Why It Matters

EDI had this problem too. In the early days, every organisation implemented EDI slightly differently. EDIFACT versus X12. Different field mappings. Different interpretations of the same schema. Trading partners had to negotiate bespoke integration agreements with every counterparty. The technology worked. The interoperability didn’t — not without significant effort.

EDA had the same growing pains. Kafka versus RabbitMQ versus Pulsar. Different event schemas. Different serialisation formats. Different approaches to ordering, delivery guarantees, and error handling. The ecosystem fragmented before it consolidated.

Agentic AI is at exactly that point right now.

Every platform has its own way of defining tools. Its own agent memory model. Its own approach to multi-agent orchestration. Its own security and governance primitives. An agent built in LangChain doesn’t natively interoperate with one built in AutoGen. A tool wrapped for Copilot Studio doesn’t automatically work in n8n. The capability is real. The standards are not yet.

This is not a reason to wait. It is a reason to build with portability in mind — and to watch one emerging standard very closely.

MCP — The Standard That Could Change Everything

Model Context Protocol, introduced by Anthropic and rapidly gaining adoption across the industry, is the most important standards development in agentic AI right now. And it maps almost perfectly onto what EDI did for data exchange — and what event schemas did for EDA.

MCP is a standard protocol that defines how an AI agent connects to external tools, data sources, and systems. Instead of every agent builder implementing bespoke integrations with every tool, MCP provides a universal connector layer. Build an MCP server for your system once, and any MCP-compatible agent can use it.

Think about what that means in practice. For the agent builder, instead of writing custom integration code for every tool the agent needs to call, you connect to MCP servers. The agent discovers what tools are available, what they do, and how to call them — dynamically, at runtime. For the tool owner, instead of building integrations for every agent framework that might want to use your system, you build one MCP server. Any compliant agent can connect. For the enterprise, instead of a fragmented estate of bespoke agent-to-tool integrations that nobody fully understands, you have a governed, discoverable, auditable layer of MCP servers that defines exactly what your agents can and cannot do.

This is the EDI moment for agentic AI. EDI gave us agreed schemas for business documents. MCP gives us an agreed protocol for agent-to-tool communication.

The analogy goes further. EDI worked best when the underlying data was clean and the trading partners had agreed on what the fields actually meant — not just their format. MCP works best when the tools behind the servers are well-behaved, well-documented, and governed. The protocol solves the connection problem. It doesn’t solve the data quality problem or the governance problem. Those are still yours to own.

MCP also does something that matters enormously for any enterprise running multiple agents across multiple systems. It makes multi-agent architectures composable. Consider a manufacturer running a maintenance agent, a production scheduling agent, and a procurement agent in parallel. Without MCP, connecting them into a coherent workflow requires custom orchestration code that understands the internals of each agent — change one and you potentially break the others. With MCP, each agent exposes its capabilities as MCP tools. Other agents can discover and call those capabilities through the standard protocol, with a standard contract, logged and auditable. Three systems. One control plane. Connected through a standard that didn’t exist two years ago.

The pattern is the same as every democratisation wave in technology history.

EraWhat got democratisedThe tool that did it
1990sDesktop publishingPageMaker, Word
2000sWeb presenceWordPress, Dreamweaver
2010sData visualisationTableau, Power BI
2020sAgentic workflowsn8n, Copilot Studio, Agentforce

Each wave put powerful capability into the hands of people who previously had to ask a specialist. Each wave also created a new class of problems — because power without understanding is just faster chaos.

B2B Agentic Workflows — The Next Frontier

Most of the conversation about agentic AI is pointing inward. Automated reports. Automated configurations. Automated competitive analysis. Internal workflows made faster, smarter, less dependent on human intervention. That’s real, and it matters.

But it’s only half the story. Possibly the smaller half.

Because EDI was never an internal tool. It was born as a between-business protocol — two organisations’ systems talking directly to each other, without human intermediaries on either side. If the lineage holds, agentic AI follows the same arc. And the scenario that makes that concrete isn’t hard to imagine. It’s already forming.

Consider a retailer. Its demand forecasting agent is reading sales velocity, seasonal patterns, and external signals continuously — and generating a forward-looking inventory position without being asked. That signal reaches the procurement agent, which reasons across current stock levels, lead times, and supplier terms, and decides to place an order. That order doesn’t go to a human at the supplier. It goes to the supplier’s availability agent, which checks production schedules and fulfilment capacity and responds — or negotiates. Behind that, the supplier’s manufacturing scheduling agent has already slotted the order into the production run. And further upstream, the supplier’s own procurement agent is talking to their suppliers.

Agent talking to agent, all the way up the chain. Each one reasoning locally. The chain reasoning collectively.

This is B2B Agentic — and it is categorically different from EDI. EDI moved a deterministic message between agreed parties. B2B Agentic moves a reasoned decision across organisational boundaries, without a human initiating either side of the transaction. The demand signal propagates. The factory schedules. And at no point did a person decide to place an order.

That’s not science fiction. The components exist today. What doesn’t exist yet is the inter-enterprise trust and governance framework that makes it safe to run at scale. Who owns the decision when two agents from different organisations get it wrong together? How do you audit a transaction that involved reasoning, not just data transfer? What does liability look like when the purchasing agent acted autonomously on a signal the forecasting agent generated?

These are the questions that will define whether B2B Agentic scales cleanly or creates a new class of enterprise risk. MCP is a candidate for the protocol layer. The governance model is still being written.

The ancestors built the pipes. The current generation added the brain. The next frontier is teaching that brain to do business across organisational boundaries — reliably, safely, and at scale.

The Critical Caveat

Here’s the thing that gets lost in the excitement about low-code agent builders.

The tool is not the answer. The tool is the last ten percent.

A marketing manager who wires up an agentic workflow in Copilot Studio in an afternoon has built something that runs on top of data. If that data is ungoverned, siloed, or untrustworthy — the agent will be fast, autonomous, and wrong. In a B2B Agentic world, that problem doesn’t stay inside your firewall. It propagates upstream, downstream and crossstream.

The democratisation of the interface doesn’t democratise the need for foundations.

EDI required clean, agreed data schemas. EDA required reliable, well-defined events. Agentic AI requires trustworthy data, well-behaved tools, clear governance, and someone who owns the outcome. The new hire arrives fluent in n8n. They can build an agent before lunch. But if nobody has done the work to make the underlying data and systems agent-ready, they’ve built a very sophisticated way to automate a bad process.

The low-code builder is the interface. The foundations are still the foundations.

What This Means in Practice

If you’re thinking about agentic AI in your organisation, the lineage matters.

The organisations that got the most out of EDI were the ones that had clean master data and agreed standards before they plugged in the integration. The organisations that got the most out of EDA were the ones that had well-defined events and reliable systems of record before they started subscribing to streams.

The organisations that will get the most out of agentic AI — and that will be ready when B2B Agentic arrives — are the ones that have data their agents can actually use: authoritative, accessible, reasonably clean. Systems that expose safe, well-defined actions: APIs, automations, tools with clear contracts. Governance that decides where autonomy is allowed and where a human stays in the loop. And someone who owns the agent as a product, not a side project.

The technology has changed dramatically across three generations. The discipline required to use it well has not.

Agentic AI is the most capable generation yet. It can reason, plan, adapt, and explain. It can handle the unexpected in ways that EDI and EDA never could. And if B2B Agentic develops as the lineage suggests it will, the boundaries of what agents can do — and who they can do it with — are about to expand significantly.

The ancestors built the pipes. The next generation will build the trust layer.

Just like EDI and EDA before, B2B Agentic Workflows will become cross-organizational pipelines – now with intelligence built in.

Posted on

The Plumbing Under the Hood: RAG, MCP and the Architecture Nobody Explains

A diagram illustrating the architecture of a large language model (LLM) with connections to various systems including CRM, ERP, HR, and SharePoint, displayed on a blueprint-style background.

I’m an under the hood type of guy. I hear high-level fluff and I just turn off. I need more. I need to be able to visualise how things work — and the effects of implementation. I guess that’s the Solution Architect in me. Years of seeing projects go south. Experience that says it’s just not that simple.

I learned a long time ago: if you want something doing, do it yourself.

So here it is. No fluff, no hand-waving. The no-nonsense guide to what RAG and MCP actually are, how they work, and why the distinction matters more than most people realise. Enjoy.

The Problem Every Enterprise AI Deployment Hits

Large language models are genuinely extraordinary. The breadth of knowledge, the reasoning capability, the ability to synthesise and explain — it’s real, and it’s useful. But they have a fundamental constraint that every organisation hits the moment they try to deploy one seriously.

They are frozen.

An LLM is trained on a vast corpus of data up to a point in time, and then the weights are fixed. The model doesn’t know what happened last Tuesday. It doesn’t know your organisation’s processes, your customer contracts, your current pipeline, or the policy document your HR team updated this morning. It is, for all its capability, a brilliant mind in a sealed room.

Every enterprise AI deployment is therefore really solving one problem: how do we get relevant, current, organisational knowledge into the model’s hands at the moment it needs to answer?

Two main solutions emerged. They look similar on the surface. They are fundamentally different underneath.

RAG: The Indexed Snapshot

RAG stands for Retrieval Augmented Generation. The name is less important than the mechanism.

Imagine you have a large knowledge base — policy documents, product guides, training materials, technical specifications. RAG takes all of that content and processes it in advance. Each document gets broken into chunks. Each chunk gets converted into a vector embedding — a numerical representation of the meaning of that text, not just its keywords. Those embeddings get stored in a vector database.

When a user asks a question, the question itself gets converted into a vector using the same method. The system then searches the database for the chunks whose meaning is closest to the meaning of the question — semantic similarity, not keyword matching. The most relevant chunks get retrieved and placed into the model’s context window alongside the original question. The model answers using that retrieved material as its working context.

Think of it as a library. Brilliantly organised, perfectly indexed, searchable by meaning rather than title. You walk in, the system finds the most relevant books, opens them to the right pages, and hands them to the model before it answers.

It’s powerful. For stable, curated knowledge bases it works extremely well.

But it has a ceiling, and the ceiling matters.

The library was shelved at a point in time. The moment your source documents change, your index is stale until you re-embed. And the quality of retrieval is entirely dependent on the quality of what went in. Poorly structured documents, inconsistent language, missing metadata — the embeddings become noisy and retrieval underperforms. The foundational principle holds here as firmly as anywhere in AI: weak data quality at the input stage leads to flawed outputs downstream. RAG doesn’t solve a data quality problem. It inherits it.

MCP: The Living Plumbing

MCP — the Model Context Protocol — is a different kind of answer to the same problem. And understanding the difference is where the real business thinking begins.

MCP doesn’t retrieve from a pre-built index. It connects the model to live systems through their APIs — and queries them in real time, at the moment of the conversation.

Here’s what that means practically. Your SharePoint isn’t indexed in advance — the model calls it directly and gets back whatever is there right now, including the contract template someone updated this morning. Your CRM isn’t embedded into vectors — the model queries it and sees the deal that moved stage an hour ago. Your HR system, your procurement platform, your service desk — all of them accessible, all of them current, all of them live.

The model doesn’t see a snapshot of your organisation. It sees your organisation as it actually is, right now.

And here is the point that changes how you should think about this entirely.

Most enterprise knowledge isn’t in one place. It never has been. It’s fragmented across Salesforce and SAP, ServiceNow and SharePoint, HR platforms and finance systems and procurement tools. Getting RAG to span those systems requires significant data engineering effort — ingesting, normalising, embedding, maintaining. It’s achievable, but it’s heavy.

MCP connects to all of them. Through their APIs. Simultaneously. The model becomes a single conversational interface across the entire technology estate — not just one knowledge base, but the living information fabric of the organisation.

That is not a chatbot connected to some documents. That is a fundamentally different proposition.

Not Competitors — Different Layers

It would be tempting to read this as RAG versus MCP. It isn’t.

They solve overlapping problems at different layers and with different trade-offs. RAG is the right tool for large, stable knowledge corpora where semantic similarity search matters — where you need the model to find relevant material even when the exact words don’t appear in the query. MCP is the right tool where data is live, dynamic, and distributed across operational systems.

And they can work together. A well-architected system might use MCP as the orchestration layer — the model deciding which tools to call — while one of those tools triggers a RAG pipeline for a specific stable knowledge base. The plumbing and the library, working in concert.

The practical guidance is straightforward. Start with MCP. It’s the lower point of entry — no vector infrastructure to provision, no embedding pipelines to build and maintain, no index to keep fresh. You’re connecting to systems and APIs you already have. Reach for RAG when you’ve hit the ceiling — when the corpus is large, messy, and semantic retrieval across unstructured content becomes essential.

Start simple. Earn the complexity.

Before You Lay The Plumbing — What Nobody Tells You

The pitch for both RAG and MCP is compelling. The reality, as always, has a few sharp edges worth knowing about before you commit.

RAG brings infrastructure with it. RAG isn’t just a software pattern you switch on. Behind every vector database is a compute and storage requirement that needs provisioning, maintaining, and scaling as your knowledge base grows. Embedding pipelines need to run continuously — every time source content changes, chunks need re-processing and re-indexing or your library goes stale. For organisations already managing data centre complexity, this is a real cost conversation that rarely appears in the vendor presentation.

MCP makes your legacy systems load-bearing. MCP’s power is connecting to live systems. But those live systems are now dependencies. The legacy HR platform with the flaky API. The procurement system that slows under load. The CRM with three years of inconsistent data entry. Once the LLM is reaching across your technology estate, it is only as reliable as the weakest system it touches. A timeout, a bad API response, a data quality problem in one system degrades the entire interface. What felt like a peripheral legacy problem just became front and centre.

Governance and security are not optional extras. When a model can traverse your entire technology estate — reading CRM data, querying HR systems, pulling procurement approvals — your entire technology estate needs to be ready for that conversation. Access controls, data classification, audit trails, API security, compliance boundaries. These cannot be bolted on after deployment. They need to be designed in from the start. MCP without a holistic governance and security view isn’t just risky. It’s an exposed surface at scale.

This is AI Reality. The plumbing is powerful. Lay it properly.

The Interface, The Plumbing, The Flow

Here is the frame I want to leave you with — because it’s the one that changes how you brief a customer, evaluate a vendor, or think about your own AI roadmap.

LLMs are becoming the interface to information. Not a search bar, not a dashboard, not a report. A conversational, reasoning interface that sits in front of your organisation’s entire data landscape and makes it accessible in plain language.

MCP is the plumbing. The connective tissue that links the interface to the living systems underneath — the CRM, the ERP, the HR platform, the document store, the data warehouse. Without the plumbing, the interface has nothing to work with. With it, the interface can see everything.

And once you have an interface and plumbing, something else becomes possible.

Agents.

Not models that answer questions. Models that act. That move through systems, make decisions, complete workflows, and hand off to humans at exactly the right moment. Agents ride the pipelines that MCP creates and turn information flow into work getting done.

That’s where this goes. And that’s what the next post is about.

Next: The Agentic Leap — when AI stops answering and starts acting.

The Interface. The Plumbing. The Flow.

Posted on

The Unglamorous Guide to Agentic AI

A flowchart illustrating a framework with sections labeled 'Experiments,' 'Mapping,' 'Assisted,' 'Narrow Autonomy,' 'Governance,' 'Tools,' and 'Ownership,' showing connections and percentages for each section within a 'Home Lab Zone' and 'Enterprise Zone.'

A practical map from chatbots to digital colleagues

Every AI conference this year ends the same way. Someone walks off stage having promised you digital colleagues, autonomous operations, and a workforce that never sleeps. The audience files out buzzing. Then Monday arrives, and the to-do list still starts with “fix the CMDB.”

The hype is real. The map is missing.

This post is the map. It’s written for business leaders, IT decision-makers and pre-sales architects who are back from the conference circuit with a head full of agents and a backlog full of reality. I’m not going to predict the entire future of agentic AI. I’m going to draw a practical route from today’s chatbots to tomorrow’s digital colleagues — and be honest about what has to be true before you make that journey safely.

From clever autocomplete to colleagues that actually do things

Let’s get the terminology out of the way in plain language, because the distinction matters more than most people admit.

An LLM or chatbot is great at language. You ask, it responds. It drafts documents, summarises threads, generates emails. But once the text stops, so does the system. It is, if we’re honest, very clever autocomplete with no hands.

An agentic AI — or AI agent — is great at doing. You give it a goal, not just a prompt. It plans multi-step work. It calls tools and systems: APIs, RPA bots, workflows, orchestration engines. It observes outcomes, adapts its plan, and retries. It can operate with humans “on the loop” rather than in every loop.

That last point is precisely where the hype tends to skip ahead. An agent can only plan, act and adapt meaningfully if your data is accessible and trustworthy, your systems expose safe and well-defined actions, you have guardrails and governance that decide where autonomy is allowed, and someone actually owns the agent as a product rather than a side project.

If those conditions aren’t in place, your “agent” is just a more expensive chatbot wearing a new badge. So before you flip the agentic switch, what actually needs to be true?

“Can’t I just install something and it works?”

Yes. In your home lab, absolutely — and there’s nothing wrong with that. Download an open-source agent framework, point it at a few APIs, chain some tasks together and you can have something impressive running by the weekend. The ecosystem is genuinely good and moving fast. More importantly, experimenting in a home lab is one of the best ways to develop real intuition: what agents can actually do, where they get confused, which tools behave well and which don’t, and what the supporting infrastructure starts to look like when things get serious.

Think of it as the design phase. Low stakes, high learning.

But your home lab has a very specific set of conditions that don’t exist in your business. It has one user who knows where all the data lives, trusts their own judgement on every call, and absorbs the full blast radius if something goes wrong. It has no compliance team, no change management process, no SLAs, and no regulator asking what happened at 2am on a Tuesday. And it has no customers.

The technology has never been the hard part. Dropping an agent into a business environment and having it behave well — reliably, at scale, with governance — is a different problem entirely. Not harder in a technical sense. Harder in the sense that it requires decisions, ownership and trust that no framework installs for you.

Good business is practical by design. That’s not a constraint on ambition. It’s the architecture that makes ambition safe to deploy. Every guardrail, every policy, every named owner exists because the blast radius of getting it wrong is real — and someone else’s problem to live with.

The home lab shows you what’s possible. The foundations in this post are how you make it production-ready.

Before we get to those foundations, there’s an even more basic stack that has to exist: a data platform with clean-enough pipelines, a working LLM capability, and an API and tool layer your systems expose to the outside world. Agentic AI sits on top of those three. If you’re missing any one of them, you don’t have a gap in agents — you have a gap in data, language or automation. That distinction matters, because it tells you where to invest first.

Four foundations before you go agentic

Think of these as readiness pillars built on top of three prerequisites: a data platform, a working LLM capability and an API and automation layer. The foundations below are how you turn that stack into something you’d trust with real work. You don’t need them perfect. You need them good enough for a real workflow.

1. Data the agent can actually use

Agents don’t run on slide decks. They run on the reality of your systems — and the gap between the two is where most early agent projects quietly fail.

For a given workflow, you need an authoritative system of record. You need reasonable data hygiene: IDs that line up across systems, critical fields mostly filled in, obvious duplicates under control. And you need retrieval paths an agent can actually call — APIs, search indices, vector stores — not just dashboards that a human reads.

Sniff test: Pick one workflow, say resolving a recurring support issue. Ask a human expert: “Using only the tools available today, can you find the relevant data and context in under five minutes?” If the answer is “not really”, you’ve found a data readiness gap for agents too.

Practical move: Start with one domain — tickets, orders, incidents, invoices — and make sure it has a clear system of record. Document how to query it programmatically. Fix the top three to five quality issues that keep surfacing in real conversations. You don’t need an enterprise-wide AI data lake to start. You need one solid patch of ground.

2. Tools, not just text

A lot of agentic demos quietly assume something you may not have: reliable, callable actions. The agent in the video creates a record, triggers a workflow, updates a case — and it looks seamless. What’s invisible is the API scaffolding underneath.

Agents become genuinely useful when they can create or update records, trigger automations, and kick off jobs in your ITSM, CRM, RPA or orchestration platforms. For that to work safely, your tools need clear contracts — input and output schemas, error codes and behaviours, latency expectations. They also need safety properties: idempotency where possible so retries don’t cause chaos, a bounded blast radius so a misfiring agent can only touch tickets in a certain state, and sensible timeouts and fallbacks.

Self-check: Take a target workflow — “close low-risk tickets automatically”, for example. List the steps a human takes today. Mark which already have an API or automation, which could be automated with tools you already own but haven’t yet exposed, and which are inherently human — judgement calls, negotiation, relationship management. If there’s nothing in the first two categories, you’re not ready for an agent. You’re ready to build some tools first.

Practical move: Pick one or two high-volume, low-risk actions and expose them as well-behaved tools. Add basic protection: permissions, rate limiting, logging. Treat them as building blocks for multiple future agents, not a single-point solution. Tools built once should serve many agents.

3. Guardrails, governance and observability

This is where the uncomfortable questions live. What if an agent misconfigures production? Who approved the change? How do you roll it back?

The answer can’t be “we’ll figure it out when it happens.” You need policy decisions made upfront: which actions can an agent perform autonomously, which require human approval, and which are strictly observe-only. Agents should have their own identities — service principals or technical users — not borrowed developer accounts. Access should match the agent’s actual mandate, not the path of least resistance.

Equally important is observability. You need logs that capture the goal the agent was working toward, the plan it generated, every tool call with inputs, outputs and timestamps, and the final outcome or handoff. Without that, you’re not managing an agent. You’re hoping one.

Self-check: “If an agent did something wrong yesterday, could we explain what it did, undo it, and prevent a repeat — without a digital forensics exercise?” If the honest answer is no, stay in assisted modes until observability and governance catch up.

Practical move: Start with human-in-the-loop patterns. The agent drafts actions; a human clicks Approve or Edit. Add a kill switch per agent, simple policies like “never act on Premium Tier customers without human sign-off”, and alerting on unusual error or action rates. Only then consider fully autonomous zones.

4. Org ownership and operating model

Even with perfect data, well-behaved tools and solid governance, you still need to answer one question nobody wants to get stuck on: who owns this thing?

Every non-trivial agent needs a product owner who defines its purpose and scope, maintains a backlog of improvements, and keeps business stakeholders aligned on value. It also needs an operations owner responsible for platform health, reliability, security and DR. And it needs feedback loops — channels for the frontline teams who use it to report what’s working, what’s misfiring, and what’s missing.

Treat meaningful agents as products, not toys. For each one, write down its mission in one sentence, define its scope by system and region, set clear success metrics — resolution rate, cycle time, human override rate — and document how new capabilities get promoted and who signs off.

Without this, you end up with shadow agents nobody wants to admit they depend on. That’s not digital transformation. That’s technical debt with a better name.

A staged roadmap: from copilots to digital colleagues

With the foundations clear, here’s a practical maturity path — one you can use as a roadmap or, if you need it, a slide.

Stage 0 — Experiments: chatbots and copilots

Objective: Learn what good looks like with minimal risk.

Deploy chat or document copilots on internal knowledge: FAQs, SOPs, policies, runbooks, playbooks. Let teams use them for drafting responses, answering “how do I…” questions, and summarising documents and threads. This isn’t about automation yet. It’s about building intuition.

Exit when you’ve identified three to five workflows where users say: “If this system could not only answer but also do things, it would be a big deal.” Those are your candidate agent use cases. Capture them.

Stage 1 — Workflow mapping and instrumentation

Objective: Understand the real process end to end before touching it.

Pick one or two candidate workflows with clear business value and contained risk. Run a value stream mapping session with the people who actually do the work: map the steps, systems, handoffs and wait times, and surface the common exceptions and failure modes. Instrument what you can — volumes, cycle times, where work gets stuck or loops.

Exit when you can draw the workflow on a single page and annotate which steps are data lookups, which are decisions with clear rules, and which are actions that could be automated. That diagram becomes the blueprint for your first agent.

Stage 2 — Assisted agents: recommend, don’t press the buttons

Objective: Put an agent in the loop safely.

Build an agent that reads the current context — a ticket, case, order or incident — calls read-only tools to gather information, and proposes a plan with recommended actions. Integrate it into the tools people already use: the service desk console, the CRM screen, the ops dashboard. Humans review the plan, approve or edit recommendations, and execute final actions via normal tooling.

Exit when a healthy proportion of recommendations are being accepted with minimal edits and are clearly improving speed or quality — and when you’ve surfaced and fixed the worst data issues and most brittle automations in the process.

At this stage, the agent is a smart junior colleague sitting beside an expert. Not an unsupervised intern loose in production.

Stage 3 — Narrow autonomy with strong guardrails

Objective: Let the agent own low-risk slices end to end.

Choose narrow scenarios where the rules are clear, the actions are reversible and the impact is measurable. Define hard policies: which customers, regions, ticket types or transaction sizes are in scope, the maximum number of actions per hour or day, and the conditions that always require human sign-off. Implement autonomous execution within those constraints, alongside kill switches and alerts on rising error or override rates.

Exit when you can show clear business impact — 30% faster resolution for a class of issues, for example — with errors within agreed budgets, and when stakeholders trust the agent for that specific scope and are actively asking to expand it.

This is where “digital workforce” starts to mean something. Not because of a leap of faith — because the groundwork is there.

Stage 4 — A portfolio of agents, not a one-off hero

The destination isn’t one giant agent that does everything. It’s a portfolio of specialised agents — for support, infrastructure, finance, sales operations — built on a shared platform that handles identity and access, logging, monitoring, guardrails, policy and tool discovery consistently across all of them.

At this level, agent performance reviews become a normal part of the operating rhythm: what did each agent deliver this quarter, where did it fail, what new capabilities are now justified? Onboarding a new agent starts to look like product onboarding — a repeatable process with known steps — rather than a bespoke science project that requires a specialist to lead it every time.

This is the digital colleagues future people describe on stage. It’s reached via boring, disciplined steps. Not a leap of faith.

Start here Monday

If you’ve skimmed to the end, here’s the short version for your next leadership or architecture meeting.

You don’t have to fix everything everywhere. For a single outcome, you can build a thin vertical slice of the whole stack: one domain of data with clean-enough pipelines; LLM patterns that understand and plan for that domain; a handful of safe, well-wrapped APIs and tools; and an assisted agent workflow on top. Then go deep, not wide. Master the slice before you scale it.

Pick one real outcome — not “do something with agents”, but something measurable: reduce the L1 ticket backlog by 20%, cut quote cycle time by 30%, shorten onboarding by 25%.

Map the true workflow. Get the people who actually do the work into a room. Draw the steps, systems and handoffs. Capture volumes and pain points.

List systems and tools for that workflow. Where does the truth live? What APIs, RPA bots or workflows already exist? What’s missing?

Choose three to five candidate tools — actions an agent could safely call, with clear inputs and outputs, that are reversible or low risk, and high volume or high annoyance.

Decide guardrails upfront. What is read-only? What is recommend-only? What can be fully automated, and under precisely what conditions?

Assign owners. Name a business or product owner for the agent and a technical or platform owner. Both. Before you start.

Build an assisted agent first. Let it plan, gather data and recommend. Keep humans in the loop until the numbers — and your honest comfort level — say otherwise.

Then turn the lessons from that first agent into your second and third. Use what broke or surprised you to improve the platform, refine the guardrails, and standardise patterns and tooling. That’s how a portfolio grows.

Closing thought

Agentic AI is not magic. It’s automation with a better brain — plus all the unglamorous work of data, tools, governance and ownership that nobody puts on the keynote slide.

Invest in those foundations first and your digital colleagues won’t arrive as an uncontrolled experiment. They’ll arrive as well-behaved members of the team, delivering measurable value from day one.

And that’s the bit we don’t hear enough about on stage.