<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2592941450723103&amp;ev=PageView&amp;noscript=1">

How Much Control Should AI Agents Have? Lessons from Axon Ivy 14

Nov 02, 2026

AI agents can make enterprise processes more adaptive, but giving them more autonomy also raises questions about governance, transparency, and control. While building Axon Ivy 14, we learned that the answer is not to choose between deterministic processes and AI agents. It is to combine them: let agents make contextual decisions while critical process steps remain governed, traceable, and predictable.

About 18 months ago, when we started planning Axon Ivy 14, almost every customer conversation seemed to carry two very different sentiments at the same time.

There was excitement about how quickly AI could fundamentally change the way enterprise software is built. Some even predicted that platforms would soon become obsolete because any application could simply be generated from a prompt.

At the same time, there was a much more pragmatic question, and I still believe it is the most important one:

Where exactly does AI create real value, and how much of what we are seeing is still vision rather than reality?

We asked ourselves the same question as a team and spent many hours discussing it.

The result is the most extensive modernization of our platform since version 4. More importantly, the process taught us several lessons that I believe matter to any IT organization deciding what foundation it wants to use for its business processes over the next several years.

AI Is No Longer a Feature. It Is Part of the Foundation.

At first, we viewed AI primarily as an integration, another capability that could be added to existing workflows.

The deeper we went, the clearer it became that this view was too narrow.

AI is changing two things at once: how applications are built and how processes are orchestrated at runtime.

If you take both seriously, AI cannot simply be treated as another feature. It has to become part of the platform itself.

For CIOs, that has an immediate consequence. Choosing a process orchestration platform today also means deciding how much control your organization will retain over the way AI operates within its processes.

Why AI Makes Process Platforms More Important, Not Obsolete

The idea that AI will make platforms unnecessary does not hold up well in practice.

Ask a coding assistant to build an employee onboarding process from scratch, and it has to start from zero. Before it can even address the actual business process, it needs to design hosting, workflow logic, task management, permissions, data persistence, and monitoring.

In other words, it first has to build all the infrastructure the process will eventually rely on.

That takes time and computing resources. But from an IT perspective, there is a bigger issue.

Every application built this way becomes a one-off solution with its own architecture, security logic, and operational requirements. What looks impressively fast in isolation can create a new form of shadow IT at scale, only much faster than before.

Now put the same assistant on top of a platform that already provides roles, forms, task management, monitoring, and a user portal.

The assistant can focus on what actually matters: the business process.

Development becomes faster, less costly, and, most importantly, more predictable because everything the assistant builds follows the same underlying standards.

That is why we moved our development environment fully into Visual Studio Code and made the platform’s building blocks accessible to AI coding assistants such as GitHub Copilot and Claude Code.

Our internal Version 14 materials describe the same architecture: AI tools work with Axon Ivy-specific schemas and platform capabilities rather than having to recreate workflow infrastructure themselves.

That decision also meant saying goodbye to a development environment that many people had used for years.

Decisions like that can be painful. But I believe a platform only becomes future-ready when you focus on a small number of things that truly matter instead of trying to improve everything a little.

How Much Autonomy Should an AI Agent Have?

No question occupied us internally for as long as this one.

Axon Ivy is a very open platform. Developers can use it to implement almost anything. At the same time, no enterprise wants an AI agent to be allowed to do absolutely anything.

Anyone who has managed large process orchestration projects will recognize the tension.

Fully modeled processes are reliable, testable, and auditable. But in large projects, they can grow into what we have sometimes called “spaghetti BPMN,” with every exception adding another possible path through the model.

AI agents work differently.

They receive a task or objective and determine how to proceed. They can handle exceptions remarkably well, but their individual decisions are not always predictable.

This may be where many AI agent projects are currently getting stuck. The limiting factor is not necessarily model performance. It is often trust, transparency, and governance.

Our answer is Smart Workflow, based on a simple idea: stop treating AI agents and deterministic processes as opposites.

The agent handles the orchestration. It analyzes a case, asks follow-up questions when necessary, and determines the next appropriate step.

But the tools available to that agent are clearly defined process components.

If the agent invokes an approval process that requires a four-eyes principle, that process runs exactly as modeled. There is no room for interpretation within that controlled subprocess.

That is the fundamental principle behind Smart Workflow: deterministic BPMN processes remain binding where control is required, while the agent can dynamically orchestrate them based on context.

What does this look like in practice?

We tested the approach with our own support process.

If a ticket is missing version information, the system automatically asks the customer for it without requiring a person to review the ticket first.

A licensing question that does not belong in technical support is routed to Account Management instead of sitting in the wrong queue.

And a well-documented issue can bypass the usual support levels and go directly to the appropriate development team.

The underlying business logic has not changed. The difference is that the process no longer needs to anticipate and explicitly model every possible branch in advance.

The support scenario was also demonstrated in the Version 14 webinar, including dynamic routing and requests for missing information.

How Do You Govern AI Agents in Enterprise Processes?

For this approach to work in an enterprise environment, I believe governance has to exist at three levels.

That is why we built those three levels directly into the platform.

1. Governance by design

Anything that must follow a specific sequence is modeled as a process.

The agent cannot bypass those steps, regardless of how it orchestrates the rest of the case.

2. Guardrails and human intervention

Guardrails should intervene before something goes wrong.

For example, someone might try to inject instructions into the model through a support ticket. Or an agent could get caught in a loop and consume budget without anyone noticing.

In cases like these, the process stops and a person takes over.

The Version 14 implementation supports this Human-in-the-Loop approach by combining runtime guardrails with controlled process boundaries. The webinar demonstration included a prompt injection example in which the automated process stopped and handed the case over for manual review.

3. Monitoring and traceability

You also need to be able to understand what happened after the fact.

For every case, it should be possible to see which data was sent to which model, which tools the agent called, and what those calls cost.

Once you need to explain a decision to an auditor, a data protection team, or a customer, that level of traceability is no longer a nice-to-have. It becomes a prerequisite for using AI in production.

Axon Ivy’s AI governance capabilities provide visibility into model usage, messages, tool calls, token consumption, response times, and related execution data.

Why Enterprises Should Retain Control Over Their AI Models

We made one decision very deliberately: Axon Ivy does not come with its own language model.

Organizations connect the models they already use or are permitted to use, whether through major cloud providers or locally on their own infrastructure.

This is more than a technical detail. It is a strategic consideration.

The language model market is evolving too quickly for organizations to lock themselves into a single model for years. Existing contracts, data protection requirements, and security policies should continue to apply rather than being undermined by the introduction of a new platform.

Our internal product materials describe this approach as bring your own model, with support for different cloud-based and locally hosted LLMs.

That also requires being honest about maturity.

A locally hosted model can be perfectly adequate for many classification tasks, especially because most business processes do not depend on millisecond response times.

Processing large volumes of images or data, or supporting AI-assisted development, requires more capable models.

And whatever an AI assistant builds still needs to be reviewed by a human.

That applies to every platform. Anyone promising otherwise is selling the vision rather than the operational reality.

Six Questions to Ask When Evaluating an AI Process Orchestration Platform

If I were evaluating a process platform today, I would ask these six questions, regardless of the vendor:

1. Does AI work with standardized platform components, or does every AI-generated application become a one-off solution?

2. Can you define which process steps an AI agent must follow, and are those requirements technically enforced rather than simply written into a prompt?

3. Are there guardrails that can stop a process and hand control over to a person?

4. Can you trace every agent decision afterward, including the data, model, and associated costs?

5. Does the organization retain control over which language model it uses, including the ability to switch models later?

6. Does the platform connect the systems you already have, or does adopting it require replacing them?

These questions go beyond whether a platform can technically run an AI agent. They address the harder question: Can you use agents in enterprise processes without giving up the governance, interoperability, and control those processes require?

Axon Ivy 14: A Foundation for AI-Powered Process Orchestration

For us, Version 14 is therefore less about a feature release and more about creating a foundation for enterprise process orchestration.

We connect people, existing systems, and AI agents within the same process while giving IT visibility into who or what made a decision and why.

I believe the organizations that succeed with AI agents over the next few years will not necessarily be those that deploy the most agents the fastest.

They will be the ones that learn how to give agents responsibility without giving up control.

Thomas Zehetner and I demonstrated what that looks like in our Version 14 release webinar, from AI-assisted application development to the orchestration of a supplier onboarding process. The webinar recording provides the full demonstration.

Watch the Axon Ivy Version 14 webinar