IMDA's Model Governance Framework for Agentic AI, read by builders.

On 22 January 2026, Singapore’s Infocomm Media Development Authority launched the Model AI Governance Framework for Agentic AI (“MGF”) at WEF in Davos. It is, at the time of writing, the only formal agentic-AI governance framework published by a national regulator. If you build for Singapore gov, regulated industries, or any MNC headquartered here, it’s about to become procurement-relevant.

This piece is not the legal reading. It’s the builder’s reading. The question we want to answer: of all the controls in the MGF, which ones cost real engineering hours, and which ones are zero-cost if you architect for them up front?

How we read the framework

The MGF organizes around lifecycle controls — design, build, deploy, monitor, retire — and around accountability for autonomous action. Most of it tracks the same disciplines a competent agentic team would apply anyway. But “anyway” is doing a lot of work in that sentence. Here’s the split.

Zero-cost (if you architect for it)

These are the controls that cost essentially nothing to satisfy if your system was designed correctly from day one. They cost a lot to retrofit.

Audit trail of agent actions

If your agent’s actions are logged as structured events keyed to the input that triggered them, this is free. The MGF expectation: a regulator can reconstruct what the agent did, why, and on what data. Most teams that retrofit this discover their controller logs everything to stdout and have to rebuild the eventing layer.

Bounded autonomy / engineer-written safety envelopes

The MGF asks for explicit constraints on what an agent can do, and a record of those constraints being reviewed by a human. If the constraints live in code, get reviewed in pull requests, and ship as part of the deployable artifact — free. If they live in a system prompt that an engineer edits ad hoc — expensive.

Human approval gates for high-stakes actions

The framework wants high-impact decisions reviewed by a person before they take effect. In a well-architected agent system this is a property of the action API, not of the agent. Your agent can attempt anything; only certain actions execute without human sign-off. Building this in is half a day. Bolting it on is a sprint.

Real engineering cost

These cost actual hours and you should plan for them.

Continuous evaluation against production behaviour

The MGF asks for ongoing monitoring of model behaviour against expected outcomes, with a process for responding to drift. Building a real eval harness with production traffic — not a benchmark suite — costs real time. Budget at least a senior engineer-week per agent. The good news: you needed this anyway.

Documentation of training data lineage

If you’re using vendor models (Claude, GPT, Gemini, etc.) you can rely on the vendor’s published documentation, but you still owe your own record of which model versions handled which decisions. Nontrivial to retrofit; modest if planned.

Incident response specific to agentic failure modes

Standard SRE incident response doesn’t cover “the agent decided X for the wrong reason.” MGF expects you to have a separate playbook for agentic failure modes — drift, prompt injection, tool misuse, capability creep. We wrote our first version of this playbook from scratch, and it took two engineers a week to make it actually usable.

Surprising / contentious

A few items in the framework surprised us, in both directions.

Identity and authorization for agents

The MGF treats agents as principals that need their own identity and scoped authorization. We initially read this as overhead. A month into the embedded engagement we use as a reference point, we changed our mind: giving each agent its own identity, its own scoped IAM, and its own audit log made debugging a different category of problem. We now do this on every project, regardless of regulatory pressure.

Capability disclosure to end users

The framework asks that end users be told when they’re interacting with an agent, and roughly what it can do. This is going to be a friction point for some product teams who want to hide the agent under a polished UI. Our position: disclose. Trust compounds. Hidden agents are a brand risk.

Vendor lock-in commentary

The framework gestures at the risk of locking critical workflows into a single foundation-model vendor. Our reading: this is going to push regulated buyers toward systems where the model is swappable. If your stack hardcodes one vendor’s tool-use API, plan accordingly.

The architecture pattern that makes it cheap

There is a single architectural choice that makes most of the MGF nearly free, and we’ve now adopted it across the studio.

Treat agent actions as messages on an audited bus, not as direct function calls.

Every action an agent wants to take is published to a queue. Each action carries the agent’s identity, the user request that triggered it, the input data, and a hash of the agent’s reasoning. A separate worker actually executes the action — and applies any human-approval gate, rate limit, or safety envelope at the worker level.

This single change gets you:

• Audit trail (free, by construction)
• Bounded autonomy (envelopes live at the worker)
• Human approval gates (a worker policy)
• Identity for agents (carried on every message)
• Replayability for incident response (re-run the message)

The cost is one architectural decision and a small amount of plumbing. The benefit is most of MGF compliance, plus a debuggable system.

What we tell new clients

If you are starting an agentic build in Singapore in 2026:

1. Read the MGF. Don’t outsource the read.
2. Decide your action-bus architecture before you write your first agent.
3. Build the eval harness before the second agent.
4. Treat envelopes and gates as first-class code.
5. Disclose the agent. Don’t hide it.

If you do those five things on day one, MGF compliance is something your buyers will be pleased to find when they look — not something you have to discover when they ask.

— wGrow studio