Fifty-three pages, no robots

IMDA's Model AI Governance Framework for Agentic AI runs to fifty-three pages. In all fifty-three, the word robot does not appear once. Neither does physical, latency, machinery, drone or safety-critical. Page 6 says what the document is about:

"Agentic AI systems are software systems consisting of one or multiple AI agents that may operate individually or collaboratively."

That is a boundary, stated on page 6, and this piece does not treat it as a defect. The framework is good at what it set out to do. It describes an agent in eight components, and those eight are a description of what we build. It asks for human approval at defined boundaries. Then it does what almost nobody does: it names two numbers by which a human approval gate can be caught having become a rubber stamp.

What it never does is imagine a machine. The same agency published seventy-six pages on autonomous mobile robots in commercial buildings in 2021, and that document says artificial intelligence twice, one of the two a glossary entry. The newer document does not cite the older one. One agency, two documents, a hundred and twenty-nine pages, five years apart — and nobody has yet written the one that joins a governed agent to a machine.

This is a reading of published documents by a company that builds the thing the first of them describes. It is not legal advice, and no sentence here claims that anything of ours has been assessed against anything.

Eight components, and a register of should

§1.1.1, pages 6 and 7, lists the core components of an agent and numbers them one to eight: Model, Instructions, Memory, Planning and reasoning, Tools, Protocols, Controls, Logging and monitoring. Item 7 breaks out into three:

"Controls: Controls limit the agent's action-space and autonomy. While there are many types of controls, the ones most relevant to agents are: a. Access controls: These limit what an agent is allowed to see, use or change, including restricting access to sensitive data, tools and systems. b. Guardrails: Guardrails monitor and constrain an agent's behaviour before, during or after it acts. It can help detect unsafe instructions, policy violations, or actions that appear inconsistent with user intent. c. Human approvals: Requirements for a human to review or approve agent actions."

Our published architecture at Brain names something for seven of the eight — everything but Instructions — and was not written from this list. The framework describes those components; our architecture is published; the figure below sets the two side by side. That is the only claim available to us: there is no product on a site, no assessment and no third-party review.

Component 6 is the easy one to lose — it dropped out of our own first two readings of the list — and it is the one that matters here. Protocols names the Model Context Protocol and the Agent2Agent Protocol. MCP's specification, revision 2026-07-28, says on its Tools page: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." The human gate is not only in IMDA's framework. It is in the wire protocol that framework points at.

IMDA v1.5, §1.1.1, pp. 6–7 — the core components of an agent, in the framework's own numbering

Components 1–8

• 1. ModelManipulation policy and local planner on the robot; task planner and verifier on the site server
• 2. InstructionsNothing published under this head
• 3. MemoryThree memories — core, short-term, long-term. Working memory, episodic buffer and a core-memory replica on the robot; the site memory service on the server
• 4. Planning and reasoningLocal planner on the robot. Task planner and verifier on the site server, called at task boundaries or on exception
• 5. ToolsFleet arbitration through Open-RMF on the site server: traffic, lifts, doors and task allocation
• 6. ProtocolsOpen-RMF, the only protocol the Brain page names. No MCP or A2A surface of ours is published
• 7. Controls — access controls, guardrails, human approvalsSafety monitors on the robot, on an independent controller; no policy and no safety function runs off the robot. A named person approves anything that enters core memory
• 8. Logging and monitoringEpisodic capture into a local index on the robot; long-term memory holds the episodic history with provenance on the site server

Right of each row: what the Tidewell Brain page already publishes for that component, and on which tier it runs. Published design target, not a measurement and not a compliance mapping — we have no bench, no rig and no prototype that has run, and nothing of ours has been assessed against this framework or any other.

• A component the Brain page already names something for
• Our side of component 7: the human gate and the independent safety controller
• A component we publish nothing under

The framework never says what kind of instrument it is. Voluntary appears zero times in the fifty-three pages, and so does mandatory, so anyone putting quotation marks around either is quoting nothing. The status has to be built instead, and it builds cleanly. Page 13 says the document "builds on the responsible AI practices for organisations set out in MGF (2020)"; that 2020 framework calls itself "the living and voluntary Model Framework" at §2.2 and warns at §2.12 that "adopting this voluntary Model Framework will not absolve organisations from compliance with current laws and regulations." IMDA's press release for the agentic edition uses only guidance verbs: it "provides guidance", it is "recommending" measures, it "offers a structured overview" of risks and "emerging best practices". The register is 83 instances of should against two of must. It calls itself "a living document" and ends in a call for feedback. The mechanisms that would make it something else are absent: no statutory basis cited, no penalty, no conformity assessment route, no notified body, no certification scheme, no registration requirement. Singapore's other 2026 agentic instrument, CSA's Securing Agentic AI addendum, says it outright — "not mandatory, prescriptive nor exhaustive", and "these measures and controls are voluntary".

Auditing the auditor

The most useful page for a buyer is 29, because it is specific. §2.2.2 asks organisations to "define significant checkpoints or action boundaries that require human approval, especially before sensitive actions are executed", and names four: high-stakes actions and decisions, "e.g. editing of sensitive data, final decisions in high-risk domains (such as healthcare or legal), actions that may trigger liability"; irreversible actions, "e.g. permanently deleting data, sending communications, making payments"; outlier or atypical behaviour, "e.g. when agent accesses a system or database outside of its work scope, when agent selects a delivery route that is twice as long as the median distance"; and user-defined boundaries, where users carry different risk appetites.

The delivery-route example is the only fleet-shaped sentence in the document. It gates a route selection — a decision about a delivery. It does not gate a vehicle.

Three more sentences on pages 29 and 30 are ones a compliance officer can lift into a tender clause tomorrow. Approval requests should be kept "short and clear, instead of providing long logs or raw data that may be challenging to decipher", with the associated risk or a confidence score attached. The form of input should match the action: approve or reject for straightforward cases, editing the agent's plan for complex ones, a written justification for high-risk ones. And the last bullet of the automated-monitoring list:

"Denying action by default when approval infrastructures fail (e.g. when human supervisors are unreachable or agents attempt new actions that do not have any established approval policies in place)."

For a software agent, unreachable supervisors are a paging failure and denying by default costs a delay. For a machine carrying a load through a hospital basement, the same rule is a stopped robot in a corridor, and whether that is the safe outcome depends on the corridor. One sentence, two physical situations, and the framework cannot tell them apart, because it has no vocabulary for corridors.

Then page 30 asks for measurable indicators of whether the oversight is real:

"Human override rate i.e. the frequency at which humans reject or modify agent actions. A low rate may signal rubber-stamping behaviours."

"Human response times during review of agent actions. A shorter time may signal automation bias or review fatigue."

Alongside them, "using data analytics to identify 'outlier' humans, whose decision patterns deviate significantly from the norm." The word rubber occurs once in fifty-three pages, on that page. IMDA's "What's new in this version" table says both indicators were added in v1.5 — IMDA's statement about its own document rather than a finding of ours, since only v1.5 is served at the canonical URL. IMDA is candid about the cost: §1.2.3 says that requiring human approvers to continuously oversee agents "can also lead to automation bias and alert fatigue."

A framework that asks for a human gate and then asks whether the gate is real is a serious framework. That is the part to ask every vendor about, ours included.

The counts, and how they were run

We counted every zero above on 11 September 2026, from the v1.5 PDF as served that day — a file generated 17 July 2026, SHA-256 2636e19ff1c86e862394d2fc900592e97b83c04cc35e3c8443108114b7f1dfba — with pdftotext from poppler 26.01.0 in default mode, cross-checked in -layout mode with identical results, matching case-insensitively as substrings after folding Unicode hyphen variants to ASCII and rejoining words split across line breaks. The cover reads "Version 1.5 | Published 20 May 2026 (Updated 5 June 2026)" and the version incorporates feedback from "60+ companies since v1.0"; the file served today is a July re-export of it, which is why the hash matters more than the date. Substring is the stricter test of a negative: the pattern for robot would have caught robots, robotic, robotics and roboticist. It caught nothing.

robot 0. physical 0. latency 0. machinery 0. drone 0. safety-critical 0. cyber-physical, actuator, sensor and embodied, all 0. warehouse is 0 in the text layer, and the word does appear once inside a raster figure on page 41, as the label "Data Warehouse" on an architecture diagram — a data warehouse, not a building.

hospital is the instructive one. Substring count 2, whole-word count 0, because both hits sit inside the word hospitality, in a case study about a Singapore property developer's portfolio spanning "residential, commercial, hospitality, and integrated developments". healthcare occurs exactly once in the document, on page 29, as an example of a high-risk domain in the approval list.

We extracted and read all seven substantial raster figures; the load-bearing terms appear in none of them. But the case-study diagram on page 20, for a private bank's source-of-wealth workflow, draws each of its six software agents as a cartoon robot icon, with human silhouettes for the two human steps. The framework depicts agents as robots and describes robots nowhere.

IMDA, Model AI Governance Framework for Agentic AI v1.5 — 53 pages

Counted 0

• robot0
• physical0
• latency0
• machinery0
• drone0
• safety-critical0
• warehouse0 in the text layer — one occurrence inside a raster figure on p. 41, as the label “Data Warehouse” on an architecture diagram

Counted, and present

• hospital2 as a substring, 0 as a whole word — both hits sit inside the word “hospitality”
• healthcare1 — p. 29, an example of a high-risk domain
• machine3 — machine-readable, machine speed, a victim's machine
• device2 — “controlling devices”, “personal devices”

The register

• should83
• must2

Counted 11 Sep 2026, pdftotext / poppler 26.01.0, substring, case-insensitive.

• Counted zero in the text layer — a measured negative, drawn as zero rather than left out
• Counted, and present in the text

The closest the framework comes to a physical actuator is three words, in component 5: agents take actions "such as writing to files and databases, controlling devices, or performing transactions."

Page 11: "Because agents take actions in the real world, when they malfunction, it can lead to harmful real-world impact." The harms that follow are appointments fixed on the wrong date, flawed code, biased hiring and procurement, data breaches, a deleted production codebase. On page 38, the "real-world situations" an agent must navigate are to be mirrored in testing with "tool integrations, external APIs, and sandboxes". The document's real world is the world of records.

The mirror

The IMDA Guidelines for the Use of Autonomous Mobile Robots for Delivery within Commercial Buildings, version 3.0, January 2021, run to seventy-six pages. An Autonomous Delivery Workgroup chaired by IMDA with JTC, BCA, HDB and others produced them, and they are about RMF, the Robotics Middleware Framework, lift and door integration, interoperability and safety integrity levels [single source — a hosted copy, whose own foreword states the authorship and the working group]. Counted by the same method: artificial intelligence 2, one the abbreviations-list entry "AI artificial intelligence" on page 15 and the other "artificial intelligence libraries" in a cloud back end. machine learning 1. healthcare 0.

One agency. Two documents. A hundred and twenty-nine pages. The 2026 framework does not cite the 2021 guideline, and the citation is not hiding elsewhere. Annex A of the agentic framework lists fifty-one further resources and not one is a robotics source, and the acknowledgements on page 53 name eight Singapore government agencies — CCS, CSA, GovTech, HTX, IPOS, MOE, MDDI, MAS — with no health, transport or workplace-safety regulator among them.

Singapore is not short of robot instruments, and a compliance officer will say so before the second slide of any pitch that pretends otherwise. TR 108:2022, Safe deployment of robot systems in the healthcare sector, is sixty-two pages from the Manufacturing Standards Committee. We have not read it — the text is behind the Singapore Standards eShop paywall — so we say nothing about what it requires; the standards body’s own catalogue record lists the 2022 edition as current, and says it covers system-level recommendations, a safety evaluation framework and risk assessment for robot systems in healthcare facilities. SS 713:2025 covers robot-to-infrastructure communications. The machinery half of this gap is two pieces we have already published: the scope statements that leave a legged robot in a hospital outside all of them, and the conformity route that exists in January 2027 with no harmonised standards list behind it. The agent is governed as software, the machine as machinery, and the document joining them does not exist.

Nobody's fault, and it still bites

None of this is an error. Page 6 defines the object as software systems and the document does what it says it does. So the claim narrows, to this framework and to Singapore's two 2026 agentic documents: fifty-three pages here, one hundred and six in the CSA addendum, a hundred and fifty-nine in total, with robot at zero in both [inference — arithmetic on two counted documents].

It narrows for a second reason: a general AI safety framework elsewhere does name machines that move. China's 《人工智能安全治理框架》2.0版 / AI Safety Governance Framework 2.0 (TC260 and CNCERT, 15 September 2025, ninety-two pages bilingual) says at §4.2.3(d) that "for AI application scenarios requiring strong perception of the real world, such as intelligent assisted driving and drones, perception systems should undergo testing in extreme environments, including large-scale occlusion and strong electromagnetic interference, before being put into use", and at §4.2.3(c) that "circuit breakers and one-click control" should be established where operation is highly autonomous. Read that document before repeating what is said about it: robot in English occurs zero times, and 机器人 occurs once, as 社交机器人 — social bots. Two classes of machine that move through the world, named and given a pre-deployment perception test. IMDA's framework names none. One jurisdiction was enough to make the narrow claim the honest one; the UK, NIST, METI, Korea and the EU AI Office were not checked, and nothing here should be read as though they were.

The reason the gap bites comes from the human-factors literature rather than from us. Parasuraman and Manzey, Human Factors 52(3), June 2010, pages 381 to 410: automation complacency "is found in both naive and expert participants and cannot be overcome with simple practice", and automation bias "cannot be prevented by training or instructions, and can affect decision making in individuals as well as in teams." It is a cost of the systems you would most want to build — "systems characterized by high reliability and high levels of automation, particularly in high task load situations." The gate degrades as the machine under it improves. The one intervention that moved behaviour was accountability: in Skitka, Mosier and Burdick's study of 181 non-pilots in a flight-task simulation, as Parasuraman and Manzey report it, "participants who felt responsible for overall performance or accuracy also showed more attentive automation verification behavior than did participants in all the other groups."

The European legislature has put the same failure mode into binding law: Article 14(4)(b) of Regulation (EU) 2024/1689 requires that overseers be enabled "to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)", and Article 26(2) makes it the deployer's duty to "assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support."

So a human gate that nobody measures is the failure mode the framework names on its own page 11. That is why the two numbers on page 30 are the more important half of §2.2.2, and the checkpoints the less important one.

What nobody has published is what such a gate costs a fleet. We searched on 11 September 2026 for approvals per hour, operator-to-robot ratio under an approval regime, and gate-induced delay, in a second pass, two months of literature after a first that reached the same place. Nothing. What comes back is teleoperation data-collection throughput, a different quantity and not a proxy [inference — a bounded negative, stated as one]. The nearest robotics result, HMCF (arXiv 2505.00820), reports a 4.76% improvement in task success over prior planning methods; that is a simulation figure, and the paper's real-world tests are described qualitatively and carry no number. Most of what has been written about the framework was written without opening it: one widely syndicated write-up calls it "the first comprehensive regulatory framework built specifically for autonomous agents, requiring each agent to carry a verifiable digital identity" [secondary], and it is neither regulatory nor carrying any such requirement in fifty-three pages.

The two numbers we will publish

We have measured nothing on a machine. There is no bench, no rig and no prototype that has run, so there is no override rate of ours to report and no review response time. Any number we gave you today about our own gate would be invented.

We will publish both for Crew, under IMDA's definitions rather than our own, so the definition is not the part we get to choose afterwards: human override rate, "the frequency at which humans reject or modify agent actions", and human response times during review — against IMDA's own reading that a low rate "may signal rubber-stamping behaviours" and a shorter time "may signal automation bias or review fatigue." Those two numbers tell a hospital whether the approval gate in its building is a control or a formality, and they are the two we would least like to publish if they came out badly.

IMDA v1.5, §2.2.2, p. 30 — human override rate against human response time

Low override rate

• …with a short review timeBoth readings fire. “A low rate may signal rubber-stamping behaviours.” “A shorter time may signal automation bias or review fatigue.”
• …with a long review timeOne reading fires. “A low rate may signal rubber-stamping behaviours.”

High override rate

• …with a short review timeOne reading fires. “A shorter time may signal automation bias or review fatigue.”
• …with a long review timeNeither reading fires, and IMDA supplies no reading for this quadrant. The framework names failure signals, not a threshold that anyone passes.

Drawn from IMDA's definitions — no data, nothing measured. No point is plotted here and none could be: we have no bench, no rig and no prototype that has run, so there is no override rate of ours and no review response time of ours to place on it.

• Both of IMDA’s failure readings fire
• One of them fires
• Neither fires, and the document says nothing about this quadrant

That is a promise and not a result, and it is worth what a promise is worth until the numbers appear. Write it down anyway. A buyer who has read this far has four questions for any vendor putting an agent in their building: which checkpoints require approval, what form the approval takes, what happens when the approver is unreachable, and what the override rate and the review response times have been. The first three have answers in a published Singapore document today. The fourth is the one to hold us to.