MEMO · TO readers evaluating a workshop or a speaker · RE Governance

Insights Governance

Foundations of dependable agentic AI

Why engineering reliability into agentic systems depends on bounded task specifications and trajectory-level observability in production, not on how capable the underlying model is.

Terence Kok

About the author

Terence Kok

Enterprise AI Strategist, Author, Keynote Speaker

Enterprise AI strategist with twenty-five years leading transformation programmes across Asia and the Middle East, specialising in impact assessment, governance and deployment methodology.

Read the full profile ›

The most common failure mode in agentic AI deployment is capability-led design: a system built around what the model can do, with controls retrofitted after the fact. Reliability depends primarily on the engineering controls placed around a model, not on the model's own capability, and a task only belongs to an autonomous agent if its success can be checked programmatically and the agent runs against a hard step and cost budget. Everything else is decision support, not automation.

Ten elements make up a specification-first architecture. A bounded task specification defines machine-checkable success criteria, explicit termination conditions, and a task contract covering input schema, side effects and cost budget before the agent runs. Closed-loop verification gives the system access to a deterministic checker, a compiler, a unit test, a constraint solver, so a plausible-sounding output can be distinguished from a correct one. Least-privilege authority scopes credentials to the task, with staged autonomy from autonomous reads through to human-confirmed irreversible writes, and an absolute boundary at operational technology and safety-instrumented systems that no autonomy tier crosses.

Every external input, including tool results, is treated as untrusted by default, structurally separated from instructions to prevent injection attacks. Trajectory-level observability logs every step, prompt hash, model version, tool call, arguments, result, latency and policy decision, because assurance requires a record, not a demo, and an incident can only be reconstructed from a log that was actually kept. Evaluation happens against known-correct trajectories with step-level scoring and adversarial test cases, not against whether the final answer merely looked right.

The remaining elements handle what happens when something goes wrong: checkpointed state, loop detection, spend ceilings and tested escalation paths that let a system degrade gracefully rather than fail silently, with deterministic conventional code handling routing, validation and sequencing so a model's judgment is reserved for the decisions that actually require it. The frameworks referenced, ISO/IEC 42001, the EU AI Act's Article 12, and comparable national standards, all converge on the same underlying requirement: a system has to be built to produce evidence of its own reliability, not just claim it.

Reference

This piece is adapted for Praxora Lab from the original. Originally published at terencekok.com ›

More in Governance