Skip to main content
FromNine
Menu

AI & data

AI agents and automation that act within the limits you set.

We automate multi-step work with agents and workflows that use scoped tools, stop for approval before consequential actions and leave a trail your auditors can replay.

For shared service centres and operations teams that run the same process across several countries and systems.

Discuss your projectSee service assistance
AI Agents & Automation: capability stackFour layers stacked in depth. From top to bottom: the workflow that holds state, the agent steps inside it, the tool gateway with its permissions, and the approval gate before actions reach your systems.01Workflow and state02Agent steps03Tool gateway and scopes04Approval, then action
  1. 01The right degree of autonomy per step, from fixed workflow to supervised agent
  2. 02Least-privilege tools behind a gateway, with limits per action
  3. 03Every step, tool call and approval logged, replayable and exportable

01 Problems

Why automation programmes hesitate

  1. 01

    Nobody can say what the agent is allowed to do

    It runs under a broad service account. Risk and security will not sign off, and they should not have to guess.

  2. 02

    The automation rate looks good, the exceptions pile up

    Straightforward cases flow through. The rest lands in a shared mailbox without context, and the team that handles them is now busier than before.

  3. 03

    When it goes wrong, nobody can reconstruct why

    There is no record of which data the agent saw, which tool it called or who approved the step. Internal audit asks, and there is no answer.

  4. 04

    The bots break whenever a screen changes

    Screen-scraping robots carry critical work. Every application update means a weekend of repairs.

02 Delivery ledger

What we deliver

  1. 01 Autonomy design per step

    For each step we choose the simplest thing that works: a deterministic workflow, a single model call, a tool-using agent or multi-step orchestration. Sometimes the right answer is that an agent is the wrong tool.

    What we do

    • Process walk-through with the people who do the work
    • Step-by-step autonomy decision with risk per step
    • State machine or BPMN model of the flow
    • Exit criteria for moving a step to more or less autonomy

    What you receive

    • Autonomy map of the process
    • Workflow model under version control
    • Decision record for each agent step

  2. 02 Tool permissions and least privilege

    Agents call tools, never systems directly. A tool gateway enforces scopes, allow-lists and transaction limits, and every tool runs under its own service identity.

    What we do

    • Tool catalogue with read and write tools separated
    • Scoped service identities per tool
    • Transaction and rate limits per action type
    • Sandboxed execution for code and file handling

    What you receive

    • Tool gateway with policy as configuration
    • Permission matrix approved by security
    • Test suite for policy enforcement

  3. 03 Human-in-the-loop design

    Approval thresholds, confidence-based routing and four-eyes checks for consequential actions. Decisions about people keep a person in the loop, in line with GDPR article 22 and the right to human review.

    What we do

    • Classification of actions by consequence
    • Approval thresholds and escalation rules
    • Reviewer interface with the context needed to decide
    • Safeguards for decisions about individuals

    What you receive

    • Approval policy per action type
    • Reviewer workflow in the tools your teams already use
    • Escalation map with named teams

  4. 04 Traceability and audit

    A complete record of inputs, retrieved context, model outputs, tool calls and approvals, so any run can be replayed and exported for internal audit or a supervisor.

    What we do

    • Event log design with retention rules
    • Replay of runs against fixed inputs
    • Audit export formats agreed with internal audit
    • Dashboards for exception and approval rates

    What you receive

    • Audit trail store
    • Replay tooling
    • Operational dashboards

  5. 05 Failure handling

    Agents will fail. We design so that failure is safe: idempotent actions, compensation and rollback, timeouts, escalation to a named team and a kill switch that someone is authorised to use.

    What we do

    • Idempotency keys on every write action
    • Compensation steps for multi-system changes
    • Timeouts and retry budgets
    • Kill switch per agent and per tool

    What you receive

    • Failure mode analysis
    • Runbook with kill-switch procedure
    • Chaos tests for the critical paths

  6. 06 Agents alongside existing automation

    Process mining shows the flow as it really runs. Robotic process automation stays where only a legacy screen exists, and moves to APIs as soon as one does. We measure exception rate, not just automation rate.

    What we do

    • Process mining on event logs
    • Inventory of existing robots and their failure history
    • API alternatives for fragile screen automation
    • Exception analysis by cause

    What you receive

    • Current-flow analysis
    • Migration plan from screens to APIs
    • Baseline and target for exception handling time

03 Architecture

An illustrative reference architecture

The orchestrator owns the state of the work. Agent steps sit inside it and can only reach your systems through the tool gateway, which checks scope and limits on every call. Read tools pass through; write tools stop at an approval gate when the action is consequential.

Everything leaves a record in the audit trail. A kill switch and timeouts sit on the orchestrator, and exceptions go to a named team with the full context of the run.

Layers in the drawing

Intake
A new case, message or event starts a run with a correlation id.
Orchestration
Workflow state, agent steps, compensation and the kill switch.
Permission boundary
Tool gateway, read tools, approval gate and write tools.
Systems
CRM, ERP and case management, reached only through tools.
Trace
The audit trail and the team that handles escalations.
Illustrative example

  1. Intake

    • Trigger: case, message, event

  2. Orchestration

    • Orchestrator and state
    • Agent step
    • Kill switch and timeouts
    • Compensation and rollback

  3. Permission boundary

    • Tool gateway
    • Read tools
    • Approval gate
    • Write tools

  4. Systems

    • CRM, ERP, case management

  5. Trace

    • Audit trail: every step, call and approval, with replay and export
    • Named team for exceptions
Agent inside a permission boundary

Illustrative architecture, not a client system.

Read the diagram as text

The main route runs from a trigger through the orchestrator and an agent step to the tool gateway, then through an approval gate where a person decides, then to a write tool and finally to the business systems.

The gateway also allows read tools that query business systems directly. A kill switch controls the orchestrator, compensation steps can undo agent actions, and the orchestrator escalates to a named team.

Approvals and write actions are recorded in an audit trail that supports replay and export. The gateway, read tools, approval gate and write tools together form the permission boundary.

04 Considerations and limits

Engineering considerations and limits

  • Autonomy is earned per step

    How we handle it

    Steps start supervised. We widen autonomy only when the logs show the step behaves within agreed limits over a meaningful volume of cases.

    Limits and dependencies

    Some steps should never be autonomous, whatever the numbers say. That is a business decision, and we will ask you to make it explicitly.

  • Agents are only as safe as their tools

    How we handle it

    Write tools are narrow and parameterised: "create a credit note up to a limit", never "call the ERP".

    Limits and dependencies

    Where a system has no fine-grained permission model, we compensate in the gateway. That adds work, and some systems cannot be made safe enough for write access.

    AI output can be wrong. That is why consequential actions stop for a person and uncertain cases are routed, not guessed.

  • Prompt injection is an operational risk

    How we handle it

    Content from emails, documents and web pages is treated as untrusted. It cannot change the agent’s instructions or widen its permissions, and red-team tests check that it does not.

    Limits and dependencies

    No mitigation removes the risk completely. The design assumes an attempt will one day succeed and limits what it can reach.

  • Exceptions are part of the product

    How we handle it

    Every exception arrives with the run’s context, a reason and a suggested next step, in the queue of a team that owns it.

    Limits and dependencies

    Automation moves work rather than removing it if nobody owns the exception queue. We will not go live without a named owner.

05 How we work

How we work

We start from the process as it runs, not as it is drawn, and earn autonomy step by step.

  1. 01

    See the real flow

    Process mining and shadowing show volumes, variants and where time is lost.

    OutputCurrent-flow analysis

  2. 02

    Decide autonomy per step

    Workflow, model call or agent, with the consequence of a wrong action written down for each step.

    OutputAutonomy map and permission matrix

  3. 03

    Run in shadow mode

    The system proposes, people act. We compare its proposals with their decisions on live cases.

    OutputShadow-run report

  4. 04

    Go live with approvals

    Consequential actions wait for approval; thresholds are reviewed on evidence, not on feeling.

    OutputApproval policy and dashboards

06 Human control

Where people stay in control

Agents act within permissions you define, ask for approval before consequential actions and log every step.

  • Approval before consequence

    Payments, decisions about individuals and changes to master data wait for a person, with the context needed to decide quickly.

  • Four eyes where it matters

    Above agreed thresholds, two people approve. The threshold is a setting your risk owner controls, not code.

  • A kill switch someone may use

    Each agent and each tool can be stopped by a named role, without a deployment, and the procedure is rehearsed.

  • Human review for decisions about people

    Where an outcome affects an individual, a person reviews it and the individual can ask for that review.

  • Escalation to a named team

    Uncertain or failed runs go to a team that owns them, never to an unattended mailbox.

07 Example

An illustrative example

Illustrative example

Supplier invoice exceptions in a shared service centre

01Situation
A finance shared service centre serves subsidiaries in four countries. Invoices that do not match a purchase order wait in a queue for days while staff chase buyers by email.
02What we would build
An agent gathers the order, receipt and contract terms, drafts a resolution and a message to the buyer, and proposes the posting through scoped ERP tools.
03Where people decide
Postings above a per-entity threshold need two approvals. Anything touching a supplier’s bank details is never automated.
04What we would measure
Days an exception stays open, share of proposals accepted without change, and time spent per exception.

08 Sector lens

In your sector

  • Financial Services

    Claims, onboarding and payment exceptions handled by agents with transaction limits, four-eyes approval and audit exports in a format agreed with your audit function.

  • Public Sector & Government

    Case preparation where the agent gathers and drafts, and the civil servant decides, with every step recorded for review and objection procedures.

  • Manufacturing & Industry

    Order changes, supplier follow-up and service requests across ERP and email, with approvals at the points that commit money or capacity.

International

Automation across borders and supervisors

A shared service centre that serves entities in several Member States automates one process under several sets of expectations. The EU AI Act and the GDPR right to human review apply everywhere; how a supervisor or a works council looks at automated decisions still differs by country, and so do approval rules inside the group.

We keep one orchestration and one audit trail, and make approval thresholds, languages and escalation routes configurable per entity. Each country’s risk owner sees and signs off the settings that apply to their people and customers.

Questions about AI agents and automation

How do you decide between an agent and a normal workflow?

If the steps are known and the inputs are structured, a workflow is cheaper, faster and easier to audit. Agents earn their place where inputs vary, the path depends on what is found, and a person can check the outcome. Most production systems combine both.

What stops an agent from doing something it should not?

It can only act through tools, each tool runs under its own scoped identity, and the gateway enforces limits on every call. Consequential write actions stop for approval. Untrusted content cannot change those rules.

We already use RPA. Do we throw it away?

No. Robots on legacy screens keep working where no API exists. We add agents for the judgement steps, use process mining to find the fragile robots, and replace them with API integrations as the underlying systems allow.

How do you measure success?

By throughput time, exception rate, rework and the time people spend on exceptions, against a baseline taken before go-live. The automation rate alone hides too much.

Can internal audit or a supervisor inspect what happened?

Yes. Every run can be replayed from its log: inputs, retrieved context, model outputs, tool calls and approvals. Export formats are agreed with your audit function before go-live.

Bring the process that keeps your team busiest

We will map where an agent helps, where a workflow is enough and where a person must decide, before anything is built.

Discuss your projectSee service assistance