Skip to main content
FromNine
Menu

AI & data

Automation and AI agents that answer to an accountable officer.

We automate work with several steps using agents and workflows. Each one calls narrowly scoped tools, pauses for an accountable officer before any step with consequences, and keeps a record that your auditors can play back.

For finance, operations and shared service teams in Malaysia that want automation their auditors and regulators can follow.

Arrange a discussionService assistance
AI Agents & Automation: the four layersA stack of four layers, read from top to bottom: the workflow that keeps track of the case, the agent steps within that workflow, the tool gateway with its permissions, and the approval point that comes before any action reaches your systems.01Workflow and case state02Agent steps03Tool gateway and permissions04Approval before action
  1. 01Autonomy decided step by step: some steps stay fixed workflows, others become supervised agents
  2. 02Tools with the smallest permissions that work, behind a gateway with limits on each action
  3. 03A replayable log of each tool call, approval and outcome, exportable for your auditors

01 Common problems

Why organisations hold back on automation

  1. 01

    No one can state what the agent may do

    It runs under one service account with wide access. Risk and information security refuse to approve it, and they should not have to work it out for themselves.

  2. 02

    The automation figure looks fine while exceptions accumulate

    Easy cases pass. The rest pile up in a shared mailbox stripped of context, so the exception team now carries a heavier load than before.

  3. 03

    After an error, nobody can explain it

    Nothing records the data the agent read, the tool it invoked or the approver of the step. Internal audit raises the question and the trail is empty.

  4. 04

    Robots stop working whenever a screen is updated

    Screen-reading robots carry critical tasks. Each new release of the underlying application sends someone to repair them out of hours.

02 Scope of the service

What the service covers

  1. 01 Choosing the level of autonomy step by step

    Per step, we look for the least complex mechanism that delivers: fixed workflow logic, a single call to a model, an agent with tools, or orchestration over several steps. Sometimes our recommendation is to keep agents out of a step altogether.

    Activities

    • Sessions beside the officers who run the process today
    • A decision on autonomy for each step, with the risk of each step noted
    • A state machine or BPMN model of the process
    • Conditions under which a step later gains or loses autonomy

    What you would receive

    • Process map marked with the autonomy of each step
    • The workflow model under version control
    • Decision note per agent step, with its rationale

  2. 02 Tool permissions kept to the minimum

    An agent has no direct line into ERP or CRM; every request passes through a tool. The gateway checks scope, allow-list and amount on each request, and every tool carries its own service identity.

    Activities

    • Tool catalogue split into read-only and write tools
    • One service identity per tool, scoped to its task
    • Ceilings on amounts and call frequency by action
    • Isolated execution whenever code or files are handled

    What you would receive

    • A tool gateway whose policies are configuration
    • Permission matrix signed off by your information security function
    • Tests that prove the policies are enforced

  3. 03 People placed in the process by design

    Approval thresholds, routing by confidence and checks by a second person for actions with consequences. When an outcome concerns an individual, a person stays involved; where that individual is in the EU, article 22 of the EU General Data Protection Regulation (GDPR) and the right to human review require it.

    Activities

    • Grading of actions by their consequences
    • Approval thresholds and rules for escalation
    • A review screen that gives the approver the context needed
    • Safeguards for outcomes that concern individuals

    What you would receive

    • Approval rules written per action category
    • Approver screens built into applications your officers already open daily
    • An escalation map that names the responsible teams

  4. 04 Records that support audit and notification

    A full record of inputs, retrieved context, model output, tool calls and approvals. Any run can be replayed and exported for internal audit or a regulator, and the same log tells you quickly which personal data was involved if a breach must be notified to the Personal Data Protection Commissioner, which the Commissioner’s guidance expects within 72 hours.

    Activities

    • Design of the event log and its retention rules
    • Replay of runs on fixed inputs
    • Export formats settled with internal audit
    • Dashboards for exception rates and approval rates

    What you would receive

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

  5. 05 Safe behaviour when things fail

    Some runs will fail. Our design keeps a failure harmless: repeatable actions, compensating steps and rollback, time limits, handover to a named team, and a stop switch that a designated officer may pull.

    Activities

    • Idempotency keys on each write action
    • Compensating steps for changes that span several systems
    • Time limits and limits on retries
    • Separate stop switches for agents and for tools

    What you would receive

    • An analysis of failure modes
    • Runbook covering how and when to pull the stop switch
    • Injected faults to test critical paths

  6. 06 Agents and your existing RPA robots

    Process mining reveals the real path work takes. Where only a legacy screen offers access, robotic process automation stays; when an API appears, the robot retires. Alongside the automation rate, we watch how many cases fall out as exceptions.

    Activities

    • Process mining on event logs
    • A list of existing robots and how often they have failed
    • APIs that could take over from brittle screen robots
    • Analysis of exceptions by cause

    What you would receive

    • An analysis of the process as it runs today
    • Sequence for retiring screen robots in favour of APIs
    • Baseline hours on exceptions today, and the target

03 Architecture

A reference architecture, for illustration

State lives in the orchestrator. Agent steps run under it and touch your systems only via the tool gateway, which verifies scope and limits per call. Read-only tools pass freely; a write tool with consequences stops until someone approves.

The audit trail captures each step. Time limits and a stop switch belong to the orchestrator, and exceptions travel to a named team with the run’s full history attached.

Layers shown

Intake
Each new case, message or event opens a run tagged with a correlation id.
Orchestration
Holds case state and agent steps; owns compensation and the stop switch.
Permission boundary
Tool gateway, read-only tools, approval point and write tools.
Systems
ERP, CRM and case systems, never touched by an agent except via a tool.
Records
Where the audit trail lives and where escalated cases land with a team.
Illustrative example

  1. Intake

    • Trigger: case, message or event

  2. Orchestration

    • Orchestrator and case state
    • Agent step
    • Stop switch and time limits
    • Compensation and rollback

  3. Permission boundary

    • Tool gateway
    • Read-only tools
    • Approval point
    • Write tools

  4. Systems

    • CRM, ERP and case systems

  5. Records

    • Audit trail: steps, tool calls, approvals; replay and export
    • Named team for exceptions
An agent within a permission boundary

For illustration only; this is not a system built for a client.

Read the diagram as text

The main path leads from a trigger through the orchestrator and an agent step to the tool gateway, then through an approval point where a person decides, then to a writing tool and on to the business systems.

Read-only tools may also query business systems directly via the gateway. A stop switch governs the orchestrator, compensating steps can reverse agent actions, and unresolved cases escalate to a named team.

Everything inside the permission boundary, meaning the gateway, the read-only tools, the approval point and the write tools, reports to an audit trail. That trail can replay and export any approval or write action.

04 Trade-offs and limits

Trade-offs we plan for

  • Each step earns its autonomy

    What we do about it

    Each step starts with a person watching. Only when logs over a meaningful volume of cases show it holding to agreed limits do we loosen supervision.

    Limits and prerequisites

    Certain steps should stay with a person whatever the figures show. That is your business decision, and we will ask you to take it explicitly.

  • Narrow tools make safer agents

    What we do about it

    Writing tools are narrow and take parameters, such as “issue a credit note below a set amount”, never “use the ERP”.

    Limits and prerequisites

    If a system offers only coarse permissions, the gateway compensates. That is extra engineering, and for some systems write access can never be made safe enough.

    AI output can be mistaken. Steps with consequences therefore wait for a person, and uncertain cases are routed to someone rather than guessed.

  • Prompt injection, treated as an operating risk

    What we do about it

    Anything an agent reads in emails, attachments or web pages counts as untrusted input. Such text has no power to rewrite instructions or extend permissions, and our adversarial tests try to prove otherwise.

    Limits and prerequisites

    Mitigations reduce the risk; none eliminates it. We therefore assume one attempt will eventually get through and confine what it could touch.

  • Exceptions belong to the product

    What we do about it

    An exception lands in its owning team’s queue with the run history, the reason it stopped and a proposed next action.

    Limits and prerequisites

    If nobody owns the exception queue, automation just relocates the work. Go-live waits until an owner is named.

05 Working method

Our working method

Our starting point is the process as staff actually run it, not the version in the procedure manual, and autonomy is widened one step at a time.

  1. 01

    Observe the actual process

    Process mining and time spent alongside staff reveal volumes, variants and where delays build up.

    ResultAnalysis of the current process

  2. 02

    Set autonomy for each step

    For every step: workflow, model call or agent, plus a written note of what a wrong action would cost.

    ResultAutonomy map and permission matrix

  3. 03

    Run alongside your staff

    Proposals come from the system while your officers keep acting as usual; we then compare both on live cases.

    ResultReport on the parallel run

  4. 04

    Go live with approvals in place

    Actions with consequences queue for approval, and thresholds move only when evidence justifies it.

    ResultApproval policy and dashboards

06 Human oversight

Where decisions stay with people

Agents work inside the permissions you set, wait for an accountable officer before actions with consequences, and record each step.

  • Approval comes first

    Payments, outcomes for individuals and edits to master data queue for a person, who is shown enough context to decide fast.

  • Two approvers above a threshold

    Above agreed amounts a second approver is required. Your risk owner sets that amount as configuration rather than code.

  • Named roles hold the stop switch

    Any agent or tool can be halted by a named role without redeploying, and that drill is rehearsed.

  • A person reviews outcomes for individuals

    If a result affects an individual, a person looks at it, and the individual may request that review.

  • Escalation to a responsible team

    Runs that stall or fail land with their owning team, never in an inbox no one watches.

07 Scenario

An illustrative scenario

Illustrative example

Rejected e-Invoices in a retailer’s finance team

01Starting point
A retail group issues and receives e-Invoices through MyInvois. Documents that fail validation pile up, and finance staff work out each error and its correction by hand.
02What we would deliver
An agent sorts each rejected document by cause, gathers the order and customer data needed, and drafts the corrected document through scoped ERP tools, without submitting it.
03Decisions that stay with people
A finance officer reviews and releases every corrected document; changes to a buyer’s tax details are never automated.
04How results would be tracked
Days a rejected document stays open, share of drafts released without changes, and staff time spent per rejection.

08 By industry

By industry

  • Financial Services

    Claims, customer onboarding and payment exceptions at banks, insurers and takaful operators, with value limits, approval by two people and audit exports in a format your audit function agrees.

  • Public Sector & Government

    Case preparation in which the agent collects and drafts while the public officer decides, with each step recorded for review and appeals.

  • Manufacturing & Industry

    For manufacturers: order amendments, supplier chasing and service requests spanning ERP and email, with approval wherever cash or capacity gets committed.

Malaysia

Approvals and logs that serve Malaysian rules

An agent that reads customer or staff records processes personal data under the Personal Data Protection Act 2010 (Act 709), the PDPA. Since 1 June 2025 a data controller must notify the Personal Data Protection Commissioner of a personal data breach as soon as practicable, and the Commissioner’s guidance sets 72 hours, so the logs must show quickly what an agent saw and did. The National Guidelines on AI Governance and Ethics (AIGE) remain voluntary guidance.

Many Malaysian teams also process work for companies in the EU. Where the output of an AI system is used in the EU, the EU AI Act can apply to providers and deployers outside the Union, and the EU General Data Protection Regulation (GDPR) gives individuals there rights against decisions based solely on automated processing. We build one orchestration and one audit trail, and keep approval thresholds and escalation routes configurable for each entity.

Questions on AI agents and automation

When is an agent better than an ordinary workflow?

Fixed steps and structured inputs favour a workflow: lower cost, quicker runs and a simpler audit. An agent justifies itself when inputs differ case by case, the next step depends on what turns up and a person can check what came out. Production systems usually mix the two.

How do you stop an agent from overstepping?

It can act only through tools, every tool runs under a scoped identity of its own, and the gateway checks limits on each call. Write actions with consequences wait for approval. Untrusted content has no way to change these rules.

Our RPA robots already work. Do they have to go?

No. Where an old screen is the only way in, the robot stays. Agents take the steps that call for judgement, process mining shows which robots break most often, and those are replaced by API integrations once the systems behind them allow it.

How is success measured?

We compare lead time, exception rate, rework and hours spent on exceptions with a baseline measured before go-live. Reporting the automation rate alone hides most of what matters.

Could our auditors or a regulator reconstruct a run?

Yes. Each run can be replayed from its log, covering inputs, retrieved context, model output, tool calls and approvals. If personal data is involved in an incident, the same log supports a notification to the Personal Data Protection Commissioner. Export formats are agreed with your audit function before go-live.

Which process consumes most of your team’s week?

Before anything is built, we will mark where an agent adds value, where a plain workflow suffices and where an officer must decide.

Arrange a discussionService assistance