I spent three years building MEPS+ before it went live in 2006, and kept returning to it for years afterwards. It is the system that settles payments between Singapore’s banks. The work involved payments infrastructure where availability, authorisation and traceability mattered together.
There was no artificial intelligence anywhere near it. This was payments infrastructure, built the way it was built twenty years ago, and the problems we spent our days on were the problems of that era — keeping it available, making sure every change was verified before it went near production, and never losing the thread of who did what.
I have been thinking about that work a lot lately, because the problems have come back. Different clothes, same shape.
The question nobody asked
Here is the thing I did not appreciate at the time.
In all those years, across all those design reviews, I do not remember anyone ever asking whether the system could do something. Of course it could. That was never the interesting part.
What people asked, over and over, in every meeting, came back to the same three things.
- 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 this felt like process. Necessary, a little tedious, the price of working on something that mattered. It took me a long while to understand that those three requirements were not the overhead around the engineering. They were the engineering.
A payment you cannot explain afterwards is not a payment. It is an incident.
Why this matters for agents
Almost everything being written about AI agents at the moment is about the first question — the one nobody in that building ever bothered to ask. How much can the agent do on its own? How many steps can it chain? How much of the job can it absorb?
Very little of it is about the other three.
Which I find strange, because in my experience the other three are what decide whether the thing ever gets near real work.
In January 2026, Singapore’s IMDA published a governance framework for agentic AI. It has four dimensions, and the second is making humans meaningfully accountable. Under it, the framework recommends “defining significant checkpoints in the agentic workflow that require human approval, such as high-stakes or irreversible actions, and regularly auditing human oversight to check that it remains effective over time.”
I read that line and felt something close to recognition. That was our requirement, written in 2026, for a different kind of machine.
Then I found the part that stopped me. When the framework sets out how much autonomy to give an agent, it describes a level where the agent runs on its own and calls a human only at critical steps — and the example it chooses for a critical step is “making a payment above a predefined amount.”
An authorisation limit. The most ordinary control in the building I used to work in, arriving twenty-two years later as the canonical illustration of when a machine should stop and ask.
The framework has been revised twice since — it was at version 1.5 by June — and the revisions are worth more than the launch was. What got added is the part that only shows up once people have tried it.
The approval sequence
The sequence I build to now has seven steps.
signal received → records collected → evidence prepared → agent proposal → a person approves → permitted action → audit record
Most of it is obvious. Three parts are not, and they are the three that usually get skipped.
Preparing the evidence is its own step. Collecting the records is not enough. Someone has to assemble them into something a human can actually read and judge, in the time that human really has. Skip it and you end up with an approval step nobody can meaningfully evaluate — which is worse than having no gate at all, because now you are generating records of approvals with no judgement behind them.
A proposal is not an action. The agent proposes; it does not act and then report. That sounds like a small distinction until the first time an agent does something you would not have approved, and you discover how much difference there is between a system that asked you and a system that told you.
The permission is scoped before the proposal, not after the approval. Otherwise “yes, do this” quietly becomes “yes, you are trusted”, and the blast radius stops being something you chose.
That last one has a neat expression in the framework’s own case material, which describes approval for editing files as valid only for the session in which it was given, with future sessions requiring new approvals, while a shell command can be approved for a project. The permission is shaped to the action rather than to the person. Twenty years ago we would have called that a limit of authority, and it would have been on paper.
What breaks when you take the person out
The obvious next move, once an agent has been reliable for a few months, is to remove the human. Three things go wrong, and all of them go wrong quietly.
The first is that people stop looking. It has a name — automation bias — and IMDA names it directly, calling it the tendency to over-trust an automated system, especially when it has performed reliably in the past. The better the system performs, the less carefully anyone checks. The gate stays on the diagram and stops existing in the building.
What I like about the updated framework is that it stops treating this as a warning and starts treating it as something you measure. Watch how often humans actually override the agent, because a low rate may mean nobody is really reading. Watch how long they take, because a fast one may mean the same thing. Those are the two numbers I would want on a wall, and I had not seen anyone write them down before.
The second is that if you did not capture the evidence at the time, you cannot reproduce the decision. Run the same agent three months later and you will get a different answer, because the records underneath it have moved. What you have then is a log, not a record. Anyone who has sat through an audit knows the difference.
The third is that the permission quietly widens. Approval for an action becomes approval for the agent.
None of this shows up in a demo. All of it shows up in a review.
What I got wrong
I underestimated how much thought the approval step itself needs.
For a long time I treated the gate as a control — a yes or no in the flow. It is not. It is an interface for someone’s judgement, and if the person standing at it cannot see what they need to see, in a form they can assess in the minutes they actually have, they will approve by default. Then you have not built a safeguard. You have built theatre, and you will not find out until it matters.
The clearest example I have of that is one of my own, and it was not a person waving anything through. It was a check.
Every mechanism in the platform I work on now is registered with a test that asserts its live call site rather than its internals, and the build fails if that reference stops existing. The gate ran green for a long time, and I read that as evidence the mechanisms were in place. It was evidence of something much narrower: that the tests still resolved.
One of them was asserting against a call site that had moved. The assertion still found something, the test still passed, and the mechanism underneath it had not actually run in a long time. The gate had been reporting on its own configuration rather than on the system. Nobody approved anything they should not have. The record simply said a control existed, and the control was not there.
What needed changing was not the rule. The rule was correct. The answer was a second proof — evidence collected at deployment that the mechanism had actually fired — so that a row cannot stay green on the strength of a test alone. Two independent things now have to be true, and they fail in different ways, which is the entire point. A single proof is a claim about itself.
Keeping the controls working
What interests me about agentic AI is not the autonomy. It is the guardrails — the unglamorous work that lets a regulated business put agents into production instead of piloting them forever.
A capable model does not, by itself, answer those three questions. Before I would trust an agent with consequential work, I would want to see those answers demonstrated.
None of this is something you install once.
The gate I just described was correct on the day it was written. It went quietly wrong afterwards, without anyone touching it, and it went on reporting that everything was fine the entire time. That is the part I would say to anyone starting this work: the control is not the artefact. The control is whether somebody is still checking that the artefact 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; the quotations here are from version 1.5, published 20 May 2026 and updated 5 June 2026. Launch announcement · Framework (PDF)