Skip to main content
FromNine
Menu

AI & data

AI agents and automation that stay inside your limits.

We automate work that takes several steps, using agents and workflows with narrowly scoped tools. They pause for a person’s approval before any action with consequences, and they leave a record your auditors can play back.

For public entities, licence holders and Maltese companies whose teams handle the same process across several systems every day.

Start a conversationExplore service assistance
AI Agents & Automation: the layers we buildFour layers shown one behind the other. Top to bottom: the workflow that keeps track of state, the agent steps within it, the gateway that grants tools their permissions, and the approval step that comes before any action reaches your systems.01Workflow with its state02Steps taken by agents03Gateway and tool scopes04Approval comes first
  1. 01Autonomy set step by step, from a fixed workflow to an agent under supervision
  2. 02Tools with the least privilege they need, behind a gateway with limits for each action
  3. 03A log of each step, tool call and approval that can be replayed and exported

01 Common problems

What makes organisations hold back on automation

  1. 01

    No one can say what the agent may do

    It operates under a service account with wide rights. Your risk and security functions refuse to approve it, and they should not need to guess.

  2. 02

    Good automation figures, a growing pile of exceptions

    Simple cases pass straight through. Everything else ends up in a shared inbox with no context, and the staff dealing with it have more work than they had before.

  3. 03

    After an error, no one can explain it

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

  4. 04

    Robots fail each time a screen is updated

    Critical work depends on robots that read screens. Each new version of an application costs a weekend of fixes.

02 Delivery scope

Our delivery scope

  1. 01 Deciding autonomy one step at a time

    For every step we pick the simplest option that does the job: a fixed workflow, a single call to a model, an agent with tools, or orchestration over several steps. At times the honest conclusion is that an agent does not belong there.

    Our work

    • Walking through the process with the staff who carry it out
    • An autonomy decision for each step, with the risk of that step
    • A BPMN or state machine model of the flow
    • Criteria for giving a step more or less autonomy later

    What you get

    • An autonomy map of the whole process
    • A workflow model kept under version control
    • A recorded decision for every agent step

  2. 02 Tool permissions on a least-privilege basis

    An agent calls tools and never touches a system directly. A tool gateway applies scopes, allow-lists and transaction limits, and each tool runs with a service identity of its own.

    Our work

    • A catalogue of tools that keeps reading and writing apart
    • A narrowly scoped service identity for every tool
    • Rate and transaction limits for each type of action
    • Isolated execution for handling code and files

    What you get

    • A tool gateway whose policy is held in configuration
    • A permission matrix approved by your security function
    • Tests that prove the policy is enforced

  3. 03 Designing the human role in the loop

    Approval thresholds, routing based on confidence and a second approver for actions with consequences. Where a decision concerns a person, a person stays involved, as Article 22 of the GDPR and the right to human review require; in Malta the IDPC supervises this.

    Our work

    • Sorting actions by how serious their consequences are
    • Rules for approval thresholds and escalation
    • A reviewer screen showing the context needed to decide
    • Safeguards for decisions that concern individuals

    What you get

    • An approval policy for each type of action
    • A review workflow inside the tools your staff already use
    • An escalation map naming the responsible teams

  4. 04 Traceability for audit

    A full record of inputs, the context retrieved, model outputs, tool calls and approvals, so that any run can be played back and exported for internal audit or for a supervisor such as the MFSA.

    Our work

    • Design of the event log, with retention rules
    • Replaying runs against fixed inputs
    • Export formats for audit, agreed with internal audit
    • Dashboards for approval and exception rates

    What you get

    • A store for the audit trail
    • Tools to replay runs
    • Dashboards for daily operations

  5. 05 Planning for failure

    An agent will fail at some point, so 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 an authorised person can use.

    Our work

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

    What you get

    • An analysis of failure modes
    • A runbook that includes the kill-switch procedure
    • Chaos tests on the critical paths

  6. 06 Agents next to the automation you already have

    Process mining reveals how the flow actually runs. Robotic process automation remains where a legacy screen is the only way in, and gives way to an API once one is available. We track the exception rate as well as the automation rate.

    Our work

    • Process mining based on event logs
    • A list of current robots with the history of their failures
    • API options to replace fragile screen automation
    • Analysis of exceptions by their cause

    What you get

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

03 Architecture

A reference architecture, shown for illustration

The orchestrator holds the state of each piece of work. Agent steps run within it and reach your systems only through the tool gateway, which checks scope and limits on each call. Tools that read go straight through; tools that write halt at an approval step whenever the action has consequences.

Each action is written to the audit trail. The orchestrator carries timeouts and a kill switch, and every exception reaches a named team together with the full context of the run.

Layers shown in the diagram

Intake
A new case, message or event opens a run that carries a correlation id.
Orchestration
The state of the workflow, the agent steps, compensation and the kill switch.
Permission boundary
The gateway, tools that read, the approval step and tools that write.
Systems
CRM, ERP and case systems, which the agent reaches through tools only.
Audit trail
The record of every run and the team that takes escalations.
Illustrative example

  1. Intake

    • Trigger: case, message or event

  2. Orchestration

    • Orchestrator holding state
    • Agent step
    • Timeouts and kill switch
    • Rollback and compensation

  3. Permission boundary

    • Gateway for tools
    • Tools that read
    • Approval step
    • Tools that write

  4. Systems

    • CRM, ERP and case systems

  5. Audit trail

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

Shown for illustration only; this is not a client system.

Read the diagram as text

The main route leads from a trigger to the orchestrator and an agent step, then to the tool gateway, through an approval step where a person decides, on to a write tool and lastly into the business systems.

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

Approvals and write actions are stored in an audit trail that can be replayed and exported. Together, the gateway, the read tools, the approval step and the write tools make up the permission boundary.

04 Choices and limits

Engineering choices and their limits

  • Each step earns its autonomy

    Our approach

    Every step begins under supervision. We give it more autonomy only after the logs show, over a meaningful number of cases, that it stays within the limits agreed.

    Limits and what we rely on

    Certain steps should stay under human control regardless of the figures. That is a business call, and we will ask you to make it in writing.

  • An agent is as safe as the tools it holds

    Our approach

    Tools that write are narrow and take parameters, for example “issue a credit note up to a set amount”, never “use the ERP”.

    Limits and what we rely on

    When a system lacks a detailed permission model, the gateway has to make up for it. That costs effort, and a few systems can never be made safe enough to write to.

    An AI system can give a wrong output. So actions with consequences wait for a person, and doubtful cases are routed rather than guessed.

  • Prompt injection is a risk to operations

    Our approach

    We treat content from emails, documents and websites as untrusted. It cannot alter the agent’s instructions or extend its permissions, and red-team tests confirm this.

    Limits and what we rely on

    No safeguard takes the risk away entirely. The design expects that an attack will succeed one day and restricts what it could reach.

  • Handling exceptions belongs to the product

    Our approach

    Each exception lands in the queue of the team that owns it, with the context of the run, the reason and a proposed next step.

    Limits and what we rely on

    Without an owner for the exception queue, automation shifts work instead of reducing it. We do not go live until someone is named as that owner.

05 Our method

Our method

Our starting point is the process as it really runs, not the version on the chart, and autonomy is earned one step at a time.

  1. 01

    Observe the actual flow

    Process mining and time spent alongside your staff reveal volumes, variants and the points where time is lost.

    ResultAn analysis of the flow as it runs today

  2. 02

    Set autonomy for each step

    A workflow, a model call or an agent, with the effect of a wrong action recorded for every step.

    ResultAn autonomy map and a permission matrix

  3. 03

    Run alongside staff first

    The system proposes and your staff act. We compare its proposals with their decisions on real cases.

    ResultA report on the shadow run

  4. 04

    Launch with approval steps

    Actions with consequences wait for approval, and thresholds change only on evidence, never on impressions.

    ResultAn approval policy with dashboards

06 People in control

Where people keep the decision

Agents act inside the permissions you grant, ask a person before any action with consequences and record each step they take.

  • Approval comes before the consequence

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

  • Two approvers where it counts

    Above thresholds agreed with you, two people approve. Your risk owner controls the threshold as a setting, not through code.

  • A kill switch with a named user

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

  • Human review of decisions about people

    When a result affects an individual, a person reviews it, and the individual may ask for that review.

  • Escalation to a team that owns it

    Runs that fail or are uncertain go to the team responsible for them, never to an inbox nobody reads.

07 Illustrative case

An illustrative case

Illustrative example

Resident requests at a local council

01Starting point
A local council receives requests from residents by email, web form and phone notes: bulky refuse collection, street lighting faults, permits for events. A small office sorts them by hand, and replies can take days.
02The system we would put in place
An agent classifies each request, checks it against the council’s records, drafts a reply and prepares the work order through tools limited to the case system.
03Where staff decide
Staff approve every reply before it is sent. Anything that commits spending or concerns a complaint about a named person is never handled automatically.
04How we would judge success
Days until a resident receives a reply, share of drafts approved without change, and staff time spent per request.

08 By sector

Sector by sector

  • Financial Services

    For credit institutions, insurers and investment services firms: claims, client onboarding and payment exceptions prepared by agents, with transaction limits, two approvers and audit exports in a format your internal audit has agreed.

  • Government & Public Entities

    Case files in ministries, public entities and local councils where the agent collects and drafts and the public officer decides, with every step kept on record for review and appeal.

  • Manufacturing & Industry

    Changes to orders, supplier chasers and service requests across the ERP and email at pharmaceutical and export plants, with approval wherever money or capacity is committed.

Malta

Automation that Maltese supervisors can follow

An organisation in Malta that automates a process answers to more than one expectation at once. The AI Act and the GDPR right to human review apply to everyone; in Malta the MDIA leads AI Act market surveillance, the IDPC supervises data protection under the Data Protection Act (Cap. 586), and licence holders also face questions from the MFSA. Approval rules inside a group with Maltese operations add their own layer.

We build a single orchestration and a single audit trail, and keep approval thresholds, languages and escalation routes configurable per entity. The risk owner of each entity sees and approves the settings that affect its staff and customers.

Common questions on AI agents and automation

When do you choose an agent rather than a standard workflow?

When the steps are fixed and the input is structured, a workflow costs less, runs faster and is simpler to audit. An agent is worth it where the input varies, the next step depends on what it finds, and a person can check the result. Most systems in production use both.

What prevents an agent from doing something it must not do?

It acts only through tools. Each tool has its own narrowly scoped identity, and the gateway applies the limits on every call. Write actions with consequences wait for approval, and untrusted content cannot alter any of these rules.

We already run RPA robots. Must they go?

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

How will we know it works?

We compare lead time, exception rate, rework and the hours staff spend on exceptions against a baseline measured before launch. The automation rate on its own conceals too much.

Can our internal audit or the MFSA examine what took place?

They can. Each run can be played back from its log, including the inputs, the context retrieved, model outputs, tool calls and approvals. We agree the export formats with your audit function before launch.

Bring us the process that takes most of your team’s time

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

Start a conversationExplore service assistance