Can an agent take actions in our systems?

It can support permitted actions when the workflow, system boundary and exception route are clear. The first decision is which action is safe to automate and which remains human.

Do we need clean data first?

You need enough approved information to define a useful first job. The work should reveal unreliable or missing context before the agent is asked to cover it.

When is a single agent not enough?

When the work needs genuinely different specialisms, different permissions per step, or steps that must run in parallel and then reconcile. Those cases are multi-agent architecture, which is Agentic AI Development, and it carries coordination cost most buyers do not need. If one agent with well-scoped tools can do the job, that is the cheaper and more debuggable answer.

How will we know it is worth what it costs?

By whether the queue behind the task got shorter, which is a business measure rather than a model one. Agreeing that measure before the build is the part most often skipped, and its absence is why a working agent can be impossible to defend six months later.

Many steps is not the test

AI agents are useful when work takes more than one step and the next action depends on approved context.

We build agents around a defined job, permitted information, controlled actions and a clear route to a person when the system should stop.

Talk to a senior engineer Need a workflow assessment?

Building and running software since 2007A clear route to a person when the system should stop

One taskNine steps

0 / 9steps where the next action depends on approved context

Verdict · not an agent

Some work is deterministic and should use ordinary workflow automation.

Illustrative of the test this page applies, not a client task.

What we can build

An agent is not the answer just because a task has many steps.

Some work is deterministic and belongs in ordinary automation; some is a conversation and belongs in a chatbot. An agent earns its place when it must choose a next step across systems.

Operational agents
Gather approved context, prepare a task, take permitted actions and hand over when the case needs judgement. The useful version of this is narrower than it sounds. An agent that prepares a case well and hands over cleanly is worth more than one that attempts the whole task and is right most of the time, because the second kind requires every output to be checked anyway.
Research and knowledge agents
Work across approved information to prepare a traceable brief, recommendation or next step for a person to review. Traceable is the operative word. A recommendation nobody can audit back to its sources cannot be defended to a customer, an auditor or a colleague, which means in practice it will not be used for anything that matters.
Product-embedded agents
Place an agent inside a software journey where its output, permissions and next action must fit the product rules. Here the constraint is the product, not the agent. Existing permissions, audit requirements and interface conventions all apply, and an agent that ignores them creates a second set of rules inside the same product.
Human-in-the-loop agents
Prepare work and complete limited actions while stopping at the point an accountable person must approve or decide. Most first agents should be this kind. The scope can widen once the stop conditions have been tested against real cases, and widening from evidence is considerably safer than narrowing after an incident.

Before it acts

Four boundaries before an agent can act

Four boundaries, in the order they have to be settled. The sequence below assumes all four have been answered.

The job
Name what the agent moves forward, what a useful completion looks like and what remains outside its scope.
The permitted context
Identify the approved information and systems the agent may use. It should not make a decision from a broad, unowned pool of data.
The action boundary
State which actions may happen automatically, which need confirmation and which the agent must never initiate.
The human route
Decide who receives an uncertain, high-consequence or failed case, with the context needed to resolve it.

How the work runs

How the work operates

Four steps in order. The first two settle the job and what may be used to reach it, before any access, action boundary or escalation rule is set.

Map the current task
Identify the trigger, systems, decisions, exceptions and people involved.
Define the first bounded job
Choose one outcome and the approved options the agent may use to reach it.
Connect context and controls
Set source access, permissions, action boundaries and escalation rules around the job.
Review live exceptions
Improve the agent, source or underlying process from the cases real work reveals.

What makes it trustworthy

What makes an agent trustworthy in practice

The relevant technical questions are where context comes from, which system permissions are needed, what actions are allowed, how exceptions are logged and how a change is reviewed.

Clear input and source ownership
The agent can show what it used to prepare a next step.
Limited permissions
A useful agent does not need unlimited access to every system.
Visible stop conditions
The system does not quietly continue when judgement is required.
Reviewable actions and handoffs
A person can understand what happened and take over with context.

Tools support those decisions; they do not replace them.

Quiet failure

How to tell an agent has quietly stopped working

A failing agent rarely announces itself. It keeps running and the output slowly stops being right. That is the question worth asking before you commission one.

Escalations fall to almost none
Reads as success
What it usually means
The agent has stopped recognising cases it cannot handle, not that quality improved
What should already be in place
An expected escalation rate, so a drop reads as a fault rather than a success
Escalations rise sharply
Reads as a fault
What it usually means
Either the input mix changed or a source became unreliable
What should already be in place
Escalation reasons captured, not just counts
Humans quietly stop using the output
Reads as success
What it usually means
The result is technically correct and not useful in the actual task
What should already be in place
Someone watching adoption, not only accuracy
Output looks right and outcomes do not improve
Reads as success
What it usually means
The agent was applied to a step nobody was waiting on
What should already be in place
The business measure agreed before the build
Reviewers approve everything
Reads as success
What it usually means
The review queue has become a formality
What should already be in place
Sampled re-checks of approved cases

Four of these five look like success in a dashboard. That is why the operating rules and stop conditions are set before the build, not after the first incident.

Evidence

Where this work has been done

Agents are only as good as the controls around them, and those controls are in delivered Viithiisys work.

Fitelo, evaluation and cost controls in production
An AI product running with evaluation and cost controls in place, rather than shipped and watched.
Those controls are the discipline this page argues an agent needs. It is not an agent engagement.
Milo, a product used under time pressure
A driver-facing system where a slow or wrong response has an immediate operational cost.
Which is the case for a stop condition and a named person to receive what stops.
Vizitor, a platform in daily multi-site use
Contextual scale only: 500+ workplaces across 15+ countries.
Cited as evidence of software that has to keep working, not as an agent engagement.

See all case studies

None of these is an agent engagement, and none is offered as one. They are cited as context for the controls this page says an agent needs, and no figure on this page is read off any of them.

FAQ

Questions teams ask

Pick a topic, or ask us directly. We answer every inbound within one business day.

Still have questions?

Talk to a senior engineer, not a bot.

Talk to us

Which page you want

Choose the right intervention before you build autonomy.

If the need is customer answering, explore AI Chatbot Development. If it is a defined handoff, see AI Workflow Automation. For broader generative work, see Generative AI Development.

Fixed triggers, rules and next actionsAI Workflow AutomationDeterministic work, which is more reliable without an agent in it
A customer or employee conversation with a known answer/handoff pathAI Chatbot DevelopmentA conversation with a known answer belongs in a chatbot
Contextual multi-step work and permitted actionsAI Agent Development · you are hereInterpretation, approved options, and a route back to a person
Genuinely different specialisms or permissions per stepAgentic AI DevelopmentMulti-agent architecture, and coordination cost most buyers do not need
Generative AI product work beyond an agentGenerative AI DevelopmentGenerating the output rather than deciding the next action
A product journey or source process that is itself unclearBroken Workflow AssessmentThe process is the problem, so it is settled before anything is built

Start here

Show us the multi-step work you want to improve.

Bring the multi-step task, systems involved, known exception and the person who owns the decision when the agent should stop.

Talk to a senior engineer Need a workflow assessment?

AI agents are useful when work takes more than one step and the next action depends on approved context.

An agent is not the answer just because a task has many steps.

Operational agents

Research and knowledge agents

Product-embedded agents

Human-in-the-loop agents

Four boundaries before an agent can act

The job

The permitted context

The action boundary

The human route

How the work operates

Map the current task

Define the first bounded job

Connect context and controls

Review live exceptions

What makes an agent trustworthy in practice

Clear input and source ownership

Limited permissions

Visible stop conditions

Reviewable actions and handoffs

How to tell an agent has quietly stopped working

Escalations fall to almost none

Escalations rise sharply

Humans quietly stop using the output

Output looks right and outcomes do not improve

Reviewers approve everything

Where this work has been done

Fitelo, evaluation and cost controls in production

Milo, a product used under time pressure

Vizitor, a platform in daily multi-site use

Questions teams ask

Choose the right intervention before you build autonomy.

Show us the multi-step work you want to improve.