Ryanair’s reported move toward Google Cloud, Gemini agents, and AI-supported operational decision-making is interesting for one reason above all others.
It is not a cloud story.
It is a business-process story.
The airline is exploring where agentic AI can help with areas such as crew planning, disruption handling, fleet operations, and maintenance. AWS remains part of the landscape. Google Cloud gains a larger role. That makes for a neat “dual cloud” headline.
But the important part is what happens between those clouds, the people running the business, and the systems that keep aircraft moving. Because agentic AI is leaving the chat window. It is moving into the operating model.
And that is where the real value is. Also where the real risks begin.
Most companies have already had their first encounter with generative AI.
Someone asks a model to summarise a document. Another person drafts an email in seconds. A team builds an internal knowledge assistant. An innovation unit shows a polished demo that makes everyone in the room say: “Interesting. What else can it do?”
That was an important first step. It made the technology tangible. But it is not yet transformation. A useful chatbot can save an individual a few minutes. A well-designed agent can improve how an entire process works.
That is a very different proposition.
Imagine a maintenance issue in a manufacturing plant. Today, the first signal may come from a machine, an operator, a ticketing system, or a stressed colleague who has already tried three things before calling for help. Information is spread across systems. Maintenance history sits in one place. Spare-part availability in another. Production priorities in a third. The person making the decision has to pull it all together under time pressure.
An agent can help turn that into a connected process.
It can recognise the signal. Check the relevant production order. Retrieve maintenance history. Assess spare-part availability. Identify qualified technicians. Estimate the operational impact of different options. Prepare a recommendation. Route it to the right person. Trigger the agreed next step. Document what happened.
This is no longer “AI that writes something.”
This is AI participating in work.
And that is exactly why agentic AI has the potential to drive much larger performance gains than the first generation of enterprise copilots.
There is a persistent misunderstanding in many AI discussions: the assumption that the endgame is to remove people from the process. It is not. At least, it should not be.
The best agentic systems will not replace human judgement. They will remove the friction that prevents human judgement from being used where it matters.
People are still better at understanding ambiguity, weighing conflicting priorities, recognising unusual context, taking accountability, and making decisions that affect customers, colleagues, or safety. They should not spend their best hours hunting for data in five systems, chasing approvals, copying information between tools, or manually creating the same status update for the seventh time.
That is where agents can help. A good agent does not become a digital employee with an impressive job title. It becomes part of a well-designed operating process. It gathers context faster than a person can. It handles routine coordination. It makes the next best action visible. It spots exceptions early. It knows when to stop. That last point matters.
The promise of agentic AI is not “fully autonomous business.” That sounds clever in a keynote and terrifying in an audit meeting. The promise is a more responsive business in which humans and AI work together, each doing the things they are actually good at.
Many organisations now have a vision for agentic AI. Some have prototypes. A growing number have productive use cases. But truly integrated agentic processes are still rare.
Not because organisations lack models, cloud platforms, or ambition. They struggle because production-grade agentic AI requires several disciplines to work together at once. The business process needs to be understood. Data needs to be reliable. Identity and permissions need to be precise. Systems need safe integration points. Decision rights need to be clear. Risks need to be observable. People need to trust the result enough to use it.
A proof of concept can skip much of this. That is why a POC can look magical on Friday afternoon and become uncomfortable on Monday morning. A demo is usually a narrow path through a controlled environment. Production is a forest full of exceptions.
What happens when the data is late, incomplete, or simply wrong?
What happens when the agent is confident but mistaken?
What happens when a customer case does not fit the usual pattern?
What happens when an ERP interface is unavailable?
What happens when the person responsible disagrees with the ecommendation?
What happens when nobody can explain why the agent took a certain action?
These are not edge cases. They are the actual job.
When people talk about AI risk, they often focus on hallucinations. That is reasonable. A model inventing a fact is not helpful. But in operational business processes, the more dangerous question is often this: what is the agent allowed to do with a wrong answer?
A flawed recommendation that needs human approval may create rework. A flawed action that automatically changes a customer order, blocks a supplier, reschedules a maintenance window, or reallocates a field-service team can create real damage.
The risk is not just intelligence. It is authority.
This is why companies should not ask only, “How capable is this agent?”
They should ask: “What is this agent allowed to read?”, “What is it allowed to recommend?”, “What is it allowed to change?”, “What action requires a human decision?”, “And how quickly can we stop or reverse it?” Those questions may sound obvious. In large enterprises, they rarely have simple answers.
Permissions are often broad. Process ownership is distributed. Data definitions differ across departments. A system that appears to be one process from the outside turns out to be twelve connected workflows, three manual workarounds, and one spreadsheet that everyone hopes nobody will notice.
The spreadsheet, naturally, is usually critical.
A good prompt can improve an interaction. It cannot fix a bad process. Before deploying an agent, the organisation needs a clear view of the process it is trying to improve. Not the happy-path process diagram from a project presentation. The real one.
Where does work actually begin?
Which systems provide the relevant data?
Where do people make decisions today?
Which exceptions are common?
Where do handovers create delays?
What is the business impact of a wrong decision?
How can the process continue if the agent is unavailable?
This is process discovery with sharper consequences.
Once that picture is clear, the deployment can be designed around a simple principle: automate the repeatable, augment the ambiguous, and escalate the consequential.
For example, an agent may be allowed to classify incoming cases, retrieve relevant context, identify missing information, and prepare a recommendation. It may be allowed to trigger low-risk, reversible actions within strict rules. But high-impact decisions should remain with accountable people. That does not make the system less intelligent. It makes the business more resilient.
A safe agentic deployment is not one technology decision. It is a set of connected design choices.
Do not begin with “Where can we use AI?” Start with “Which process creates enough friction that improving it would matter?”. The best first candidates tend to have real volume, known pain points, measurable outcomes, enough structure to define rules, and a process owner who actually wants to improve the workflow.
Service triage, maintenance planning, claims handling, supplier onboarding, sales support, incident management, and capacity planning can all be promising areas. The ideal first use case is not trivial. But it is contained enough to learn safely.
More data does not automatically make an agent better. Unclear, stale, contradictory, or poorly governed data merely makes it confidently confused at scale. An agent needs defined sources of truth. It needs context that is relevant to the decision. It needs to know the freshness of that data. And it needs to respect permissions.
This is why data architecture suddenly becomes a very practical business topic again. If the organisation does not agree on what a customer, an asset, an order status, or a maintenance event actually means, the agent will expose that disagreement quickly. Painfully, perhaps. But usefully.
An agent should not inherit broad human permissions simply because integrating fine-grained access is inconvenient.
That would be like giving an intern the master key because they need access to one meeting room. Agents need their own identities. Their access should be limited to the specific data and actions required for their task. Sensitive operations should require stronger controls. Credentials need to be protected, rotated, and monitored.
Most importantly, the business must understand which identity performed which action. When an agent changes something, there must be an answer to a basic question: who did what, based on which information, under whose authority?
Every agentic process needs an explicit authority model. Some actions are safe to automate. Others should require approval. Some should be blocked entirely unless a specific threshold is met. Think of this as a traffic-light model.
Green actions are low-risk, repeatable, and reversible. The agent can execute them. Amber actions require a person to review and approve the recommendation. Red actions are too consequential, regulated, or uncertain to be delegated. This model should be defined with business owners, risk, security, legal, and operations. Not dropped on them after the pilot has already been built.
If an agent is part of the operation, it must be operated. That means monitoring more than technical availability. You need to see the quality of outcomes.
How often does the agent escalate? How often are its recommendations accepted, changed, or rejected? Which data sources are failing? Where does it create delays instead of removing them? Are certain teams or customer groups affected differently? Can a person understand the reasoning behind a recommendation? An agent without observability is not autonomous. It is unaccountable. And unaccountable systems do not belong in critical processes.
Every important process needs a fallback. Not a vague sentence in a risk register. A tested operating procedure.
If the model is unavailable, what happens? If a connected system fails, what happens? If the agent detects uncertainty, who takes over? If a wrong action is taken, how is it reversed? If a cloud region or a key dependency becomes unavailable, can the process still continue?
This is also where the dual-cloud discussion becomes real. Two cloud providers do not create resilience by themselves. Two copies of data do not create resilience either. A process is resilient only when it can genuinely continue in an alternative environment with the necessary data, identities, integrations, rules, and accountable people in place.
Anything else is a procurement strategy, not an operating model.
The success of agentic AI will not be decided solely by data scientists, architects, or platform teams. It will be decided by the people who run the process every day.
They know where the exceptions live. They know which data can be trusted. They know which decision looks simple but has political, legal, or customer implications. They also know immediately when a supposedly helpful system creates more work. Their involvement is not a change-management checkbox. It is design input.
The organisations that get this right will not present agents as a threat or a shiny replacement. They will show teams how agents remove friction, improve decisions, and give people more room for valuable work. That is a much stronger offer.
Ryanair is an interesting reminder of where this is heading. AI agents are starting to influence the physical world through planning, maintenance, logistics, and operational decisions. Manufacturing, healthcare, energy, transport, and retail will follow the same pattern in different forms.
The winners will not necessarily be the companies with the largest model, the most agents, or the most impressive demo. They will be the companies that connect technology to the reality of work.
They will build processes where data is trustworthy, authority is clear, human judgement is deliberately placed, and failure does not become a crisis. Agentic AI can become a serious performance lever. But only when we stop treating the agent as the product.
The Automated Business Process is the product.
Stay clever. Stay responsible. Stay operational.
The Cloud Advisor,
Uwe Zabel
🚀 Curious how agentic AI can improve business performance without turning core operations into a black box? Follow my journey on The Cloud Advisor’s Book of Stories—where cloud, AI, and business strategy converge. Or ping me directly—because building the future works better as a team.

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.