Singapore's updated AI framework says the people who deploy an agent own what it does. Most support teams can't yet name that person, or say what gets checked before a reply goes out.
At ATxSummit in May, Singapore updated its Model AI Governance Framework to cover agentic AI, meaning systems that plan and carry out tasks on their own. The accountability line is short: an agent may do the work, but the people who deployed it own the result.
A piece on TechNode Global by Marcus Low of Sonar, a code-quality vendor, applies that rule to software written by AI. Low borrows a phrase from Amazon CTO Werner Vogels, who calls the gap between how fast AI produces work and how fast people can make sense of it "verification debt."
Low's argument is that an AI reviewer can't close that gap alone. It reads context well, but the same input can get a different verdict on a different run. So he puts fixed, rule-based checks first, because they give the same answer every time and leave a record, and layers AI review, tests and a person on top. Sonar says teams using its automated checks are 44 percent less likely to have an outage caused by AI-written code. That is a vendor's figure about its own product, so weigh it that way. The ordering stands up without the number.
The article is about code, but the same debt builds up anywhere an agent produces work faster than people read it. If your support agent drafts more replies in a day than your team could read in a week, most of what it sends has never been looked at by anyone. Each of those replies is a small loan against your name, and it gets called in when a customer screenshots a refund or a delivery date you never meant to offer.
Singapore's line matters even if you have no customers there. It is the position a regulator, a customer's lawyer or your own board will take anyway: "the model said it" is no defence. So two plain questions follow. Who, by name, owns what your agent sends? And what is checked before it goes out, with a record you could hand over?
Low's ordering maps straight onto a support flow. A lot of what a reply must never do is a fixed rule rather than a judgment call. Quote a price that isn't on the price list. Offer a refund above the agent's limit. Promise a delivery date. Repeat a full card or account number back to the customer. None of these needs a second model's opinion. A plain rule catches them every time, and when an auditor asks why a reply was stopped, you can point to the exact line.
Judgment comes next. Does the reply answer what was asked, and is the tone right for an angry customer? That is where an AI reviewer earns its place, as the second layer instead of the only one. A person comes last, and only for what the first two layers flagged, so the queue a supervisor sees stays small enough to read properly.
CX-Builder builds that as one flow on your own servers: the agent drafts, fixed rules check, a reviewer model scores, a human-in-the-loop step holds anything flagged, and each step is logged against the conversation.
In an agentflow, the drafting agent's output passes through a structured output step, so the reply text, any amount and any date come out as separate fields instead of being buried in prose. Condition nodes and a short custom function test those fields against fixed limits and patterns. An LLM step then scores relevance and tone, and the score is written to the record. Anything that breaks a rule or scores low stops at a human input step for a supervisor to approve, edit or reject. Everything else sends.
The order is the point. Cheap, repeatable checks run first and catch the obvious failures. The model reviewer only sees replies that already passed them, and your people only see what both layers doubted.
Write down one name for each live agent: the person who owns what it sends. Then have that person list the five things a reply from that agent must never do. Every item a fixed rule can catch goes into the flow ahead of any AI reviewer this quarter. Whatever is left is what your people review.