I build systems where an unapproved action is an incident.
My work spans AI architecture and enterprise systems. I write about what agents can do, where they should stop, and how to check their work.
My work has taken me from interbank settlement in Singapore to payment systems for the Central Bank of Bahrain and enterprise data platforms in the United States. Now I’m back in Singapore, building agentic AI.
- Agent proposesA bounded set of actions
- Evidence gatheredSource lines stay attached
- InterlockHeld until it is signedA named person signs
- Permitted actionExplicitly grantedNot grantable
- Trace retainedAnswerable afterwards
What I’m building now
AI systems that know when to stop.
Right now, I’m building agentic systems for hiring at SMAARiX in Singapore.
Most of my attention goes to the line between what an agent may propose, what it’s authorised to execute, and what still needs a person to say yes.
The copilots only see the candidate records they’ve been cleared for, and every action one of them can take is either granted explicitly or isn’t grantable at all. There’s no middle category that quietly widens with use.
Drawing that line is most of the job, and it’s where I spend my time.
One question. Different systems.
Payments, enterprise platforms, data, machine learning, now agentic AI. The systems change, but I keep coming back to three things a decision has to make clear.
- A named approver
- Who authorised the action, and what they agreed to.
- The evidence behind it
- What the reviewer had in front of them when they decided.
- A record you can retrieve
- Enough to explain the decision later, to someone who wasn’t there.
The technology changed. The responsibility didn’t.
Systems I’ve helped build
MEPS+
MEPS+ is the Monetary Authority of Singapore’s system for settling payments between the country’s banks, and I spent three years building it before it went live in 2006. When it was later upgraded to a new database version, I wrote the check that proved the migration: every record compared character by character, before and after, so it was signed off on evidence rather than on nobody having complained.
Central Bank of Bahrain
Payment systems for Bahrain’s central bank. A different regulator, and the same rule underneath: nothing settles unless there is a record of who authorised it, and that record has to still make sense years later, to someone who was never in the room.
State Farm
Three delivery teams, about thirty-six people, inside a programme of more than ten teams. I had line authority over none of them. What actually moved between those teams wasn’t instruction, it was method: test cases written before implementation, and test data agreed across verticals before the dependency landed rather than after it.
Agentic AI
Agentic systems for hiring at SMAARiX. Every mechanism is registered with two proofs: a test that asserts the live call site, and evidence that it actually fired once deployed. If a mechanism isn’t in that ledger then as far as the build is concerned it doesn’t exist.
How I lead
01
Architecture without line authority
The teams building to your decisions rarely report to you. Good architecture has to travel through influence, not hierarchy.
I’ve spent most of my career as the external party inside someone else’s organisation. Sometimes I had a team reporting to me; more often I was delivering through people who didn’t. The largest of those ran across more than ten delivery teams, and I worked closely with three of them without line authority over anyone in the programme.
02
Evidence before implementation
Make the decision testable before the implementation makes it expensive to change.
On the enterprise platforms that meant writing test cases before implementation, and agreeing test data across verticals before the dependency landed. In the agentic work it means a mechanism doesn’t count as existing until two independent proofs say so, and the build fails the moment either one of them goes missing.
03
Clarity across boundaries
Architecture, product, engineering, operations and business teams often see different versions of the same problem. The work is making those versions line up.
In practice that means getting the real workflow out of people who will describe a different one, carrying enough of each discipline to judge whether the specialists can actually deliver it, and then answering for all of it to the executives who signed.
How the work changed — and what stayed the same
2003–2006
When settlement had to be provable
Singapore · MEPS+
The constraint was absolute. Not “usually”, and not “for large amounts”. Nothing moved at all unless there was an authorisation trail behind it.
Then
When scale changed what evidence cost
United States · Enterprise data platforms
At that volume you can’t inspect decisions one at a time, and a platform designed to carry more than five million transactions a day settles the question of whether you are going to try. The record has to be produced by the system itself, rather than assembled afterwards by whoever is asked for it.
Then
When the model became part of the decision
Machine learning · Private banking · Computer vision
A score doesn’t tell you why. To review a model-assisted decision properly you need the inputs it saw, the model version, the surrounding context and the action that followed, all of it captured at the time, because the data underneath will have moved by the time anyone thinks to ask.
By then I was running delivery rather than writing the code, as associate director on private banking programmes. Then warehouse operations automated by computer vision, ninety-nine per cent targeted and ninety-eight achieved, put a model inside that sequence.
Now
When the machine can act
Singapore · Agentic AI
In January 2026 Singapore’s IMDA published the first Model AI Governance Framework for Agentic AI. When it reaches for an example of an action that has to stop and ask a person, one of the two it picks is “making a payment above a predefined amount.”
That is an authorisation limit, and it is the control I worked under on MEPS+ twenty years earlier. Given the choice I would rather design the control than inherit it, and that part hasn’t changed.
The question never changed. The challenge did.
Where I’m going next
The next generation of enterprise systems won’t simply recommend actions. They will take them.
The organisation will need to answer for more than whether the agent finished the task:
- The action
- What the agent actually did.
- The permission
- Why that action was within its authority.
- The approval
- Who authorised it.
- The evidence
- What remains to explain and review the outcome.
That is the work I want to be doing: leading AI architecture where agents do things somebody has to answer for. Regulated industries are the obvious place for it. The harder and more interesting one is the companies building the agents in the first place.
That's the kind of AI architecture I want to build.
Thinking in public
Notes on architecture, AI governance and what changes when software starts making decisions.
- Two proofs, or it does not exist
Most teams can watch their agents run. Far fewer can say whether they work. This is the ledger I built so that no mechanism in a live agentic system is allowed to claim it works without evidence that it fired — including the day the gate caught itself.
- You cannot motivate an agent
Managing agents and managing people are different jobs with opposite failure modes. The leadership layer over agentic work is thinner than anyone admits — and thin is not the same as absent. What survives the thinning is the part that was always hardest.
- What running engineering with agents taught me about running it with people
An agent that produces work you have to check is a junior engineer, structurally. What running an engineering function that way taught me about specification, delegated authority, and where the analogy stops.
Principles I design by
01
Approval should name the action
An approval should be specific enough to survive scrutiny later.
The four parts of an approval - Action
- What is intended.
- Resource
- What it affects.
- Scope
- Where its permission ends.
- Evidence
- What the reviewer saw.
If the proposal changes after approval, the approval doesn’t carry over to the new one.
02
Memory does not grant permission
Knowing something is not the same as being allowed to act on it.
The agent’s credential is read-only against the record, and the write path is one it holds no tool for. It can’t widen its own boundary because nothing it can call does that, rather than because it was told not to.
03
Evidence when the decision happens
Don’t reconstruct the record after something goes wrong.
Design the system to produce it while the decision is being made. Anything assembled later is an account of what people remember, and it is worth about that much when somebody finally checks.
04
Automation needs boundaries
The best agent isn’t the one that does everything. It’s the one that knows when it cannot proceed.
A gate that has never refused anything hasn’t been tested yet. And a limit you can step over when it’s inconvenient was never a limit, it was a preference.
I’ve written up each principle with the constraint behind it, how I try to break it, and where it stops working.
Working on a system that needs to know when to stop?
I’d be glad to talk about AI architecture roles, agentic systems and what enterprise transformation actually costs.
Source
The framework quoted in the arc above is IMDA, Model AI Governance Framework for Agentic AI, version 1.5, published 20 May 2026 and updated 5 June 2026; version 1.0 launched 22 January 2026. Launch announcement · Framework (PDF)