Skip to main content
FromNine
Menu

AI & data

AI agents and automation that stay inside your limits.

We automate work that runs over several steps, using agents and workflows. They call narrowly scoped tools, pause for sign-off before any action with real consequences, and leave a record your auditors can replay step by step.

For operations teams in Irish organisations, from council case handling to fund administration, where one process runs through several systems.

Talk to us about your projectExplore service assistance
AI Agents & Automation: the layersFour layers, one behind the other. First the workflow that keeps track of state, then the agent steps that run within it, then the tool gateway with its permissions, and last the approval gate every action passes before it reaches your systems.01Workflow holding state02Steps taken by agents03Tool gateway with scopes04Sign-off, then the action
  1. 01For each step, the level of autonomy it warrants, from a fixed workflow to an agent under supervision
  2. 02Tools with only the privileges they need, behind a gateway that sets limits per action
  3. 03Each step, tool call and sign-off recorded, so it can be replayed and exported

01 Problems

Where automation programmes get stuck

  1. 01

    Nobody knows what the agent may actually do

    It runs on a broad service account. Risk and security refuse to approve it, and it is unfair to ask them to guess.

  2. 02

    Good automation figures, a growing pile of exceptions

    Simple cases go straight through. Everything else ends up in a shared inbox with no context, and the people who deal with it are busier than before.

  3. 03

    After a failure, nobody can piece together what happened

    Nothing shows which data the agent looked at, which tool it used or who approved the step. Internal audit asks and gets no answer.

  4. 04

    Robots that break with every screen change

    Critical work depends on bots that scrape screens. Each application update costs a weekend of fixes.

02 Delivery ledger

What you get from us

  1. 01 Choosing the autonomy for each step

    Step by step we pick the simplest option that does the job: a fixed workflow, one model call, an agent that uses tools, or orchestration across several steps. Sometimes the honest answer is that an agent does not belong there.

    What we do

    • Walking through the process with the staff who carry it out
    • A decision on autonomy for every step, with its risk written down
    • A model of the flow as a state machine or in BPMN
    • Criteria for giving a step more autonomy, or taking it back

    What you receive

    • A map of autonomy across the process
    • The workflow model, kept under version control
    • A recorded decision for every agent step

  2. 02 Least privilege for every tool

    Agents only ever reach systems through tools. A tool gateway applies scopes, allow-lists and transaction limits, and each tool has its own service identity.

    What we do

    • A tool catalogue that keeps read and write tools apart
    • A narrowly scoped service identity for each tool
    • Limits on transactions and call rates per kind of action
    • Sandboxes for running code and handling files

    What you receive

    • A tool gateway whose policy is configuration
    • A permission matrix your security team has approved
    • Tests that prove the policy is enforced

  3. 03 Designing people into the loop

    Sign-off thresholds, routing based on confidence, and a second approver for actions with consequences. Where a decision concerns an individual, a person stays involved, in keeping with Article 22 GDPR and the right to obtain human intervention.

    What we do

    • Sorting actions by their consequences
    • Sign-off thresholds and rules for escalation
    • A review screen that gives reviewers the context to decide
    • Safeguards for decisions that affect individuals

    What you receive

    • A sign-off policy for each kind of action
    • Review steps inside the tools your teams already use
    • An escalation map naming the teams involved

  4. 04 A trail auditors can follow

    Inputs, retrieved context, model outputs, tool calls and approvals are all recorded, so internal audit or a regulator can replay and export any run.

    What we do

    • An event log design with retention rules
    • Replaying runs against fixed inputs
    • Export formats that internal audit has agreed
    • Dashboards for exception and sign-off rates

    What you receive

    • A store for the audit trail
    • Tooling to replay runs
    • Dashboards for day-to-day operations

  5. 05 When things go wrong

    Agents will fail at some point. We make failure safe: actions that can be repeated without harm, compensation and rollback, timeouts, escalation to a named team, and a kill switch that a specific person is allowed to use.

    What we do

    • An idempotency key on each write action
    • Compensating steps for changes across several systems
    • Timeouts and limits on retries
    • A kill switch for each agent and each tool

    What you receive

    • Analysis of failure modes
    • A runbook covering the kill switch
    • Chaos tests on the critical paths

  6. 06 Agents next to the automation you have

    Process mining shows how the flow really runs. Robotic process automation stays where a legacy screen is the only way in, and gives way to APIs once one exists. We track the exception rate, not only the automation rate.

    What we do

    • Process mining on your event logs
    • An inventory of current robots and how often they fail
    • API options to replace fragile screen automation
    • Analysis of exceptions by cause

    What you receive

    • Analysis of the flow as it runs today
    • A plan to move from screens to APIs
    • A baseline and a target for time spent on exceptions

03 Architecture

Reference architecture, for illustration

The orchestrator holds the state of the work. Agent steps run inside it and can reach your systems only through the tool gateway, which checks scope and limits on each call. Read tools go straight through; a write tool with consequences waits at an approval gate.

Every action is written to the audit trail. The orchestrator carries a kill switch and timeouts, and exceptions reach a named team together with everything that happened in the run.

Layers in the drawing

Intake
A new case, message or event opens a run with its own correlation id.
Orchestration
State of the workflow, agent steps, compensation and the kill switch.
Permission boundary
The tool gateway, read tools, the approval gate and write tools.
Systems
CRM, ERP and case management, which agents reach only through tools.
Trace
The audit trail, and the team that takes escalations.
Illustrative example

  1. Intake

    • Trigger: a case, message or event

  2. Orchestration

    • Orchestrator holding state
    • Agent step
    • Kill switch, timeouts
    • Compensation, rollback

  3. Permission boundary

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

  4. Systems

    • CRM, ERP and case systems

  5. Trace

    • Audit trail of every step, call and approval, replayable and exportable
    • Named team for exceptions
An agent within a permission boundary

An illustration, not a client’s system.

Read the diagram as text

The main route starts with a trigger, passes the orchestrator and an agent step, reaches the tool gateway, then an approval gate where a person decides, then a write tool, and ends at the business systems.

The gateway also lets read tools query the business systems directly. A kill switch governs the orchestrator, compensation steps can reverse what an agent did, and the orchestrator escalates to a named team.

Approvals and write actions go into an audit trail that can be replayed and exported. Together, the gateway, the read tools, the approval gate and the write tools make up the permission boundary.

04 Considerations and limits

What to weigh up, and where the limits are

  • Each step earns its autonomy

    How we handle it

    Every step begins under supervision. We give it more freedom only when the logs show it keeping within agreed limits across a meaningful number of cases.

    Limits and dependencies

    Some steps should stay with people whatever the figures show. That is a business call, and we will ask you to record it.

  • An agent is only as safe as its tools

    How we handle it

    Write tools are narrow and take parameters: “raise a credit note up to a set amount”, never “call the ERP”.

    Limits and dependencies

    Where a system lacks fine-grained permissions, the gateway makes up for it. That costs extra work, and some systems will never be safe enough to write to.

    Generated output is sometimes wrong, so actions with consequences wait for a person and doubtful cases are routed to someone rather than guessed.

  • Prompt injection is a risk to operations

    How we handle it

    We treat text that arrives by email, in documents or on web pages as untrusted. It cannot alter the agent’s instructions or extend its permissions, and red-team tests confirm this.

    Limits and dependencies

    No safeguard removes the risk entirely. The design assumes that one attempt will eventually get through, and limits what it could reach.

  • Exceptions belong to the product

    How we handle it

    Each exception carries the context of its run, the reason it stopped and a proposed next step, and lands with the team responsible for that queue.

    Limits and dependencies

    If nobody owns the exception queue, automation only shifts work around. We do not go live until someone is named as owner.

05 How we work

How we work

We begin with the process as it actually runs rather than as the diagram shows it, and widen autonomy one step at a time.

  1. 01

    Watch the real flow

    Process mining and time spent alongside the team reveal volumes, variants and where the hours go.

    OutputAnalysis of the current flow

  2. 02

    Set autonomy step by step

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

    OutputAutonomy map with permission matrix

  3. 03

    Shadow the team first

    The system suggests and people act. We compare its suggestions with what staff decided on live cases.

    OutputReport on the shadow run

  4. 04

    Launch with sign-off

    Actions with consequences wait for approval, and thresholds change on evidence rather than gut feeling.

    OutputSign-off policy and dashboards

06 Human control

Where your people keep control

Agents work within permissions you set, check with a person before any action with consequences, and record what they do at every step.

  • Sign-off before consequences

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

  • A second approver where it counts

    Above thresholds you agree, two people approve. Your risk owner controls that threshold as a setting, not in code.

  • A kill switch someone may actually use

    A named role can stop any agent or tool without a deployment, and the procedure is practised in advance.

  • A person reviews decisions about people

    When an outcome affects an individual, a member of staff reviews it, and the person concerned has the right to request that review.

  • Escalation to a named team

    Runs that fail or are uncertain go to a team responsible for them, never to a mailbox nobody watches.

07 Example

An example, for illustration

Illustrative example

Supplier invoice exceptions at a distributor

01The situation
A distributor in Ireland receives invoices from many suppliers, more of them arriving as structured e-invoices ahead of Revenue’s VAT modernisation. Invoices that do not match a purchase order sit for days while the accounts payable team chases buyers by email.
02What we would put in place
An agent collects the order, goods receipt and contract terms, drafts a resolution and a note to the buyer, and proposes the posting through narrowly scoped ERP tools.
03Where staff decide
Postings above an agreed amount need two approvals. Changes to supplier bank details always stay with people.
04How we would judge it
How long an exception stays open, the share of proposals accepted unchanged, and staff time per exception.

08 Sector lens

By sector

  • Financial Services

    Claims, onboarding, KYC refresh and payment exceptions at banks, insurers and fund administrators, with transaction limits, a second approver and audit exports in the format your audit function has agreed.

  • Public Service & Government

    Planning and housing case files prepared by an agent for council staff, who make the decision, with each step recorded for internal review and appeals.

  • Manufacturing & Industry

    Order changes, supplier follow-up and service requests that run through the ERP and email in pharma, medtech and electronics plants, with sign-off wherever money or capacity is committed.

Ireland

Automation that Irish supervisors can follow

An automated step in Ireland can fall under more than one supervisor. The Data Protection Commission oversees the GDPR right not to be subject to decisions based solely on automated processing, and under the Regulation of Artificial Intelligence Act 2026 the AI Office of Ireland coordinates sector authorities such as the Central Bank of Ireland and the CCPC. Irish operations of international groups often answer to approval rules set by a group function abroad as well.

We run one orchestration and one audit trail, with approval thresholds, languages and escalation routes held as settings per entity or business unit. The risk owner for each sees and approves the settings that affect their staff and customers, and a council or State agency can show exactly where a public servant took the decision.

Questions we hear about AI agents and automation

When is an agent the right choice instead of a plain workflow?

When the steps are known and the inputs structured, a workflow costs less, runs faster and is easier to audit. An agent is worth it where inputs vary, the route depends on what turns up along the way, and a person can check the result. Most systems in production use both.

What keeps an agent from doing something it should not?

It can act only through tools. Each tool runs under its own narrow identity, and the gateway applies limits to every call. Write actions with consequences wait for sign-off, and untrusted content cannot change any of these rules.

We already run RPA. Does it have to go?

No. Robots on legacy screens carry on where there is no API. We add agents for the steps that need judgement, use process mining to spot the fragile robots, and swap them for API integrations as the systems underneath make that possible.

How do you judge whether it works?

Against a baseline taken before launch: throughput time, exception rate, rework and the hours people spend on exceptions. The automation rate on its own conceals too much.

Can internal audit or a regulator see what happened?

Yes. Any run can be replayed from its log, covering inputs, retrieved context, model outputs, tool calls and approvals. Your audit function settles the export formats with us before launch.

Bring the process that takes up most of your team’s week

Before anything is built, we will map where an agent adds value, where a plain workflow will do and where a person has to decide.

Talk to us about your projectExplore service assistance