When_a_Government_Writes_About_Your_Workflow

Singapore's Infocomm Media Development Authority published what it calls the world's first governance framework specifically for agentic AI in January 2026. Not general AI governance - agents: systems that can plan, use tools, retain memory, and act autonomously across multiple steps. The framework is voluntary, not legislation, but it sets the institutional baseline for what governance at this level looks like.

The framework identifies four governance objects: risk bounding (what agents can do before they act), human accountability (who is responsible when they fail), technical controls (mechanisms that enforce governance independently of review), and end-user responsibility (what operators need to do to deploy safely).

When I read the four pillars, the reaction was not "I need to build this." It was recognition. Not pattern-matching to a checklist, but reading something that described exactly what I had already built, in the language a national authority chose to describe agentic behaviour. That language matters because it tells you the underlying problem is structural, not implementation-specific.

What makes this framework different from prior AI governance efforts: it does not focus on model outputs - bias, accuracy, explainability. It names memory, tools, and planning as the governance objects. That specificity is what makes a real system mapping possible.

Pillar_1_-_Risk_Bounding

The IMDA's first pillar: defining and constraining what agents can do before they act. Scope limitation, action boundaries, pre-authorisation for high-stakes operations.

In my system: CLAUDE.md constraint blocks define what each agent class can and cannot do. The constraints are not aspirational. Agents run under rules that are enforced structurally - they cannot skip them by moving fast or by deciding a particular rule doesn't apply today. The PR Comprehension Gate - a set of questions every PR must answer before merge - operationalises pre-authorisation for high-impact changes. The gate has a core set (what does this change do, what fails silently, what is the blast radius) and extended questions for larger surfaces (why this dependency, what's cached, how are concerns separated, what are the failure modes for external calls). These are not post-hoc reviews. They are scope-bounding mechanisms built into the workflow.

Spec-Before-Code requires a written brief before any change spanning more than two files. The brief externalises scope before implementation begins. It is a record of what was intended at the moment when intent is clearest. It becomes the contract against which merged code is evaluated.

The insight: risk bounding works when it is structural, not disciplinary. The constraints live in the system. Agents cannot skip them by taking a shortcut. I did not build these because I distrusted my agents. I built them because managing eleven specialists across nine repos makes implicit boundaries invisible. Scale makes the invisible visible. Governance is the infrastructure that responds to what scale exposes.

Pillar_2_-_Human_Accountability

The IMDA's second pillar: clear human accountability for agent decisions. An identifiable human responsible for each agent's actions, defined escalation paths, human-in-the-loop for irreversible decisions.

In my system: Sheena is the orchestrator. Every task routes through Sheena. Specialists do not delegate to each other - all escalation goes through Sheena's routing function. Model tiering (Sonnet for code, QA, research, and strategy; Haiku for content, social, design, and operations) makes accountability structural. Each tier has defined latitude. Higher-stakes reasoning runs on the model tier assigned for it. The Owner approval gate on spec-driven briefs is the human-in-the-loop control for irreversible or wide-scope actions. Before a brief that restructures an API surface or touches multiple projects merges into code, Diana's approval is required.

The IMDA requirement sounds like policy. In practice, it requires routing architecture. A rule that says "escalate to humans when needed" fails because "when needed" is not defined operationally. There is no path for escalation. Sheena's routing function - all work goes through Sheena, specialists do not delegate to each other, cross-project decisions require Owner approval - is that path made operational.

The insight: human accountability in a multi-agent system requires architectural routing, not just policy. The rule is the formal statement. The architecture is what makes it structural.

Pillar_3_-_Technical_Controls

The IMDA's third pillar: technical mechanisms that enforce governance independently of human review. Logging, sandboxing, least-privilege access, pre-deployment testing.

In my system: Quinn is the mandatory QA gate. No code ships before Quinn reviews it. Every development task runs through Quinn before Sheena sees it, and Sheena's review happens before the Owner decides whether the work is done (Dev → Quinn → Sheena → Owner). Sandboxed worktrees for parallel multi-agent work. Least-privilege tool access per agent class - agents are not granted capabilities beyond what their role requires.

The IMDA names cascade risk, memory poisoning, and privilege compromise as the technical threat model. My technical controls address all three. Agent memory has hygiene rules: the MEMORY.md index stays under 30 entries, acted-on memories are archived and removed from the index, any recommendation from memory is verified before I suggest it to avoid staleness. QA gates catch unintended scope expansion before it ships. Least-privilege tool access means the compromise vector does not exist in the first place.

The insight: technical controls that work are constraints on the system, not reviews of its output. A code review is a checkpoint. It answers "does this look right?" Least-privilege access means the attack surface was never there. It answers "could this happen in the first place?" The preventive approach scales better than the detective approach.

Pillar_4_-_End-User_Responsibility

The IMDA's fourth pillar: operators who deploy agentic systems take on responsibility for how those systems behave. Transparency about agent involvement, structured logging of decisions, defined handoff protocols.

In my system: the handoff protocol (/handoff before ending any session - decisions are written to files, not left in conversation context). Memory hygiene rules. Session management (compact at 60% context usage, write decisions to files, not conversation). The MEMORY.md index functions as a structured decision log. The feedback memory type - every correction has a Why: line and a How to apply: line - creates a reasoning log. The system doesn't just record what was decided. It records why, and that reasoning is available to every agent in every future session.

The IMDA specifically requires reasoning logs - why, not just what. The feedback memory structure was designed before the framework existed with exactly that requirement: a rule is not recorded without a Why: line explaining the reasoning. The system knows what happened and why it happened. When an agent enters a session six months later and encounters a rule that seems counterintuitive, the Why: line explains the incident that made the rule necessary.

The insight: end-user responsibility in a solo operator context is self-accountability. The handoff protocol and memory hygiene rules exist because without them, decisions made in one session become dark context in the next. You become your own organisational amnesia. The framework names a governance object I had already solved for operational reasons: the reasoning log is infrastructure for coherence across session boundaries.

What_the_Framework_Gets_Right_-_and_What_It_Can't_See

The IMDA framework is the most precise governance document for agentic AI that exists. It names the right threat model. It treats the right objects. It doesn't conflate agentic governance with general AI ethics. That precision is rare and worth acknowledging directly.

What it cannot see from the policy position: the sequence of discovery. I built the constraints for Risk Bounding after context rot made implicit scope boundaries untenable. I built the routing architecture for Human Accountability after a coordination failure made it clear that "escalate when needed" was not a sufficient operational definition. The controls under Pillar 3 emerged from specific incidents - a file write that landed in the wrong worktree, an unreviewed change that shipped because the gate was unclear. Governance built from operational necessity and governance designed from first principles arrive at the same structures. That convergence is the finding.

It suggests something about the problem structure itself: the failure modes are not implementation-specific. They appear wherever autonomous agents act across multiple steps, contexts, and tools. The practitioner who builds through problems and the policy expert who abstracts from them are looking at the same underlying problem from different distances. When they reach the same conclusions independently, you know the conclusions are not contingent on a particular approach.

There is one genuine gap the framework names but doesn't specify: memory management across sessions. The IMDA treats memory as a governance object - that is correct. But it doesn't address the compounding effect of memory over time, or the hygiene rules required to keep memory useful rather than noise. My memory hygiene practices - index limits, archive protocols, staleness checks before recommending from memory - address a problem the framework identifies but doesn't solve operationally. That gap may be where the next practitioner contribution lands.