Don't go all in on AI

Agents are everywhere right now. Every company is working on bringing them into their workflows, and SAP is no different. My team sits one step back from that — we build MCP servers and the tools agents call. That vantage point gives you a particular perspective: you see very clearly where agents thrive and where they stumble.

Then I came across a video by a contracting company that put words to something our team feels every day. They built an agentic AI system for a pharma client, went all in on AI from the start, and ran into a wall. The goal was to detect changes in revenue and act on them — a use case that seemed perfect for a fully agentic approach. It wasn't, at least not entirely.

Before getting into their story, it helps to define the two ends of the spectrum. Deterministic systems follow clearly defined, predictable processes. They operate like assembly lines: each component performs a specific function in a predetermined sequence, and the output is always traceable back to the input. Agentic systems, by contrast, involve greater autonomy — the agent dynamically determines which steps to take based on evolving context. Rather than following a fixed sequence, it can plan, adapt, loop back, and use different tools depending on what it finds.

Neither is inherently superior. The challenge is knowing which to reach for, and when to combine them.

The pharma system worked like this: the agent checks last month's sales data, compares it to the same month from the prior year, and if the change exceeds a threshold, investigates the root cause. Once identified, it produces a proposal — either how to reverse a decline or how to replicate a period of growth.

Initially, every step ran through an LLM. The results were unreliable. Reports were inconsistent, root causes were missed, and the recommendations lacked the precision the client needed.

The turning point came when the team recognized that the anomaly detection step always follows the same logic — the signals never change. So they replaced that part with a deterministic pipeline that consistently executes the same steps:

• checks sales data in Databricks
• groups the data by region
• ranks regions by performance
• compares this month against the same month last year
• scores the change on a scale from 1 to 10 (5 = no change, 10 = strong growth, 1 = decline)
• returns the result to the agent to reason over

Before this change, the agent might skip steps or approach the comparison differently each time. That non-determinism is valuable in open-ended reasoning, but it works against you when the task has a fixed, correct procedure. Hardening that part of the flow made the whole system more reliable.

Encouraged by those results, they applied the same lens to the investigation phase. The engineers noticed it also relies on the same fixed set of sources every time. Over time, new sources might be added, but the underlying requirement — retrieve all relevant data — never changes. So they defined deterministic tools covering aspects like subscription counts, drug subsidies, and the number of prescriptions per patient. There is no value in being "creative" about which data to pull; the domain constrains it. Once those data points are collected, the agent reasons over them to identify the root cause and produce a proposal.

What I find valuable about this story is not that they got it wrong at first — that is normal — but that they shared the process of arriving at the right balance. Every project, company, or team will have to go through this same iteration. Building agents is not straightforward, and there is no universal blueprint.

This is why I find the framing of a spectrum so useful: deterministic and agentic approaches are not opposites where you have to pick a side. They sit on a scale, and neither is inherently superior. The most effective AI implementations find their position on that spectrum based on the specific requirements of the use case — not based on what is trending.

In practice, this means you can start at either end. Start fully agentic and discover where the system is unreliable, then harden those parts with deterministic tools. Or start fully deterministic and identify where fixed rules are too rigid, then introduce an agent to handle the variation. Both paths are valid. The work is in the iteration — observing where things break or stall, and adjusting. That is exactly the journey this team went through, and it is the same journey our team experiences working on the MCP server side: building reliable, predictable tools that agents can actually depend on.

If you are starting an AI project, the first question worth asking is not "should we use agents?" but "which parts actually need to be agentic?" Expect things to shift as you go; getting the balance right from the start is the exception, not the rule.

Published by...

Jernej Klancic

Visit author page