Skip to main content
FromNine
Menu

AI & data

AI agents that work inside a maker-checker discipline.

We automate multi-step operational work with agents and workflows that call narrowly defined tools, pause for an authorised officer before any consequential action, and keep a record that internal audit can replay step by step.

For operations teams and global capability centres in India that run one process for entities in India and in the European Union.

Share your requirementsView service assistance
AI Agents & Automation: the four layersFour layers drawn one behind the other. Top: the workflow that keeps the state of each case. Second: the agent steps within it. Third: the tool gateway that holds the permissions. Bottom: the checker’s approval before anything reaches your systems.01Workflow and case state02Agent steps03Tool gateway and permissions04Checker approves, then action
  1. 01Autonomy set step by step, from a fixed workflow to an agent under supervision
  2. 02Tools with the narrowest rights needed, behind a gateway that caps each action
  3. 03Each step, tool call and approval logged, so incidents can be traced and reported to CERT-In on time

01 Challenges

Why automation stalls in risk review

  1. 01

    No one can state the agent’s permissions

    It runs on a single broad service account. The CISO and the risk function refuse to approve it, and they should not be asked to approve something undefined.

  2. 02

    Straight-through cases rise, exceptions pile up

    Simple cases pass cleanly. The remainder lands in a common inbox with no context, and the operations team handling them has more work than before.

  3. 03

    After an error, nobody can trace the cause

    No record shows what data the agent read, which tool it invoked or who approved the step. The auditor asks and there is nothing to show.

  4. 04

    Screen bots fail with every application release

    Robots that read and type into screens carry critical processes. Each upgrade of the underlying application costs a weekend of fixes.

02 Scope of work

Scope of the practice

  1. 01 Choosing the level of autonomy for each step

    Each step gets the simplest mechanism that does the job: a fixed workflow, one model call, an agent with tools or a coordinated set of agents. In some steps the honest conclusion is that no agent should be used.

    Scope of work

    • Walk-through of the process with the staff who run it
    • Autonomy decision and risk rating for each step
    • Model of the flow as a state machine or in BPMN
    • Criteria for giving a step more or less autonomy later

    Deliverables

    • Autonomy map of the whole process
    • Version-controlled workflow model
    • Recorded decision for every agent step

  2. 02 Least-privilege tools

    Agents never touch a system directly; they call tools. A gateway applies scopes, allow-lists and value limits, and each tool runs under a service identity of its own.

    Scope of work

    • Tool catalogue that separates read tools from write tools
    • A scoped service identity for each tool
    • Value and frequency limits by type of action
    • Isolated execution for code and file handling

    Deliverables

    • Gateway with its policies held as configuration
    • Permission matrix signed off by information security
    • Automated tests proving the policies are enforced

  3. 03 Maker-checker built into the flow

    The agent acts as maker; an authorised officer acts as checker. We set approval limits, route by confidence and add a second checker for high-value actions. Where an outcome affects an individual, such as a loan or a claim, a person decides; for people in the EU this also reflects Article 22 of the GDPR.

    Scope of work

    • Ranking of actions by their consequence
    • Approval limits and escalation matrix
    • Checker screen showing the context needed to decide
    • Safeguards for outcomes that affect individuals

    Deliverables

    • Approval policy for each action type
    • Checker workflow inside the tools your staff already use
    • Escalation matrix with named teams

  4. 04 Audit trail and reconstruction

    Inputs, retrieved context, model output, tool calls and approvals are all recorded. Any run can be replayed and exported for internal audit, a regulator’s inspection or an incident report.

    Scope of work

    • Event log design, including retention and synchronised timestamps
    • Replay of a run against its original inputs
    • Export formats agreed in advance with internal audit
    • Dashboards showing exception and approval rates

    Deliverables

    • Store for the audit trail
    • Replay tools
    • Dashboards for the operations team

  5. 05 Safe failure

    Agents do fail. The design makes failure harmless: actions that can be repeated without side effects, compensating steps and rollback, time limits, escalation to a named team and a stop control that a designated role may use.

    Scope of work

    • Idempotency keys on each write action
    • Compensating steps for changes across several systems
    • Time limits and retry budgets
    • Stop control for each agent and each tool

    Deliverables

    • Analysis of failure modes
    • Runbook including the stop procedure
    • Fault-injection tests on the critical paths

  6. 06 Agents next to the bots you already run

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

    Scope of work

    • Process mining on system event logs
    • Register of current bots and their failure history
    • API options to replace fragile screen automation
    • Exceptions analysed by root cause

    Deliverables

    • Analysis of the flow as it runs today
    • Plan to move from screens to APIs
    • Baseline and target time for handling exceptions

03 Architecture

Reference architecture (illustrative)

The orchestrator holds the state of each case. Agent steps run within it and reach your systems only through the tool gateway, which checks scope and limits on every call. Read tools go straight through; a write tool with consequences halts at the checker until an authorised officer approves.

Every action is written to the audit trail with a synchronised timestamp. Time limits and a stop control sit on the orchestrator, and exceptions reach a named team together with the full history of the run.

Layers shown

Intake
A new case, message or event opens a run with its own correlation id.
Orchestration
Case state, agent steps, compensation and the stop control.
Permission boundary
Tool gateway, read tools, the checker and write tools.
Systems
CRM, ERP, loan and case systems, reachable only by way of tools.
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 and case state
    • Agent step (maker)
    • Stop control and time limits
    • Compensation and rollback

  3. Permission boundary

    • Tool gateway
    • Read tools
    • Checker approval
    • Write tools

  4. Systems

    • CRM, ERP, loan or case system

  5. Audit trail

    • Audit trail of each step, call and approval, for replay and export
    • Named team for exceptions
An agent within a permission boundary

An illustration only; not drawn from any client system.

Read the diagram as text

The primary path leads from a trigger to the orchestrator, then to an agent step and the tool gateway, then to a checker where an authorised officer decides, then to a write tool and on to the business systems.

The gateway also permits read tools that query the business systems directly. A stop control governs the orchestrator, compensating steps can reverse agent actions, and the orchestrator hands exceptions to a named team.

Approvals and write actions are stored in an audit trail that allows replay and export. Gateway, read tools, checker and write tools together make up the permission boundary.

04 Trade-offs and limits

Design trade-offs and limits

  • Each step earns its autonomy

    How we address it

    Every step begins under supervision. We extend its autonomy only after the logs show it stays inside the agreed limits across a meaningful number of cases.

    Limits and prerequisites

    Certain steps should never run unattended, whatever the figures show. That is a business call, and we will ask your management to make it in writing.

  • An agent is as safe as the tools it is given

    How we address it

    Write tools are narrow and take fixed parameters, for example “raise a credit note up to a set value”, never “access the ERP”.

    Limits and prerequisites

    When a system lacks fine-grained permissions, the gateway has to make up for it. That costs effort, and some systems cannot be made safe enough for an agent to write to them.

    A model can be wrong. Consequential actions therefore wait for a checker, and doubtful cases are routed to staff rather than guessed.

  • Prompt injection is a risk to operate against

    How we address it

    Text from emails, attachments and websites is handled as untrusted input. It cannot alter the agent’s instructions or extend its permissions, and adversarial tests confirm this.

    Limits and prerequisites

    No control removes the risk entirely. We assume an attack will succeed at some point and restrict what it could reach.

  • The exception queue is part of the system

    How we address it

    Each exception carries the run history, a reason and a proposed next step, and lands in the queue of a team that is accountable for it.

    Limits and prerequisites

    Without an owner for the exception queue, automation only shifts work around. We do not go live until an owner is named.

05 Delivery steps

Delivery steps

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

  1. 01

    Observe the actual flow

    Process mining and time with the operations team reveal volumes, variants and the points where time is lost.

    OutcomeAnalysis of the current flow

  2. 02

    Set autonomy step by step

    Workflow, model call or agent for each step, with the consequence of a wrong action recorded against it.

    OutcomeAutonomy map and permission matrix

  3. 03

    Run alongside the team

    The system suggests and staff act. We compare its suggestions with their actual decisions on live cases.

    OutcomeParallel-run report

  4. 04

    Go live with checkers in place

    Consequential actions wait for an authorised officer, and approval limits are revised on evidence rather than impression.

    OutcomeApproval policy and dashboards

06 Approvals

Who approves what

The agent is the maker. It works within permissions you grant, waits for a checker before consequential actions and records each step.

  • A checker before any consequence

    Payments, outcomes for individuals and changes to master data wait for an authorised officer, who sees the context needed to decide promptly.

  • Two checkers above the limit

    Above the agreed value, two officers approve. The limit is a setting held by your risk owner, not something written into code.

  • A stop control with a named holder

    A designated role can halt any agent or tool without a new deployment, and the procedure is practised in advance.

  • Individuals get a human decision

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

  • Escalation to an accountable team

    Doubtful or failed runs go to a team that owns them, never to an inbox that nobody watches.

07 Scenario

Illustrative scenario

Illustrative example

Loan document checks at a non-banking financial company

01Starting point
Credit operations at an NBFC receive loan files with income proofs, bank statements and property papers. Staff check each file by hand against the credit policy, and incomplete files go back and forth with the branch for days.
02What we would set up
An agent reads the file, lists what is missing or inconsistent against the policy, drafts the query to the branch and prepares the credit appraisal note through read-only tools on the loan origination system.
03Where an officer decides
Sanction stays with the credit officer. Loans above a set value need a second approver, and changes to the borrower’s bank account details are never automated.
04How success would be measured
Days a file stays incomplete, share of agent checklists accepted without correction, and officer time spent on each file.

08 By industry

By industry

  • Banking & Financial Services

    Loan document checks, claims and payment exceptions at banks, NBFCs and insurers, prepared by agents within value limits and approved by a checker, with exports in the format your internal audit specifies.

  • Government & Public Sector

    Applications and grievances where the agent collects records and drafts a reply, the officer decides, and each step is logged for review and appeal.

  • Manufacturing & Industry

    Order amendments, vendor follow-up and dealer service requests across ERP and email, with approval wherever money or plant capacity is committed.

India

One process, Indian and EU expectations

A capability centre in India that processes work for European group companies automates under two sets of expectations. For EU entities, the EU AI Act and the GDPR right to human review apply. At home, the DPDP Act governs personal data in prompts and tools, and the CERT-In Directions require listed cyber incidents to be reported within six hours, which only works when every agent action is logged with a reliable timestamp.

We run one orchestration and one audit trail, and hold approval limits, languages and escalation routes as settings per entity. The risk owner for each entity reviews and approves the settings that affect its customers and staff.

FAQs on AI agents and automation

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

When the steps are fixed and the data is structured, a workflow costs less, runs faster and is simpler to audit. An agent is justified where inputs vary, the next step depends on what is found and a person can verify the result. Most systems in production use both.

How do you prevent an agent from overstepping?

It can act only through tools; each tool has its own narrowly scoped identity, and the gateway applies limits to every call. Write actions with consequences wait for a checker. Content from outside cannot alter these rules.

Our RPA bots are already in place. Must they go?

No. Bots on older screens continue to run where there is no API. We add agents for the steps that need judgement, use process mining to locate the brittle bots, and swap them for API integrations as your systems make that possible.

Which measures show that it works?

Turnaround time, exception rate, rework and the staff hours spent on exceptions, each compared with a baseline recorded before go-live. The automation rate by itself conceals too much.

Can internal audit or a regulator see what the agent did?

Yes. Any run can be reconstructed from its log, covering inputs, context retrieved, model output, tool calls and approvals. Export formats are settled with your audit function before go-live, and the same log supports a six-hour incident report to CERT-In.

Bring the process that consumes most of your team’s day

Before anything is built, we will show where an agent helps, where a workflow suffices and where an authorised officer must decide.

Share your requirementsView service assistance