Agentic AI Engineering Guide: IMDA

This is an engineering playbook. Not a regulatory overview, not a strategy document — a practitioner-level guide to building agentic AI systems that satisfy the controls in Singapore's IMDA Model AI Governance Framework for Agentic AI v1.5 as a structural property of the system, not a bolt-on afterward.

If you have read our companion blog post, this guide is the next layer down: the architecture patterns, the identity model, the tool-sandboxing recipes, the evaluation harness, the observability stack, the runtime guardrails, the change-management triggers, and the vendor-diligence questionnaire. It is intended for staff engineers, ML platform leads, security architects, and AI product owners who are designing or refactoring agentic systems in 2026.

This guide assumes you have read the framework PDF — or at minimum that you have skimmed the framework hub page and downloaded the PDF for reference. We will reference dimensions and sub-sections by number.

Section 1 — Reference architecture

Most agentic AI systems we build for clients converge on a small set of layered components. The framework's structure maps cleanly onto this stack:

┌─────────────────────────────────────────────────────────┐
│ Layer 6 — User Interface (transparency, factsheets,     │
│           interaction declaration, escalation paths)    │
├─────────────────────────────────────────────────────────┤
│ Layer 5 — Orchestrator / Agent Runtime                  │
│           (planning, reasoning, tool dispatch,          │
│            multi-agent coordination)                    │
├─────────────────────────────────────────────────────────┤
│ Layer 4 — Guardrails / Policy Engine                    │
│           (rule-based pre-filters and post-filters,     │
│            model-based safety judges, approval routing) │
├─────────────────────────────────────────────────────────┤
│ Layer 3 — Tool Gateway / MCP Governance Layer           │
│           (least-privilege tool access, sensitive-data  │
│            filtering, sandboxing, whitelisting)         │
├─────────────────────────────────────────────────────────┤
│ Layer 2 — Identity & Authorisation                      │
│           (agent identity, scoped tokens, delegation    │
│            chains, audit trail of "who acted")          │
├─────────────────────────────────────────────────────────┤
│ Layer 1 — Observability                                 │
│           (structured logging, OpenTelemetry traces,    │
│            immutable audit log, evaluator stream)       │
└─────────────────────────────────────────────────────────┘

The layering matters because IMDA Dimension 3 wants you to put structural controls at the lowest possible layer. A control at Layer 2 is harder to circumvent than the same control written in a Layer 5 system prompt. A filter at Layer 3 is more reliable than asking the Layer 5 model to "please not access this resource." When in doubt, push the control down a layer.

The five questions the architecture must answer

For any agentic system in design review, we use a five-question test that maps to the four IMDA dimensions:

What is the action-space and autonomy of this agent? (Dimension 1)
Who is accountable, and how is "human in the loop" implemented in a way that resists rubber-stamping? (Dimension 2)
What controls are at the tool/protocol layer, what evaluation runs before deployment, and what monitoring runs after? (Dimension 3)
What does the user-facing transparency look like, and what training do users need? (Dimension 4)
What is the change-management trigger that re-opens this review? (Dimension 3, change management)

If the design doc cannot answer all five before code is merged, the design doc is not done.

Section 2 — Identity and authorisation

This is the single biggest gap in most existing agentic deployments we audit. Teams build agents on top of human IAM, give them a service account, and call it done. That works until it does not.

Minimum viable agent identity

The framework prescribes the following baseline. We implement it as a small AgentIdentity service:

interface AgentIdentity {
  // Unique, cryptographically verifiable identifier per agent instance.
  // Use a signed JWT or a cryptographic key pair; rotate on a schedule.
  agentId: string;

  // Human-readable name and version tag for catalogue and audit.
  name: string;
  version: string;

  // Accountability chain. Always points up to a supervising human, agent,
  // or organisational unit — never null in production.
  accountableTo:
    | { kind: 'human'; userId: string }
    | { kind: 'agent'; supervisorAgentId: string }
    | { kind: 'department'; departmentId: string };

  // The capacity in which this agent is acting on this request.
  // 'independent' = acting under its own delegated authority.
  // 'on-behalf-of' = acting for a specific human user; permissions
  //                  must be bounded by that user's permissions.
  capacity:
    | { kind: 'independent' }
    | { kind: 'on-behalf-of'; userId: string };

  // Scoped, time-bound authorisation tokens.
  // Refresh per session; never long-lived in production.
  authorisations: AuthorisationGrant[];

  // Metadata for central catalogue management.
  createdAt: ISO8601;
  expiresAt: ISO8601;
  status: 'active' | 'paused' | 'retired';
}

The properties the framework wants:

Unique. Every deployed agent has its own ID. Sharing service accounts across agents prevents per-agent accountability.
Accounted for. The accountableTo field is never null. If an agent has no clear human or organisational owner, do not deploy it.
Differentiated by capacity. When the agent acts on behalf of a user, the capacity field captures that, and downstream authorisation checks enforce that the agent cannot do things the user cannot.
Catalogued centrally. A single source of truth for all agent identities — a database table, an IAM extension, or a dedicated agent registry service. The framework calls this out specifically to prevent "agent sprawl."

Authorisation: scoped, time-bound, non-transferable

Each AuthorisationGrant should encode:

Scope. The specific tools, resources, or operations the agent is permitted to use. Never grant a permission the agent does not need.
Bounds. Time-bound (expiry) or session-bound (revoked at session end).
Non-transferable. If the agent spawns a sub-agent, the sub-agent receives its own grant — not the parent's.
Least privilege by default. Start with no permissions and add as needed, not the other way around.
Bounded by the authorising human's own permissions. When an agent acts on Alice's behalf, the effective permission set is the intersection of (what the agent is allowed to do) and (what Alice is allowed to do).

In production we implement this with short-lived signed credentials issued by a central authorisation service, refreshed per session. For agents that call MCP servers, the OAuth 2.1 over MCP draft gives you a reasonable interim pattern.

Delegation chains

When agents spawn sub-agents, the delegation chain must be recorded for audit. A typical pattern:

interface DelegationRecord {
  delegationId: string;
  parentAgentId: string;
  childAgentId: string;
  delegatedAt: ISO8601;
  scopeDelegated: Permission[];   // must be subset of parent's scope
  reason: string;                 // why the delegation occurred
  expiresAt: ISO8601;
}

This is what makes a multi-agent system auditable. Without it, when a bad action happens deep in a swarm, you cannot trace who delegated to whom.

Section 3 — Tool gateway and MCP governance

IMDA Dimension 3 is unambiguous about preferring structural controls over prompt-level ones. The tool gateway is where this principle lives.

Tool registration

Every tool exposed to any agent is registered, with metadata:

interface RegisteredTool {
  toolId: string;
  name: string;
  description: string;

  // Risk classification — drives approval requirements.
  riskTier: 'low' | 'medium' | 'high' | 'critical';

  // What the tool does, structured.
  sideEffects: 'none' | 'read' | 'write' | 'external-call';
  affectsExternalSystems: boolean;
  reversible: boolean;
  costPerInvocation: number | null;
  sensitiveDataExposure: 'none' | 'pii' | 'phi' | 'financial' | 'secrets';

  // Allowed callers — agent IDs or capability tags.
  allowedAgents: string[] | { capability: string };

  // Input/output schemas, typed. Free-text params are a smell.
  inputSchema: JSONSchema;
  outputSchema: JSONSchema;

  // Sandbox / isolation level required.
  isolation: 'none' | 'process' | 'container' | 'vm';
}

Registration is gating. If a tool is not in the registry, agents cannot call it. This pattern prevents the most common failure mode we see: developers wiring up new tools to agents during prototyping and forgetting to revoke them in production.

MCP as a governance layer

The framework explicitly recognises MCP as a governance layer, and we agree. Typical controls at the MCP gateway:

Whitelist trusted MCP servers. Only allow agents to connect to servers on a maintained whitelist. New servers go through a security review.
Filter sensitive data on the way out. If the agent queries a database via MCP, fields like SSN, payment details, or credentials are stripped or redacted before the response reaches the agent's context window.
Log every call. Every MCP request and response is logged with the calling agent's identity, the tool, the parameters, and the result hash.
Sandbox any code execution. MCP servers that execute code (e.g., a Python REPL tool) run in isolated environments with no access to production resources.
Rate-limit per agent and per tool. Cap how many times an agent can invoke a tool within a window; cap aggregate cost.

For organisations bridging from raw MCP to a governed MCP layer, GovTech's reference architecture (whitelisted MCP gateway with central logging, OS-native sandboxes for low-risk operations, full container sandboxes for high-risk operations) is the cleanest pattern we have seen at scale.

Typed function calls between agents

In multi-agent systems, agent-to-agent communication should use typed function calls with structured payloads, not free text. Free text from one agent into another's context is an attack surface — prompt injection that passes through agent A reaches agent B's context.

// WRONG: free text between agents
const result = await childAgent.run(`Please find the customer's last order
                                    and tell me the total amount.`);

// CORRECT: typed function call
const result = await childAgent.invoke('lookup_order', {
  customerId: 'cust_123',
  query: { kind: 'last_order' },
});

The typed-call pattern also makes agent-to-agent traffic legible to monitoring tools and amenable to schema validation.

Section 4 — Guardrails and policy engine

The guardrails layer sits between the orchestrator and the rest of the stack. Its job is to enforce policies that are not naturally expressible as tool-layer controls.

Pre-filter, post-filter, model-judge pattern

Three classes of guardrails, applied in this order:

Pre-filters (deterministic, run before the LLM call).
- Sensitive data redaction (PII, PHI, secrets) in inputs.
- Block-listed tool combinations (e.g., disallow delete_resource followed by notify_external in the same plan).
- Rate-limit checks.
- User-permission checks for the on-behalf-of capacity.
Post-filters (deterministic, run after the LLM call, before tool execution).
- Output schema validation.
- Cost-ceiling checks for the proposed action.
- Reversibility tagging (mark proposed actions as reversible or not, and route accordingly).
Model-based judges (LLM-as-judge, run async or in parallel for high-risk cases).
- Safety classification of the proposed action.
- Policy adherence check against the SOP.
- Anomaly detection on the trajectory.

Cyber Sierra's TracyAI worked example in v1.5 implements the model-judge pattern with two reflection nodes: an LLM judge (does this answer address the question, is it grounded in retrieved evidence, are there unsupported claims) and a metrics-based scorer (similarity scores, RAGAS metrics). The agent's trajectory terminates if it cannot pass both within three iterations. That is a good pattern; copy it.

Approval routing

When an action's risk tier exceeds the agent's authorised autonomy, the guardrails layer routes the action to a human approver:

interface ApprovalRequest {
  requestId: string;
  agentId: string;
  proposedAction: {
    tool: string;
    inputs: unknown;
    summary: string;          // plain-language explanation
    risk: 'low' | 'medium' | 'high' | 'critical';
    reversible: boolean;
    confidence: number;        // 0-1
    metadata: Record<string, unknown>;
  };
  reviewers: string[];        // user IDs eligible to approve
  deadline: ISO8601;
  fallback: 'deny' | 'queue' | 'escalate';
}

The Tencent CodeBuddy pattern — proposed command in raw form, plain-English explanation, plus context on side effects — is the format we recommend. The framework is explicit that approval requests must be digestible, contextual, and clearly indicate risk.

Section 5 — Evaluation harness

Most teams' evaluation stories stop at "we ran the agent on a benchmark." That is necessary but insufficient. The IMDA framework wants four-dimensional testing:

Dimension	What you test	How
Overall task execution	Does the agent complete the task accurately end-to-end?	Curated test set with reference outputs; LLM-as-judge for unstructured outputs; human review for ambiguous cases.
Policy adherence	Does the agent follow SOPs and escalate appropriately?	Synthetic test cases that trigger SOP branches and approval-required paths; assertions on the trajectory, not just the output.
Tool calling	Right tool, right input, right order?	Trace-level assertions against the expected tool-call sequence; differential testing across model versions.
Robustness	Edge cases, errors, prompt injection, adversarial inputs?	Red-team test set; adversarial prompt suite; chaos testing (kill upstream APIs and verify graceful degradation).

Harness architecture

interface EvalRun {
  runId: string;
  agentId: string;
  agentVersion: string;
  modelVersion: string;
  promptVersion: string;
  testSetVersion: string;
  startedAt: ISO8601;
  results: TestResult[];
}

interface TestResult {
  testCaseId: string;
  dimension: 'execution' | 'policy' | 'tools' | 'robustness';
  expected: unknown;
  observed: unknown;
  trajectory: TrajectoryStep[];  // full record of tool calls
  passed: boolean;
  reason: string;
  judgeScore: number | null;
}

Run the harness:

Pre-deployment as a gate. No agent ships without a green run.
On every model update (model upgrade, prompt change, tool change).
On a schedule for production agents (we typically run daily for high-stakes agents and weekly for the rest).
On every change-management trigger (see Section 8).

Multi-agent system testing

Per-agent testing does not surface multi-agent emergent behaviour. Run the harness at the system level as well — full workflows, with all participating agents wired up — and explicitly test:

Miscoordination. Agents working on the same task interpret intent differently and pursue different sub-goals.
Conflict. Agents optimising different objectives (e.g., revenue agent vs refund agent) reach contradictory conclusions.
Collusion. Agents converge on undesirable equilibria — the framework cites pricing agents that learn to keep prices high without explicit instruction.
Cascading errors. One agent's hallucinated output becomes another's input.

Microsoft Foundry's Agent Evaluators and AWS Labs' Agent Evaluation are the named reference solutions in the framework's footnotes. We use a mix of LangSmith for trajectory inspection, Helicone for cost tracking, plus custom Python harnesses for dimension-specific assertions.

Section 6 — Observability stack

The framework wants monitoring across multiple layers, alert thresholds with defined interventions, integration with observability platforms (OpenTelemetry is the named standard), and immutable logs.

Minimum production stack

Layer	What is logged	Where it lives
User-agent interaction	Inputs, outputs, session metadata	Application logs (structured, OpenTelemetry-compatible)
Agent-orchestrator	Plan, reasoning, decision points	Trace spans with structured attributes
Agent-tool	Tool calls, parameters, results, latency	Trace spans + immutable audit log
Model	Prompts (redacted), responses, token counts, model version	Cost-and-performance log
Guardrails	Pre-filter results, post-filter results, judge scores, approval routing	Policy log + alert stream
Identity	Auth grants, delegations, revocations	Audit log

Alert thresholds and interventions

The framework prescribes graded interventions. We implement this with a four-tier alert classification:

Tier	Examples	Intervention
Info	New agent registered, scheduled run completes	Daily digest
Warning	Tool error rate above baseline, latency spike, partial failures	Engineer review within 24h
High	Unauthorised access attempt, repeated failed tool calls in a short window, agent acting outside expected trajectory	Halt agent; on-call review within 15 minutes
Critical	Data exfiltration pattern detected, multiple agents failing simultaneously, MCP whitelist breach	Page on-call; terminate agent; fallback to deterministic workflow

The framework's explicit guidance — deny by default when approval infrastructure is unreachable — is non-negotiable. If your monitoring or guardrails layer is down, agents should pause, not continue without supervision.

Log immutability

Problematic trajectories must not be deletable. The simplest pattern: write to an append-only log store (AWS QLDB, immudb, S3 Object Lock, or even a Postgres table with row-level revocation of UPDATE and DELETE). For high-stakes domains, hardware-attested logs are appropriate — Terminal 3's hardware-ledger pattern in v1.5 is the gold standard but is overkill for most non-financial deployments.

Audit-of-audit: measure whether oversight is working

The framework wants you to track human reviewers, not just agents. Measure:

Human override rate. Per reviewer, per agent. Trending toward zero is a red flag.
Response time. A median that drops over time suggests review fatigue or rubber-stamping.
Outlier reviewers. Reviewers whose decision patterns deviate from the rest of the team.

We typically run this as a weekly report into the agent owner's inbox.

Section 7 — Runtime guardrails: concrete patterns

A few patterns we deploy regularly that address specific IMDA risks:

Pattern: Tool-call quota with auto-pause

For agents with broad tool access, set per-session and per-day quotas. When exceeded, the agent pauses and routes to a human. This catches runaway loops (a known agent failure mode) before they consume budget or cause damage.

Pattern: Outlier-action escalation

The framework explicitly calls this out: when an agent attempts to access a system or database outside its work scope, or its proposed action diverges from its normal trajectory, escalate even if the action would otherwise be allowed.

Implementation: maintain a profile of normal actions per agent. When proposed actions fall in the long tail of the distribution, the post-filter routes to approval regardless of risk tier.

Pattern: Read-vs-write separation

Where possible, separate agents into read-only and write-capable. Read-only agents can be deployed broadly with light controls. Write agents — a smaller, more heavily monitored set — handle just the actions that require writes.

OCBC's Source-of-Wealth agentic system in v1.5 follows this pattern: read-heavy document parsers and benchmarkers, with the actual write of the memo (to an internal data lake, not the production CRM) only allowed after human approval.

Pattern: Sensitive-data takeover

When the user is about to key in sensitive data (passwords, API keys, payment details), the agent hands control back to the user explicitly. The agent never sees the sensitive data. This is a structural defence against the agent inadvertently logging or leaking it.

Pattern: Verifiable Credential of Intent

For financial transactions, encode the agent's authority in a cryptographically signed credential per cycle that specifies exactly what the agent can do (which records, what amounts, which categories). Terminal 3's payroll agent worked example in v1.5 implements this at hardware speed. For most non-hardware deployments, a signed JWT with strict claims is sufficient.

Section 8 — Change management

IMDA Dimension 3 dedicates a sub-section to change management. The framework wants explicit triggers for re-review, with changes categorised by risk.

Triggers

Trigger class	Examples
Technical	Model upgrade, prompt change, tool added/removed/modified, MCP server added
Environmental	Domain shift, traffic pattern change, new user segment
Performance	Anomalous behaviour, degraded metric, drift in evaluator scores
Regulatory	New legislation in a jurisdiction the agent operates in, framework version update

Categorisation

Risk	Examples	Review depth
Minor	Prompt refinement, additional logging, UI label change	Engineer review + eval harness re-run
Material	Model upgrade, new tool, autonomy adjustment	Full eval suite, security review, owner sign-off
Critical	Change to a high-stakes-decision step, agent moving from advisory to decision-making	Full re-risk assessment, AI risk officer sign-off, optional notification to affected users

We implement this as a check in CI: pull requests touching agent code, prompts, tool configuration, or model selection automatically trigger the appropriate review flow based on a label on the change.

Section 9 — End-user transparency artefacts

Dimension 4 is the most under-implemented dimension. Here are the concrete artefacts we build for client deployments:

Agent factsheet

One per agent. Public-facing. Modelled on Workday's Recruiter Agent factsheet pattern:

Name and version.
What this agent can do. Enumerated, plain language.
What this agent cannot do. Enumerated. Often more useful than the "can do" list.
What data this agent accesses. Specific categories.
What data this agent stores. With retention period.
Where its reasoning comes from. Reference documents, knowledge bases.
Failure modes you should know. Common error patterns, where the agent has been observed to struggle.
How to escalate. Specific human contact path, response SLA.

Interaction declaration

In the UI, at the interaction point — not buried in T&Cs:

You are interacting with an AI agent. This agent can search our policies,
draft responses, and route requests, but cannot approve refunds above $500
or change account ownership. To speak to a human, type 'agent' or click
'Connect me to a person.'

User training

For internal users who integrate agents into their work:

30-minute onboarding covering capabilities, common failure modes, and the override path.
Quarterly refreshers as the agent evolves.
A "what went wrong this quarter" digest with anonymised examples.

Tradecraft retention plan

For each role exposed to agentic tools, identify the core skills that must be retained even as the agent absorbs the routine work. Schedule deliberate practice in those skills. The framework cites the Quarterly Journal of Economics' "Generative AI at Work" study — skill atrophy is real and business-continuity-relevant.

Section 10 — Vendor diligence questionnaire

If you are consuming a third-party agentic AI product (Microsoft Copilot Agents, Salesforce Agentforce, ServiceNow AI Agents, OpenAI Operator, Anthropic Computer Use, GitHub Copilot Agent Mode, or any other), you carry deployer obligations. This questionnaire surfaces what you need to know from the vendor:

Identity and access:

Does each agent instance have a unique, verifiable identity? How is it issued?
Can we scope agent permissions to specific tools, datasets, users?
Are agent credentials time-bound or session-bound? What is the rotation cadence?
When the agent acts on behalf of a specific user, are permissions bounded by that user's permissions?

Tools and integrations: 5. Can we whitelist or blacklist specific tools or MCP servers? 6. Can we filter sensitive data fields out of tool responses before they reach the agent context? 7. Where is code executed? Is it sandboxed? At what isolation level? 8. What rate limits apply per agent, per tool, per session?

Oversight and approval: 9. Can we configure approval requirements per tool, per risk tier, per user? 10. What information is included in an approval request? Plain-language summary, confidence, risk indicator? 11. Can we audit human approval patterns (override rate, response time)?

Testing and evaluation: 12. What pre-deployment testing has the vendor conducted? Across what dimensions? 13. Can we run our own evaluations against the agent in a sandbox? 14. What is the vendor's process for updating the model? Are we notified before a model upgrade affects our production?

Monitoring and logging: 15. What logs are captured per session? Are they accessible to us via API? 16. Are logs immutable? For how long are they retained? 17. What alerting is available, and can we integrate with our SIEM/observability stack?

Multi-agent and protocols: 18. Does the product use multi-agent architectures internally? Can we see the orchestration? 19. Which agent-to-agent and tool protocols are used (MCP, A2A, agentic commerce protocols)? 20. How does the vendor test for emergent multi-agent behaviour?

Incident response: 21. What is the vendor's process for serious incident disclosure? 22. What SLAs apply for security incidents? 23. What is the kill-switch capability if we need to terminate the agent immediately?

Compliance: 24. Which frameworks has the vendor mapped to (NIST AI RMF, ISO 42001, SOC 2, EU AI Act, IMDA MGF Agentic)? 25. What is the vendor's commitment to publishing GPAI training-data summaries (Article 53 of the EU AI Act) for upstream models they use? 26. Does the vendor support data residency requirements relevant to your jurisdiction?

If the vendor cannot answer a substantial subset of these, that is your diligence signal.

Section 11 — Sample policy language

For organisations standing up an internal AI Use Policy that addresses agentic systems, the following clauses are drawn from policies we have written for clients. Adapt to your context; not legal advice.

§ Agent registration. Every AI agent deployed within the organisation must be registered with the AI Risk Office before production use. Registration requires: a designated owner, a risk-tier assessment per the IMDA MGF Agentic framework, documented tool and data access, an evaluation report, and a monitoring plan.

§ Forbidden uses. Agents shall not be used for the following without explicit written approval from the AI Risk Officer and the relevant Department Head:

Final decisions affecting compensation, hiring, firing, promotion, or discipline.

Clinical, legal, or financial recommendations that are acted on without qualified human review.

Communications to external parties (customers, regulators, vendors) without human approval.

Modifications to production infrastructure, deployment pipelines, or security configurations.

Any action involving Personal Health Information, Personally Identifiable Information, or regulated financial data, unless the agent and its tools have been specifically certified for that data class.

§ Identity. Every agent shall have a unique identity issued by the central agent registry. Shared service accounts shall not be used for new agents. Existing shared-account agents shall be migrated to per-agent identity within 90 days of this policy's effective date.

§ Tool access. Agent tool permissions shall follow the principle of least privilege. Permissions shall be scoped, time-bound, non-transferable, and bounded by the authorising user's permissions where the agent acts on a user's behalf.

§ Human oversight. Each agent deployment shall define human-approval checkpoints corresponding to its risk tier. Approval requests shall include a plain-language summary, a risk indicator, and a confidence score. The effectiveness of human oversight shall be audited monthly, including human override rate and response time.

§ Monitoring and incident response. All agent activity shall be logged to an immutable audit store and integrated with the organisation's monitoring and SIEM infrastructure. Agents shall pause execution and route to a human reviewer when monitoring or guardrails infrastructure is unavailable.

§ Change management. Changes to agent code, prompts, tools, or model selection shall be categorised as minor, material, or critical per the AI Risk Office change-management policy, and reviewed accordingly. Production model upgrades require a full evaluation re-run and AI Risk Officer sign-off.

§ User transparency. External-facing agents shall declare AI use at the interaction point, publish a factsheet listing capabilities and limitations, and provide a clear human escalation path.

§ Vendor diligence. Third-party agentic AI products shall be reviewed against the AI Risk Office vendor diligence questionnaire prior to procurement, with risks documented and accepted in writing by the relevant Department Head.

Section 12 — Putting it together

A 12-week implementation plan we have used with clients moving from "we have agents in pilot" to "we have agents under governance":

Weeks 1-2: Inventory and triage. List every agentic system. Score each on impact + likelihood factors. Identify which need to be re-bounded, which need to be decommissioned, which are appropriate as-is.

Weeks 3-4: Identity foundation. Stand up the agent registry. Migrate existing agents to per-agent identities. Implement the basic delegation chain.

Weeks 5-6: Tool gateway. Inventory and register all tools. Stand up the MCP governance layer (or equivalent). Implement at minimum: whitelist, structured logging of every call, sensitive-data filtering.

Weeks 7-8: Guardrails and approvals. Implement pre-filter / post-filter / model-judge. Wire approval routing. Implement at least one of the runtime patterns from Section 7 per agent.

Weeks 9-10: Evaluation harness. Stand up the four-dimensional eval suite. Run the baseline. Wire to CI gates and the change-management triggers.

Week 11: Observability. Integrate logs with OpenTelemetry and your existing observability stack. Implement the alert tiers and immutable audit log. Wire the audit-of-audit reports.

Week 12: User transparency. Publish factsheets for external-facing agents. Implement interaction declarations. Stand up the user training pipeline.

Ongoing: Run the eval harness on every change. Run the audit-of-audit weekly. Run a full governance review quarterly.

Where to go from here

If you have already built agents and want to retrofit governance, the order above still applies — start with identity and tool gateway, because they require less rework than re-architecting orchestrator-level controls.

If you are designing a new agentic system, build the layered architecture from Section 1 from day one. Retrofitting is always more expensive.

Cross-references for further reading:

The Singapore framework hub page — full framework summary, applicability checklist, FAQ, control mapping, PDF download.
The EU AI Act hub page — binding-law overlay, with the high-risk obligations that intersect with agentic AI.
The NIST AI RMF hub page — US federal process framework.
The companion blog post — narrative-form walkthrough of the four dimensions.

We help clients build agentic AI systems that satisfy this stack as a structural property. If you want to talk about your architecture, schedule a consultation. We will walk through the layered design, the dimensions that matter most for your domain, and the highest-leverage places to invest.

The framework is the floor, not the ceiling. The goal is not minimum compliance — it is shipping agentic systems your customers, your auditors, and your future self can trust.