I spent three years helping build MEPS+ before it went live in 2006, then returned to it through later releases and technology changes. It settles payments between Singapore’s banks.
The work brought availability, authorisation and traceability together. A system’s ability to perform an action was only part of the question. We also needed to establish who authorised it, what had been checked and what we could show afterwards.
I find myself returning to those questions as I build agentic systems.
What the record had to show
There was no AI in that work. We were dealing with the practical demands of payment infrastructure: keeping the system available, verifying changes before production and preserving the record of who did what.
Three questions kept recurring in reviews.
- Who approved it
- The person behind the authorisation.
- What they reviewed
- The evidence they had when they said yes.
- What we could show later
- A record we could still produce if someone asked in two years.
At the time, I sometimes experienced those questions as process around the engineering. Over time, I came to see them as part of the engineering itself. If someone asked about an important action years later, the answer could not depend on the original team remembering it.
A later MEPS+ database upgrade made that tangible. I built a comparison that checked the migration record by record, character by character. The basis for acceptance was evidence that the records matched, rather than the absence of complaints.
That discipline has stayed with me: decide what must be demonstrated before accepting a consequential change.
Why agentic AI brought it back
An agent can move beyond recommending an action to carrying it out. That makes capability easy to notice and authority easy to overlook.
Singapore’s agentic AI governance framework brought the connection into focus for me. It recommends significant checkpoints for human approval, including high-stakes or irreversible actions. One example of a critical step is a payment above a predefined amount.
I recognised the principle immediately. An authorisation limit was an ordinary part of the payment systems I had worked on. The technology and risks are different, but the distinction between being able to act and being allowed to act remains useful.
I do not take that familiarity to mean payment controls and AI governance are identical. Agents introduce different attack surfaces, uncertainty and forms of delegation. The older experience gives me questions to ask, not a finished answer.
The approval sequence I use
The sequence I build to has seven steps:
signal received → records collected → evidence prepared → agent proposal → a person approves → permitted action → audit record
Three details deserve care.
Preparing evidence is a separate step. Collected records are not necessarily something a person can evaluate. The evidence needs to make the proposed decision understandable within the time the reviewer actually has.
A proposal comes before execution. The agent needs to present what it wants to do while there is still an opportunity to stop or change it. Reporting an action afterwards serves a different purpose.
Permission has a scope before approval. “Yes, do this” should identify an action within a defined boundary. It should not become a standing grant of trust in the agent.
The framework’s case material makes that last distinction concrete: permission to edit files can be limited to a session, while a shell command may be approved at project scope. The duration and reach of permission depend on the action.
How oversight loses its value
A reliable system can encourage people to stop looking closely. The approval step remains, but the judgment behind it becomes thinner.
The framework discusses this as automation bias and suggests watching override rates and review times. I would use those measures to ask whether people are still reviewing meaningfully. A low override rate alone cannot tell me whether proposals are consistently good or whether reviewers have stopped challenging them.
A second problem appears when evidence was not captured at the time. Running an agent again months later, against changed records, cannot reproduce the conditions behind the original action. An activity log may show that something happened without preserving enough to explain the decision.
The third problem is permission that widens through use. Repeated approval for particular actions gradually becomes assumed approval for the agent. I want that change to require a decision of its own.
What I underestimated
I underestimated how much design the approval step itself needs. I treated it as a yes-or-no control in the flow, when it is also an interface for someone’s judgment.
If the reviewer cannot understand the evidence, the system encourages approval by habit. Recording that click does not make the decision well considered.
One of my own checks taught me a related lesson. A gate stayed green while the mechanism underneath it had stopped running. The test still resolved, and I had read that as evidence that the mechanism remained in place.
The assertion found something at a call site that had moved. It was reporting on the check’s configuration rather than demonstrating the live behaviour. Nobody had approved an action they should not have; the record simply claimed a control existed when it was no longer doing its job.
The answer was a second, independent proof collected at deployment: evidence that the mechanism actually fired. The two-proof article explains that discipline in more detail.
A control needs continuing attention
That experience changed how I read a successful check. I want to know exactly what it establishes, and what it leaves unanswered.
The same care belongs at a human approval gate. Who is deciding? Can they understand the evidence? Does their permission cover this action? Will the record still explain the decision after the original context has gone?
A capable model cannot answer those questions simply by completing a task. They need to be designed into the work and checked as the system changes.
The lesson I carry from payment systems into agentic AI is practical: a control can be correct when it is built and become ineffective later. I still need someone checking that it does what its name says it does.
Source
IMDA, Model AI Governance Framework for Agentic AI. Version 1.0 was launched on 22 January 2026; this discussion draws on version 1.5, published 20 May 2026 and updated 5 June 2026. Launch announcement · Framework (PDF)