Search

What are you looking for?

Search our services, use cases and practical insights.

Enter at least 2 characters

Popular starting points

Agents and automation

Which processes suit AI agents – and which do not?

An agent is most useful when the goal and boundaries are clear but the route varies by case. Greater autonomy does not fix unclear accountability or a poorly understood process.

The short answer

AI agents suit variable, multi-step tasks with digitally available information and controlled tools, where the outcome can be assessed objectively. They are a poor fit for unclear goals, uncontrolled failure impact, missing data access or decisions that inherently require human judgement and accountability.

In brief

  • High case variation and a clearly testable goal favour an agent over a fully stable process.
  • The agent needs bounded, reliable tools and a safe route for exceptions and hand-offs.
  • High impact, hard-to-reverse actions and unclear accountability argue against broad autonomy.
  • The process, data quality and success measure should be sufficiently understood before an agent is introduced.

Which characteristics favour an agent?

An agent can add value when a task has a clear outcome but the required steps vary by case. Common examples include research across several sources, selecting suitable tools and iteratively working through unstructured information.

The outcome must still be testable. If neither domain experts nor software can determine whether the objective was achieved, the agent cannot be evaluated or operated reliably.

  • A clear objective and measurable completion criteria
  • Meaningful variation that a fixed decision tree handles poorly
  • Digitally available information and narrowly bounded tools
  • Observable intermediate results that can be corrected

When is an agent the wrong choice?

An agent usually makes a stable, rule-based process more expensive and less predictable. Nor does it repair a chaotic process without ownership simply because a model selects steps. Missing rules and poor data quality should first be addressed organisationally.

  • The route and exceptions are fully known and deterministic
  • Failures can immediately cause serious harm to people, finances, rights or safety
  • The outcome cannot be assessed objectively or in time
  • Required data and system access are not reliable
  • No one owns the process, approvals and operation

How should a candidate be assessed before implementation?

Assess real cases, not the abstract idea. Document normal cases, exceptions, participating systems, current processing time and failure impact. This shows whether a workflow, one bounded AI step or an agent is appropriate.

How should a candidate be assessed before implementation?
Decision questionIf yesIf no
Are the objective, owner and quality measure clear?Study real cases and data accessClarify the process and accountability first
Is the route mostly known and rule-based?Automate a fixed workflowIdentify what causes case paths to vary
Does only one bounded step require language or document understanding?Place one bounded AI step inside the workflowAssess whether several steps must be chosen dynamically
Must the system choose sources or tools for each case?Compare a narrowly bounded agent in a pilotA workflow or conventional process improvement is usually sufficient
Can impact be bounded, results tested and hand-offs made safely?Pilot with read-only and preparatory permissionsReduce autonomy or keep the task with people

What does a responsible first pilot look like?

The pilot starts with a limited user group, realistic cases and primarily read-only or preparatory capabilities. Every action remains traceable; people initially approve all consequential effects. A fixed end point prevents the pilot from silently becoming an uncontrolled production system.

  • Define expected value and unacceptable failures in advance
  • Limit tool count, runtime, spend and data access
  • Treat hand-offs and system outages as dedicated test cases
  • Expand only after quality and operational ownership are demonstrated
Example from day-to-day business

Example: suitability assessment in technical support

Technical incidents vary by product, version and previous diagnosis. An agent may read logs, find relevant handbook sections and prepare a diagnostic plan. It cannot change production configuration. The team measures resolution rate, time to correct escalation and unnecessary tool calls. A simple password reset remains a fixed workflow because its route and controls are known.

What to remember

A good agent candidate combines real case variation with a clear objective, bounded tools and measurable quality. Where these foundations are missing, process work is the better first step.

Sources and further reading

These primary sources provide further detail on definitions, technical foundations or responsible use.

Content reviewed

Would you like to apply this to your situation?

Together, we clarify what makes sense for your process, data and systems – in plain language and without unnecessary complexity.

Discuss Your Project