IMDA’s agentic AI framework: checks before an agent acts for you

The difference between an AI assistant and an AI agent is easy to state and easy to forget. An assistant drafts; an agent acts. Once software can send the email, change the delivery date or place the order, a wrong answer becomes a wrong action.

Singapore’s Infocomm Media Development Authority (IMDA) published a Model AI Governance Framework for Agentic AI in January 2026 and updated it to version 1.5 in May. It is written for organisations that develop agents and for those deploying agents from third-party suppliers, which includes a small firm switching on an agent feature in software it already uses.

For a small business, its four dimensions become four questions to settle before an agent acts: what may it do, who answers for it, which controls surround it, and what must its users know?

At a glance

• What: IMDA’s Model AI Governance Framework for Agentic AI, launched at the World Economic Forum on 22 January 2026.
• Latest version: 1.5, published on 20 May 2026 after feedback from more than 60 companies, with added case studies and practices.
• Scope: agents using generative AI models as their decision-making engine, built in-house or supplied by a third party.
• Four dimensions: assess and bound risks upfront; make humans meaningfully accountable; implement technical controls and processes; enable end-user responsibility.
• Next step: read the framework document before enabling agent features in business systems.

Why is an agent riskier than a chatbot?

A chatbot’s mistake usually stays on the screen until a person uses it. An agent’s mistake can travel: an update written into the order system, a message sent to the wrong customer, personal data passed to a tool that did not need it, or one bad instruction repeated across hundreds of records.

That is why the framework starts by assessing and bounding risk at the planning stage. It stresses defining an agent’s limits and permissions, allocating responsibility inside and outside the organisation, testing before deployment and monitoring once live.

Worked example: the supplier-delay agent

Take a fictional 20-person kitchen-equipment distributor in Kaki Bukit. Each week, a coordinator reads supplier emails about late shipments, updates expected delivery dates in the order system and tells affected customers. A software vendor offers an agent that could do all three.

Working through the four questions, the owner agrees a narrower first version:

• Bounds: the agent reads the shared supplier-updates mailbox only. It may change the expected-date field on existing orders, never prices, quantities or cancellations.
• Accountability: the operations manager owns the agent and can switch it off. The sales coordinator approves every customer message before it is sent.
• Controls: each change is logged with the email that triggered it. Before launch, the agent is tested on 40 past emails, including partial shipments and messages quoting two different dates. More than 15 date changes in a day pauses it for review.
• People: staff are told what the agent does, what it cannot do and how to report a wrong update. Customers still hear from a person.

All figures are invented. The agent does the reading and record-keeping; anything a customer sees stays a human decision until the logs justify more.

An action ladder for deciding how far to go

1. Observe: the agent reads and summarises; people make every change.
2. Propose: it prepares the change or message; a named person approves each one.
3. Act internally and reversibly: it changes internal records within set limits; every change is logged and can be undone.
4. Act externally or irreversibly: it sends, pays, orders or deletes, within explicit limits, with sampled review and a stop mechanism you have tested.

Move up a rung only when evidence from the rung below supports it: an error rate set in advance and review time actually measured. Our first AI pilot guide explains how to count review time honestly. Many small firms will never need the fourth rung.

A pre-launch checklist

• Write down what the agent may read, change, send and spend, and what it must never touch.
• Give it its own account with the narrowest access the task needs, rather than a staff member’s login.
• Name the owner, the approver for each type of action and the person who can switch it off.
• Test on past or synthetic cases, including awkward ones, before it touches live records.
• Log every action with the input that triggered it, and read the log weekly at first.
• Set thresholds that pause the agent and alert its owner.
• Ask the supplier what data the agent can reach, where it is processed and how incidents are reported.
• Tell staff what it does and how to flag a mistake, and decide what customers should be told.
• Set a review date, and a condition for returning to the old process.

Document the agent’s steps like any process, exceptions included; our process-writing guide shows a format.

What the framework cannot decide for you

The framework describes risks and emerging practice. It does not assess products or tell you whether an agent is worth the checking time; that depends on your error tolerance, your records and the hours spent reviewing.

Personal data needs its own look. If an agent handles customer names, addresses or conversation records, read PDPC’s Advisory Guidelines on Use of Personal Data in Generative AI, issued in July 2026. For customer-facing tools, our guide to IMDA’s chatbot transparency guidelines covers what to tell customers.

Common questions