AVOO and AI Agents | Architect, Visionary, Oracle, Operator in Machine Workflows

An AI agent becomes consequential the moment it can do more than answer.

It can search. It can remember. It can call tools. It can write files. It can open tickets. It can move money. It can change a calendar. It can deploy code. It can send a message. It can delegate to another agent. It can continue after the user has stopped watching.

At that point, intelligence is no longer the whole problem.

The system must decide what the model may know, what it may infer, what it may propose, what it may execute, what requires approval, what must be verified afterward, what can be remembered, what must be forgotten, and what happens when the result is uncertain.

AVOO and AI Agents is the applied machine-workflow layer of eduKateSG’s Architect, Visionary, Oracle and Operator framework.

It asks one central question:

How do we let an AI system reason, use tools and act without confusing intelligence with authority, fluency with evidence, a tool response with world state, or completion with success?

This article continues the extension phase after the AVOO Casebook. The core framework remains mapped in the AVOO Library | Complete Architect, Visionary, Oracle, Operator Operating Map.

The short answer

AVOO treats an AI agent not as one magical autonomous mind, but as a governed system in which different functions should be separated enough that reasoning, evidence, authority, execution and verification can challenge one another.

The Architect defines the workflow, tool boundaries, memory layers, interfaces, checkpoints and fallbacks.
The Visionary protects user intent, long-horizon purpose and acceptable future states.
The Oracle retrieves evidence, diagnoses state, represents uncertainty and challenges weak assumptions.
The Operator performs bounded actions through tools and returns execution evidence.
Governance decides which actions are permitted, which need human approval and which must never be delegated automatically.
The Receiver Loop checks what actually happened in the external system.
Memory preserves only the state worth carrying forward.
Thresholds decide when to continue, escalate, pause, ask, roll back or stop.

The most important rule is:

Model output is not action authority.

A model can be confident and still lack permission.

A tool can report success and still leave the real-world state wrong.

An agent can complete a plan and still fail the receiver.

Why this matters now

By 2026, agentic systems are no longer only a research abstraction. NIST’s AI Agent Standards Initiative describes agents as systems capable of autonomous action across software and digital environments, and NIST has separately highlighted identity, authorization, auditing and prompt-injection risks as important parts of secure agent deployment.

Microsoft’s current agent tooling exposes approval-required tools, human-in-the-loop workflow pauses, checkpoints and resumable state. Anthropic has highlighted the practical governance challenge created when agents can write code, manage files and operate across applications with less direct human oversight. OWASP’s agent-security guidance likewise treats tool abuse, privilege escalation, data exfiltration and memory poisoning as distinct risks of agent architectures.

Research anchors: NIST — AI Agent Standards Initiative · NIST — AI Agent Identity and Authorization · Anthropic — Trustworthy Agents in Practice · OWASP — AI Agent Security Cheat Sheet.

An agent is a system, not merely a model

A useful mental model is:

USER INTENT
  ↓
POLICY / GOVERNANCE
  ↓
MODEL REASONING
  ↓
EVIDENCE / CONTEXT
  ↓
PLAN
  ↓
TOOL AUTHORITY CHECK
  ↓
ACTION
  ↓
REMOTE STATE
  ↓
VERIFICATION
  ↓
RECEIVER
  ↓
MEMORY / LEARNING

The language model is only one layer.

The agent also includes:

instructions;
identity;
permissions;
tools;
external services;
memory;
workflow state;
approval gates;
evaluation;
logs;
receipts;
recovery logic.

When an agent misbehaves, “the model was wrong” may therefore be an incomplete diagnosis.

The failure may be architectural.

Do not map AVOO too literally

AVOO does not require one model instance called Architect, another called Visionary, another called Oracle and another called Operator.

Sometimes that decomposition is useful.

Sometimes one model performs several cognitive roles while hard system boundaries handle authority and verification outside the model.

The stronger rule is functional:

architecture should be identifiable;
future purpose should be identifiable;
evidence and uncertainty should be identifiable;
execution should be identifiable;
authority should be identifiable;
receiver verification should remain distinguishable from self-report.

Role separation matters more than role theatre.

The machine-workflow AVOO map

AVOO function	Agent-system responsibility
Architect	workflow graph, tool interfaces, memory boundaries, permissions, fallbacks, state transitions
Visionary	user goal, protected purpose, future-state constraints, long-horizon trade-offs
Oracle	retrieval, evidence, provenance, uncertainty, environment reading, contradiction detection
Operator	tool invocation, execution, bounded side effects, recovery action
Governance	authorization, approval, stop rights, audit, escalation
Receiver	external state proving whether the intended effect actually landed

The first separation: reasoning versus authority

An agent may reason that a refund should be issued.

That does not mean it should automatically possess authority to issue the refund.

An agent may reason that a calendar event should be cancelled.

That does not mean the cancellation is reversible, harmless or within the user’s intended scope.

An agent may reason that code should be deployed.

That does not mean it should hold production credentials.

The AVOO governance rule is:

A recommendation may cross the reasoning boundary. Authority must cross through a separate contract.

Microsoft’s current Agent Framework reflects this distinction directly: tools can be marked as approval-required, causing the workflow to pause until approval is supplied.

Research anchor: Microsoft Agent Framework — Tool Approval.

The authority envelope

Every acting agent should have an authority envelope.

The envelope answers:

what systems may be accessed;
what tools may be called;
what data may be read;
what data may be written;
what actions are reversible;
what actions require approval;
what monetary or operational limits apply;
what identities the agent may act for;
what must be logged;
what conditions force escalation.

NIST’s 2026 work on software-agent identity and authorization is important here because agent security cannot rely only on what the model says it intends to do. Identity, authorization, auditing and non-repudiation belong to the surrounding system.

Identity before authority

A system should know which agent is acting, for whom, under what session, under what policy and with which permissions.

Useful identity fields include:

agent identity;
user identity;
delegation scope;
session identity;
workflow identity;
operation identity;
tool identity;
permission set;
expiry;
audit context.

This makes a basic but powerful distinction possible:

The agent may know how to do something without being the agent authorised to do it.

Least privilege for tools

Tool design should begin with the smallest capability that can complete the legitimate task.

Instead of one giant “manage account” tool, prefer narrower tools where practical:

read account status;
create draft;
submit for approval;
execute approved change;
verify final state.

This improves both security and legibility.

A narrow tool is easier to authorize, audit, test and reason about.

OWASP’s current agent-security guidance explicitly highlights tool abuse and privilege escalation as risks when agents are given powerful capabilities.

Read tools and write tools should not feel the same

A read action observes.

A write action changes the world.

That difference should appear in the workflow.

Tool class	Typical default
Read-only retrieval	lower friction, still permission-scoped
Draft creation	bounded write, no external delivery
Reversible change	approval based on consequence and scope
External communication	identity, recipient and content checks
Financial / destructive / high-impact write	strong approval, narrow authority, independent receipt

The exact boundary depends on the application.

The principle does not.

Human-in-the-loop is not one thing

“Human in the loop” can mean several different control patterns.

Clarification: the agent cannot resolve user intent safely.
Approval: the agent knows the intended action but lacks authority.
Review: the action is prepared but a person checks quality before release.
Exception handling: normal automation stops because the case is outside policy.
Escalation: risk, uncertainty or consequence crosses a threshold.
Override: a person changes or cancels an agent decision.

These should not be collapsed into one generic “ask a human” mechanism.

Each has a different reason and should return a different type of state.

Approval should bind to the exact action

A weak approval asks:

Do you approve?

A stronger approval binds the user’s consent to:

the exact action;
target object;
important parameters;
recipient;
amount or scope;
current version;
expiry;
meaningful side effects.

If the material action changes after approval, the approval may no longer be valid.

This is AVOO Interfaces applied to consent.

Related: AVOO Interfaces.

The Oracle layer: evidence before action

Agentic workflows become dangerous when retrieved evidence, model inference and user-provided claims are mixed into one undifferentiated context window.

The Oracle layer should preserve provenance.

user instruction;
system instruction;
retrieved document;
live API result;
model inference;
stored memory;
third-party content;
untrusted web content;
previous agent output.

These are not equivalent evidence classes.

The system should know what kind of thing it is relying on.

Prompt injection is partly an interface problem

An agent that reads external content and also holds tools must distinguish data from instructions.

A malicious webpage, email, file or tool response may contain text that looks like an instruction to the model.

If the system lets untrusted content cross directly into authority-bearing instruction space, the interface is wrong.

The repair is not simply “tell the model to be careful.”

label untrusted content;
separate policy from data;
scope tools narrowly;
require approval for sensitive actions;
validate tool arguments;
apply allowlists where useful;
verify receiver state independently.

NIST and OWASP both identify prompt injection as an important agent-security concern because tool-using agents can convert instruction confusion into real side effects.

Memory is not one bucket

Agent systems often use the word memory too broadly.

AVOO separates at least five memory classes.

Memory class	Purpose
Working memory	temporary state inside the current reasoning episode
Session memory	continuity across turns in one task or interaction
Workflow memory	durable checkpoints, pending actions, approvals and execution state
User memory	permitted long-lived preferences or context associated with a person
Institutional memory	policies, decisions, evidence, standards and lessons shared across operations

Each should have different rules for:

who may write;
who may read;
how long it persists;
how provenance is stored;
how conflicts are resolved;
how stale state is retired;
how sensitive content is protected.

Microsoft’s 2026 security work on AI memory makes a similar point from a security perspective: persistent memory is both valuable user data and a control surface because it can shape later agent behaviour and tool calls.

Research anchor: Microsoft Security — Guarding AI Memory.

Memory poisoning

Memory poisoning occurs when false, malicious or mis-scoped state is stored in a way that influences future decisions.

The dangerous feature is persistence.

A single bad message can become a future behavioural prior.

Defences include:

source identity;
write authorization;
confidence and status fields;
separation of fact from preference;
expiry;
conflict detection;
user review where appropriate;
ability to supersede or retire state without silently rewriting history.

Related: AVOO Memory.

Checkpoints are memory with execution consequences

Long-running agent workflows need a way to pause and resume without guessing where they stopped.

Microsoft’s Agent Framework documents checkpointing as a way to capture workflow state, pending messages, requests and responses, then resume later. It also explicitly treats checkpoint storage as a trust boundary.

Research anchor: Microsoft Agent Framework — Checkpoints.

The AVOO interpretation is:

CHECKPOINT = {
  workflow_id,
  current_state,
  completed_actions,
  pending_actions,
  pending_approvals,
  evidence_versions,
  tool_results,
  unresolved_uncertainty,
  receiver_state,
  resume_rule
}

A checkpoint is not merely convenience.

It is how continuation stays truthful.

Continue from stop must mean resume recorded state

An agent should not interpret “continue” as “invent a plausible next step.”

It should recover:

work identity;
last committed state;
completed steps;
open blockers;
approval scope;
external side effects;
pending receipts;
current version.

If that state cannot be recovered, the agent should represent the uncertainty rather than hallucinate continuity.

OUTCOME_UNKNOWN is a first-class state

One of the most important states in agentic systems is:

OUTCOME_UNKNOWN

It occurs when an external action was attempted but the system cannot reliably determine whether the action succeeded.

Examples:

a network timeout after a payment request;
a browser automation run stops after clicking submit;
an email API call loses acknowledgement;
a deployment returns an ambiguous result;
a file write may have occurred before the process crashed.

The wrong response is automatic retry.

The correct response is reconciliation.

ATTEMPTED
→ acknowledgement unreliable
→ OUTCOME_UNKNOWN
→ inspect remote state
→ reconcile
→ resume OR retry safely

Related: AVOO Interfaces.

Stable operation identity

Consequential writes should carry a stable operation identity when the surrounding system supports it.

This lets retries, logs and receipts refer to one intended operation rather than several indistinguishable attempts.

Stable operation identity helps answer:

Was this already executed?
Was this the same intent or a new intent?
Did the parameters change?
Which approval belongs to which action?
Which receipt closes which operation?

Tool result is not world state

An agent calls a tool.

The tool says “success.”

What exactly succeeded?

the request was syntactically valid;
the remote service accepted it;
the object was created;
the object is visible to the intended user;
the intended workflow is now complete.

These are different states.

The Receiver Loop should observe the state that matters.

If the task is “publish the article,” the receipt might be a live post with the expected title and URL.

If the task is “book the appointment,” the receipt might be a confirmed appointment record—not a successful click.

If the task is “send the message,” the receipt might be the provider’s stored sent-message state.

The Oracle should challenge tool outputs too

Tool output should not automatically outrank every other observation.

A tool can be stale.

An API can have eventual consistency.

A UI can render differently from the underlying write.

A remote system can partially succeed.

The Oracle should preserve disagreement until it is resolved.

Agentic legibility

A human should be able to answer important questions about an agent run without reading every hidden token the model generated.

Useful legibility fields include:

goal;
current state;
current role;
evidence sources;
tool calls;
permissions used;
approvals requested;
approvals granted;
external actions;
uncertainty;
pending blockers;
receiver receipts;
memory writes;
stop reason.

This is not the same as exposing every internal chain of thought.

The objective is operational accountability, not voyeurism into hidden reasoning.

Related: AVOO Legibility.

Trace decisions through externally useful records

NIST’s 2026 work on measurement probes for agentic ecosystems points toward a similar need: agentic systems require ways to trace decisions and evaluate whether actions were appropriate.

Research anchor: NIST — Building Measurement Probes into Agentic AI Ecosystems.

AVOO turns that into a simple operational record:

RUN RECEIPT = {
  requested_goal,
  policy_version,
  evidence_used,
  important_assumptions,
  action_authority,
  tools_called,
  external_effects,
  receiver_verification,
  unresolved_state,
  memory_changes
}

The autonomy ladder

Agentic systems should not jump directly from “chatbot” to “fully autonomous operator.”

A useful autonomy ladder is:

Advise: model provides information only.
Draft: model prepares an action but cannot send or execute.
Propose: model identifies the exact intended action and requests approval.
Execute bounded: model acts within a narrow, pre-authorized envelope.
Execute with thresholds: model acts broadly but pauses on high-risk conditions.
Delegate: agent can route work to other agents under explicit contracts.
Long-running autonomous workflow: agent can continue across time with checkpoints, monitoring and recovery controls.

The correct level depends on consequence, uncertainty, reversibility, receiver breadth and observability.

More capability does not automatically justify more autonomy.

Autonomy should scale with reversibility

Action	Typical autonomy posture
search public information	high autonomy
draft text	high autonomy
modify local reversible working state	moderate autonomy with checkpoints
send external communication	identity and approval rules based on context
change shared production state	stronger authorization and receipt
irreversible or high-impact external action	narrow authority, explicit approval, independent verification

This connects directly to AVOO Uncertainty and AVOO Optionality.

The permission matrix

For each agent, write a matrix rather than one vague permission statement.

Capability	Read	Draft	Write	Approve	Verify
Email	bounded	yes	conditional	human or policy gate	provider receipt
Calendar	bounded	yes	conditional	policy by action	event state
Code repository	yes	branch	PR / bounded	separate merge rule	CI + deployed state
Finance	strictly scoped	proposal	highly restricted	explicit authority	independent ledger state

The exact cells vary by system.

The point is to make authority visible before execution.

Multi-agent systems: role separation becomes literal

In multi-agent systems, AVOO can sometimes become physically distributed.

One agent can research.

Another can plan.

Another can operate tools.

Another can verify outputs.

But distribution introduces new failure modes:

semantic mismatch;
duplicated work;
conflicting goals;
authority leakage;
stale shared state;
cascading errors;
agent-to-agent prompt injection;
unclear responsibility;
coordination overhead.

Anthropic’s 2026 work on emerging multiagent systems notes that interactions among agents may grow rapidly and that institutions designed around human-speed oversight may face new coordination challenges.

Research anchor: Anthropic — Patterns and Problems in Emerging Multiagent Systems.

Do not create more agents than the problem needs

Multi-agent architecture can look sophisticated while merely multiplying interfaces.

Every additional agent introduces:

another identity;
another state boundary;
another communication path;
another possible semantic mismatch;
another memory surface;
another failure mode;
another audit problem.

Use multiple agents when functional separation, parallelism, specialization, independent challenge or authority partitioning creates enough value to justify the coordination cost.

Do not use them because an architecture diagram looks impressive.

The hand-off packet for agents

When one agent hands work to another, the packet should be explicit.

Task ID: exact work identity.
Purpose: why the task exists.
Current state: what is already true.
Evidence: relevant source material.
Uncertainty: unresolved questions.
Authority: what the receiving agent may do.
Forbidden actions: explicit boundaries.
Tools: available capabilities.
Thresholds: when to pause or escalate.
Expected output: what should return.
Receipt: how success will be verified.

This is AVOO Interfaces expressed as an agent contract.

The Visionary in agent systems

Agent design discussions often focus on planning, tools and security.

The Visionary function asks a different question:

What future behaviour are we teaching this system to normalise?

If every task is optimised for speed, caution becomes a cost.

If every evaluator rewards completion, escalation becomes failure.

If every memory mechanism rewards persistence, forgetting becomes difficult.

If every tool is optimized for autonomy, user agency becomes friction.

The Visionary protects the value system surrounding the agent, not merely the immediate task.

Agent incentives

Agents optimise what the surrounding system rewards.

That reward can be explicit:

training reward;
benchmark;
completion score;
human preference;
automated evaluator;
cost target;
latency target.

Or implicit:

which actions are easy;
which tool results are treated as terminal;
which errors are penalised;
which escalations are counted as failure;
which behaviours receive more context or compute.

The AVOO rule is:

Do not reward the proxy more strongly than your ability to verify the purpose.

Related: AVOO Incentives.

Stop conditions belong in the design

Long-running agents need explicit reasons to stop.

goal achieved and receiver verified;
required evidence missing;
authority insufficient;
tool permission denied;
uncertainty exceeds threshold;
budget exceeded;
loop repeats without progress;
external state contradicts plan;
safety or privacy boundary crossed;
human approval required;
outcome unknown after consequential write.

An agent without stop conditions can convert persistence into damage.

Related: AVOO Thresholds.

Loop detection

An agent may get stuck repeating:

the same search;
the same tool call;
the same failing repair;
the same delegation;
the same self-critique.

A mature workflow tracks progress, not just activity.

Useful loop thresholds include:

maximum repeated identical action;
maximum budget without new evidence;
maximum iterations without state change;
maximum unresolved contradictions;
required escalation after repeated fallback.

Budget is a constraint and a safety control

Agent budgets can include:

time;
tokens;
money;
tool calls;
external writes;
human attention;
risk exposure.

A budget should not merely reduce cost.

It should force the agent to expose diminishing returns.

If another ten searches are unlikely to change the decision, the Oracle should stop searching.

If another retry will not resolve an unknown outcome, the Operator should reconcile rather than spend budget repeating.

Agent resilience

Agentic workflows should degrade gracefully when components fail.

model unavailable;
tool unavailable;
memory store unavailable;
approval channel unavailable;
network degraded;
retrieval incomplete;
external API changed.

Resilience patterns include:

fallback model;
fallback tool;
read-only degraded mode;
checkpoint and resume;
manual escalation;
small blast radius;
idempotent retry where supported;
explicit failure rather than fabricated completion.

The strongest resilience rule may be the least glamorous:

When the system cannot prove success, fail legibly rather than invent success.

Related: AVOO Resilience.

Evaluation should test the whole workflow

Evaluating only the base model can miss the risk introduced by tools, memory, permissions and external systems.

NIST’s TEVV-Athlon framework is explicitly intended to support evaluation of varied AI systems, including agentic systems, with attention to real-world impact and outcomes.

Research anchor: NIST — TEVV-Athlon Framework for Evaluating AI Systems.

An AVOO evaluation therefore tests at least:

intent understanding;
evidence quality;
uncertainty calibration;
planning;
tool selection;
permission boundaries;
argument correctness;
external action correctness;
recovery;
memory;
receiver outcome;
ability to stop.

Test the unhappy paths

Happy-path demos are not enough.

Test:

missing permission;
stale memory;
conflicting sources;
malicious retrieved content;
tool timeout;
partial write;
approval denied;
approval expires;
wrong recipient;
wrong account;
duplicate operation;
external state changes mid-run;
tool schema changes;
agent loops;
handoff mismatch;
receiver reports failure after internal success.

The system is not production-ready merely because it can complete the ideal task.

Agent case 1 — Research assistant

A research agent is asked to explain a new technical standard.

The safe architecture is relatively permissive because the agent is mostly reading.

Oracle searches primary sources.
Architect defines source-priority rules.
Visionary preserves the user’s actual question rather than collecting trivia.
Operator opens sources and extracts evidence.
Receiver is the final answer checked against the cited material.

The main risks are evidence quality, source freshness, citation mismatch and overclaiming—not destructive side effects.

Agent case 2 — Email workflow

An agent reads a message, drafts a reply and may send it.

The architecture should distinguish:

read authority;
draft authority;
send authority;
recipient identity;
thread identity;
approval requirement;
sent-message receipt.

The model may be perfectly capable of drafting while still being intentionally prevented from sending without approval.

That is not a capability failure.

It is governance.

Agent case 3 — Coding agent

A coding agent can inspect a repository, edit files, run tests and open a pull request.

A stronger workflow separates:

repository read;
local edit;
local execution;
test result;
branch write;
pull-request creation;
merge authority;
production deployment.

NIST’s 2026 work on agentic AI-assisted coding argues for explicit epistemic grounding documents that encode hard validity constraints and field-scoped conventions—another way of keeping model generation subordinate to domain truth.

Research anchor: NIST — Epistemic Grounding for Agentic AI-Assisted Coding.

Agent case 4 — Publishing agent

A publishing agent researches, drafts, checks collisions, creates a post and verifies the public URL.

The workflow should not equate:

GOOD DRAFT
≠ APPROVED EDITION
≠ SUCCESSFUL WRITE
≠ REMOTELY OBSERVED POST
≠ CORRECT RENDER
≠ SEARCH INDEXING

Each is a different state.

The agent should preserve:

canonical owner;
collision result;
source packet;
approval scope;
publication identity;
remote receipt;
verification state.

This lets publishing scale without treating a tool call as proof of a reader-facing result.

Agent case 5 — Educational tutor

An educational agent should not simply maximise helpful-sounding output.

It needs to preserve the learner as Receiver.

Oracle diagnoses the learner’s current understanding.
Architect chooses the next learning route.
Visionary protects long-term independence rather than permanent assistance.
Operator delivers explanation, practice and feedback.
Receiver returns evidence through independent performance.

A tutor that gives every answer may optimise short-term satisfaction while degrading the future capability it exists to build.

This is an incentive and receiver problem, not merely a language-generation problem.

The agent authority card

For every acting agent, write:

Identity: which agent is this?
Principal: for whom is it acting?
Purpose: what outcome is it pursuing?
Tools: what capabilities exist?
Read scope: what may it inspect?
Write scope: what may it change?
Approval scope: what requires a person or higher authority?
Budget: time, money, calls, risk?
Stop conditions: what forces pause or escalation?
Memory: what may persist?
Receipt: what proves success?
Audit: what record must remain?

The agent memory card

Memory type: working, session, workflow, user or institutional?
Writer: who may create or modify it?
Source: where did it come from?
Status: fact, preference, inference, rule, temporary state?
Confidence: how strong is the claim?
Scope: which user, task or domain may use it?
Expiry: when should it be reviewed or retired?
Conflict: what happens if newer evidence disagrees?
Privacy: who may read it?

The tool-call card

Operation ID
Tool
Target object
Arguments
Authority basis
Approval ID if required
Expected effect
Reversibility
Tool response
Observed external state
Receiver receipt

The twelve agent anti-patterns

Model-is-the-system: governance and external state are ignored.
Confidence-is-authority: fluent certainty unlocks action.
Tool-success-is-success: API acknowledgement replaces receiver verification.
One giant tool: read and destructive powers are bundled together.
Memory soup: preferences, facts, guesses and instructions persist without type.
Approval theatre: the user approves a vague intention rather than the exact action.
Blind retry: uncertain external outcomes are repeated.
No stop rule: the agent continues because it can.
Agent multiplication: more agents are added without marginal value.
Self-certification: the same agent acts and declares itself successful.
Prompt-boundary collapse: untrusted content is treated as authority-bearing instruction.
Permanent emergency autonomy: temporary expanded permissions never expire.

The agent maturity path

A practical deployment path can evolve through stages.

Stage	Characteristic
Assistant	answers and drafts; no consequential tools
Tool user	bounded reads and reversible actions
Governed operator	approval gates, typed state, receipts
Durable workflow	checkpoints, resume, recovery, persistent audit
Multi-agent system	explicit handoffs, agent identities, bounded delegation
Institutional agent layer	policy-governed, measured, maintainable, auditable operating capacity

The stages are not a score.

A simple assistant may be the correct architecture for a simple task.

The AVOO agent audit

Before deploying an agentic workflow, ask:

What exact user or institutional purpose does this agent serve?
Which decisions belong to model reasoning and which belong to governance?
What data can the agent read?
What tools can it call?
What writes are possible?
What actions require approval?
Can the user see the material action before approving it?
How is identity represented?
How is provenance preserved?
What memory persists?
What can poison that memory?
How are prompt injection and untrusted data contained?
What state is checkpointed?
What happens after a timeout?
Can the agent represent OUTCOME_UNKNOWN?
How are retries made safe?
What stop conditions exist?
How is receiver success verified?
What logs or run receipts remain?
How will the workflow be re-evaluated when models, tools or policies change?

Almost-code: AVOO agent runtime

AGENT_RUN = {
  run_id,
  user_intent,
  policy_version,
  authority_envelope,
  evidence_state,
  memory_state,
  workflow_state,
  budget,
  stop_conditions
}

VISIONARY.bind(user_intent, protected_purpose)

ORACLE.read() -> {
  evidence,
  provenance,
  uncertainty,
  contradictions,
  current_world_state
}

ARCHITECT.plan() -> {
  steps,
  tools,
  dependencies,
  checkpoints,
  fallbacks,
  receiver_receipts
}

FOR step IN plan:

  verify(step_within_authority)

  IF evidence_insufficient:
    ORACLE.retrieve_or_escalate()

  IF approval_required:
    pause()
    bind_approval_to_exact_action()

  IF untrusted_content_attempts_to_change_authority:
    reject_instruction_escalation()

  checkpoint_before_consequential_action()

  OPERATOR.execute(step)

  IF acknowledgement_missing:
    state = OUTCOME_UNKNOWN
    reconcile_remote_state()
    DO_NOT blind_retry()

  receipt = RECEIVER.observe()

  IF receipt != expected:
    reopen_diagnosis()

  IF protected_boundary_crossed:
    STOP

  IF repeated_no_progress:
    ESCALATE

MEMORY.write_only_if(
  authorised,
  typed,
  scoped,
  provenance_preserved
)

final_receipt = {
  intended_goal,
  actions,
  approvals,
  external_state,
  unresolved_items,
  memory_changes
}

The deeper problem: agents compress institutions into software

Human organisations have accumulated many control structures over centuries.

separation of duties;
review;
signatures;
permissions;
appeals;
audits;
professional standards;
logs;
contracts;
receipts;
records;
succession.

An AI agent can make these controls feel slow because the model can reason and act much faster than the institution around it.

The temptation is to remove the controls.

The better question is which controls can be encoded, compressed, automated or moved to thresholds without losing their purpose.

NIST’s current agent-standards work is significant for exactly this reason: interoperability and security are becoming ecosystem problems, not merely model problems.

Human-speed governance in machine-speed systems

A powerful agent can produce actions faster than humans can review them individually.

The answer is not necessarily to review every action manually.

It is to move governance into architecture.

pre-authorize low-risk classes;
require approval above explicit thresholds;
limit privileges;
create safe defaults;
make high-impact writes narrow;
checkpoint before expensive transitions;
verify receivers independently;
retain stop authority.

This is how governance can scale without disappearing.

Do not delegate what you cannot observe

Autonomy should not outrun observability.

If the system cannot tell:

what the agent did;
which tool acted;
which account was affected;
which external state changed;
which approval applied;
what receiver result occurred;

then granting more autonomy may create invisible risk.

A useful rule is:

Increase autonomy only as quickly as identity, authority, legibility, recovery and receiver verification can keep up.

Do not remember what you cannot govern

Persistent memory increases capability.

It also increases blast radius.

If a system cannot answer who wrote a memory, why it is trusted, where it applies, when it expires and how it can be corrected, the memory may be more dangerous than useful.

Do not automate uncertainty away

Agents are often deployed because humans dislike waiting.

That creates pressure to turn uncertain states into decisive output.

AVOO keeps uncertainty visible.

The agent should be allowed to say:

evidence incomplete;
two sources conflict;
approval scope unclear;
remote outcome unknown;
receiver not yet verified;
safe continuation requires human input.

Uncertainty represented correctly is not agent failure.

It is system honesty.

World Return

The World Return of AVOO and AI Agents is simple:

Let the model think. Let the Oracle challenge. Let the Architect bound the workflow. Let governance decide what may cross into action. Let the Operator act only inside that authority. Then ask the world what actually happened before allowing memory to turn the result into future state.

Do not confuse fluency with evidence.

Do not confuse evidence with authority.

Do not confuse authority with unlimited privilege.

Do not confuse a tool call with an external result.

Do not confuse an external result with receiver success.

Do not confuse stored state with trusted memory.

Do not retry an uncertain side effect because impatience feels like evidence.

Do not make a human approve a vague intention when the material action can be shown precisely.

And do not give an agent more autonomy than the surrounding system can observe, constrain, recover and correct.

Final definition

AVOO and AI Agents is the machine-workflow application of eduKateSG’s Architect, Visionary, Oracle and Operator framework. It separates model reasoning from action authority, treats tools as governed interfaces, keeps evidence and provenance distinct from inference, uses typed memory and checkpoints for continuity, represents uncertain external outcomes explicitly, requires receiver-side verification for consequential work, and scales autonomy only with identity, permissions, observability, recovery and stop mechanisms. Its purpose is not to make AI agents less capable. Its purpose is to make capability corrigible enough to operate safely inside real systems.

AVOO and AI Agents | How Architect, Visionary, Oracle and Operator Work in Machine Workflows