At the iBusiness conference "Daten & KI 2026" in Germany, our founder Daniel Kalkowski explained why so many AI agent projects don't fail because of the model. They fail because of the missing framework.
Getting an AI agent up and running today is often easier than answering the questions that actually matter: What is it allowed to do? Who checks its results? And can anyone later reconstruct how a decision was made?
The talk introduced four patterns for integrating AI agents into business processes in a way that actually holds up.
Two Numbers That Belong Together
Two Gartner forecasts frame the topic and explain why so many projects fail. By 2028, around 15 percent of everyday work decisions are expected to be made autonomously by agentic AI. At the same time, Gartner expects that roughly 40 percent of agentic AI projects will be abandoned by the end of 2027, mainly due to rising costs, unclear value, and insufficient control.
These two numbers don't contradict each other. Quite the opposite: together, they show exactly what's at stake.
The potential is real. But building an agent and hoping for good results isn't enough. Without a clear framework, value, cost, and risk stay hard to measure.
Chat vs. Process: Where the Difference Actually Lies
A freely operating AI agent receives its instructions mainly through prompts, skills, and context. How it processes that information and what steps it takes from there is decided by the model itself, within its own scope of action.
That can be powerful. But results can vary from run to run. And when someone later asks why a particular decision was made, the answer isn't always easy to find.
An AI agent embedded in a defined process works differently.
The process sets the frame, modeled in BPMN, for example. The agent operates at defined points within it. When it starts, which tools it can use, and what happens to its output is technically fixed in the process itself.
Naturally, the two approaches can be combined. A chat agent can call a defined process as a tool. What matters most, in our view: control shouldn't live in the prompt alone. It belongs in the process.
The Four Patterns at a Glance
Pattern 1: Defined Triggers
The first control point sits before the agent even runs: when does a process start in the first place?
That can be triggered by events in existing systems: an ERP, CRM, online shop, or an incoming email. External events can trigger a process too, for example when market prices shift and a price adjustment needs to be reviewed.
Increasingly, agents also call other processes as tools via protocols like MCP. Even then, the process being called remains a clearly defined frame.
Pattern 2: A Limited Toolset
An agent should only be able to access the tools, systems, and data it actually needs for its specific task.
That raises a few key questions:
- Which tools is the agent allowed to use?
- Which data can it access?
- Which models are available to it?
What matters is that these limits aren't just a recommendation written into a prompt. A sentence like "you may only access this data" is not the same as a technical configuration that actually enforces that boundary.
Access and permissions should be technically controlled and secured through a proper role and rights system.
A simple test question: what control mechanisms do we actually have in place today?
If the honest answer is mostly "a paragraph in the prompt," it's worth a closer look.
Pattern 3: Approval Points for Humans or Rules
AI can generate proposals, classify content, or prepare decisions. But not every output should be acted on automatically.
At certain points in the process, a clear approval step is needed. That can be a human, following a human-in-the-loop approach. Or it can be a clearly defined, deterministic rule that can be verified in code.
Only after that approval does the result get used further downstream.
This matters most wherever errors are costly: AI can take on valuable work, but it shouldn't be the final authority.
Pattern 4: End-to-End Logging
Traceability instead of a black box: for every step in the process, it should be clear which data went in and what result came out.
For agents specifically, you can log:
- What context did the agent receive?
- What response did it produce?
- Which tools did it use?
- What did it cost?
This isn't just useful for compliance and audits. It's also the foundation for actually evaluating your own AI use: what's working, where do errors happen, which processes are expensive to run, and which model delivers the best results for a given task?
When You Don't Need AI Agents
Perhaps one of the most important points from the talk: not every task needs an AI agent.
If a task is fully rule-based, classic automation is usually the better choice: faster, cheaper, and reproducible.
The same applies where data structures are fixed and transformations are clearly defined; AI isn't strictly necessary there either. And for tasks like price calculations, billing, or deadlines, where exact reproducibility is critical, standard rules are often the safer option.
A process doesn't automatically get better just because you add an AI agent to it.
We're firm believers in the potential of AI. That's exactly why good advice also means being honest about where AI doesn't add real value.
Traceability and Data Quality
An important question from the talk: can the relevant department still explain how last week's AI output came about, or does that require IT?
The EU AI Act makes transparency and documentation requirements binding for AI use, depending on the specific use case. When approval points and logs are anchored directly in the process, it at least becomes traceable what happened, when, which data was processed, and who signed off on a decision.
Data quality is another foundation that matters just as much. Every automation project, with or without AI, is only as good as the data it's built on.
If important data is missing, poorly structured, or flawed, reliably automating a process becomes difficult. The four patterns don't replace that groundwork; they depend on it.
Research backs this up, too. Fraunhofer FIT describes a comparable model in its whitepaper "From Rigid Workflow to Hybrid Action Space" (August 2026): defined action spaces and process structures serving as a governance framework for AI agents. Worth a read.
Conclusion: The Framework Decides
AI agents rarely fail because of the model alone. More often, it's other questions that determine success or failure:
- What is the agent allowed to do when in doubt?
- Who steps in when something goes wrong?
- And can anyone later trace how a result came about?
Defined triggers, a limited toolset, clear approval points, and end-to-end logging create a framework in which AI agents can actually be used and improved over time.
They make it possible to evaluate value, cost, and risk in the first place, and turn a freely operating AI system into a controllable part of a business process.
We would be happy to show you how easy and flexible process automation with swoox.io is.
Or you can try it out for yourself right away.
