A successful AI agent demo tells you what happened once. A repeatable test tells you whether your team can trust the work next Tuesday. On October 14, Singapore’s Infocomm Media Development Authority introduced a starter kit for testing agentic systems. It asks organizations to examine the answer an agent produces and the path it took: the tools it used, the information it accessed, the actions it took, and the boundaries it observed. The business opportunity is to make that examination a normal part of the work, not a ceremony held before launch.
In brief: Pick one real task. Define what a correct result and an unacceptable action look like. Run it in a safe setting, keep the action record, and repeat the same test after every meaningful change. A team that learns this routine can give agents more work with fewer surprises.
The demo is not the test
Imagine a customer-service agent asked to resolve a billing dispute. In the demo, it finds the right account, drafts a considerate reply, and closes the case. Everyone sees the final message. The room is pleased.
What did it do along the way? Did it look at another customer’s record? Did it propose a credit above the amount a supervisor authorized? Did it mark the case closed before anyone approved the refund? A fluent reply will not answer those questions. Nor will a screenshot of the completed ticket.
The Straits Times’ account of the October 14 launch describes a kit that checks the tools an agent uses, the data it accesses, the decisions it makes, and whether safeguards and permissions hold. That is a useful change of unit. You are no longer grading an answer. You are inspecting a piece of work.
Singapore’s kit was developed after consultation with government agencies and more than 20 industry deployers and testers, including Amazon, Google, Microsoft, and Singtel, according to the Straits Times. It is a practical reference, not a certification that any particular agent is safe. It gives teams a way to start asking better questions.
Keep the first test small enough to repeat
Many businesses hear “AI testing” and picture a separate compliance program. They put it on a future roadmap. Meanwhile, someone connects an agent to a live inbox because the demo looked good.
The first useful test can fit on a page. Give the agent one bounded task, such as classifying incoming support requests and drafting a response without sending it. Record a few examples it should handle correctly, plus an edge case: a request containing another customer’s account number, a demand for a refund it cannot authorize, or an instruction inside the message telling the agent to ignore its rules. Then write down who reviews the draft and what system actions are off limits.
Run those examples with test records rather than real customer accounts. Save the output and the sequence of actions. Did it read only the assigned ticket? Did it identify the refund request as needing a person? Could a supervisor reconstruct its reasoning from the record, or would they have to guess? If the test fails, that is useful information while the work is still contained.
A supervisor can judge the service. An operator can show the permissions and logs. If the vendor cannot show the path from request to action, record that too.
The advantage comes from the second run
An agent that passes today can behave differently after its instructions change, a new tool is connected, or a familiar document gets updated. Singapore’s kit calls for monitoring and retesting, not a single launch-day inspection. That distinction matters because businesses often treat testing as the last step of a pilot. It should become a reusable habit.
Keep a short set of test cases alongside the workflow. When the team changes a permission or adds a new task, run them again. Record what changed, which cases passed, which failed, and who decided the agent was ready to return to use. Keep the failed cases for next time.
This is where the gap between organizations starts to grow. One team buys another agent and repeats the introduction. Another team keeps a record of what its agents can safely do, how people intervene, and which failures have already been caught. The second team has something the first cannot purchase in a product upgrade: operational memory.
This does not mean every small company needs a dedicated AI assurance department. It means someone owns the test, the evidence, and the decision to expand the scope. The same person who approves a workflow change should be able to point to the last test run. If nobody can, the agent is still an experiment no matter how polished the interface looks.
Make the evidence usable by the next person
The next person might be a manager who was not in the demo, a new hire taking over the workflow, or an auditor investigating a customer complaint. A useful record should let that person answer three plain questions: what was the agent asked to do, what did it actually do, and who accepted the result?
Singapore’s starter kit does not solve those questions for your business. Your team has to choose its own acceptable outcomes and boundaries. That is the point. A generic pass mark cannot tell you whether a proposed $50 credit needs approval in your operation or whether closing a ticket before the customer replies is allowed.
Start with one task this week. Keep the test cases and the action record where the team can find them. Run them again when something changes. If the team cannot show what happened in the last run, it has no basis for expanding the agent’s permissions.