Introduction: “AI That Runs” and “AI That Runs in a Controllable State” Are Not the Same Thing
Automating work with AI is no longer particularly difficult. Call an LLM, use the result, and it runs. The real question is whether that “running” state is sustainable.
What I have been building over the past several months is not merely a system that runs, but a system that runs autonomously while remaining in a controllable state. This article documents the design decisions behind that effort and the reasoning for each, through the lens of SPA-IT — Security, Privacy, and AI-governance: Integrated Technology.
1. Why “Dynamic MAS”?
There is a fundamental difference between fixed-workflow automation and a Dynamic Multi-Agent System.
Fixed workflows are powerful when the assumed procedure is working correctly. But the moment a situation changes, an exception occurs, or a premise breaks — they stop, and a human must intervene. They are systems that halt at the edge of what their designer anticipated.
In a Dynamic MAS, the composition of agents, routing, and fallback behavior changes with circumstances. When task priority shifts, the responsible agent shifts. When one route fails, the system switches to another. This situational adaptation is the fundamental reason the architecture can sustain long-running, multi-faceted operations.
In the context of industry standards, this is an implementation of what IEEE P3394 and the NCCoE AI Agent Identity framework describe as “autonomous agent / dynamic spawn / inter-agent communication.” But the distance between what is written in papers and frameworks and what actually surfaces when you run the system is significant.
2. Not Trusting AI Memory — The RDB-Backed Design Choice
LLM output is inherently variable. The same prompt produces different responses. Long contexts cause earlier information to fade. This is a characteristic of LLMs, not a defect. The problem is designing a system without accounting for that variability.
My choice was to make PostgreSQL the sole Source of Truth. Task state, approval history, agent execution records, evidence — all of it is written to the RDB. Agents read state from the RDB, act, and write the results back. Database constraints, not AI memory, enforce consistency.
What this delivers is reproducibility and auditability. When the question arises — which agent made which decision at which point yesterday, and which human approved it — the design can answer immediately. This is what I determined to be the most robust implementation of the documentation and accountability requirements in ISO/IEC 42001.
3. Why MCP as the Standard Tool Bus
Model Context Protocol (MCP) standardizes how AI connects to external tools. Compared to calling each tool directly through individual CLIs, an MCP-mediated architecture looks, at first glance, like an extra layer. The reason for choosing the standard bus is this:
In a direct-CLI architecture, the connection method, error handling, and authentication logic differ per tool. Adding a new tool changes the overall design. This is fast in the short term and accumulates maintenance cost and attack surface over time.
With MCP, the connection layer is standardized. Since every call routes through the same path, logging, auditing, and permission checks can be consolidated in one place. In security terms, this is attack surface localization. In governance terms, it is centralization of audit points. I chose MCP to preserve consistency at extension time.
4. Evidence-Driven Governance — Making the Audit Trail Part of the Design
The fact that “AI did something” does not exist in governance terms unless it is recorded as evidence.
In this system, every significant action is linked to an evidence_refs record. Which task produced which evidence, which approval is substantiated by which evidence — this chain is the substance of the audit trail. Rather than writing output to log files, structuring it as RDB records makes it mechanically searchable and verifiable after the fact.
This is not about formally satisfying ISO or NIST requirements. It is because a system where you cannot immediately identify which agent processed what, and when, is not functionally operational from a governance standpoint. Evidence design belongs at the center of the architecture, not bolted on afterward.
5. Designing the HITL Boundary — What to Automate and Where to Require Human Judgment
The hardest part of HITL design is defining the boundary. Having humans approve everything is safe but does not scale. Full automation is fast, but eventually produces a situation where the system is running exactly as specified — in a direction you did not intend.
My boundary design references the eight escalation triggers proposed in the NCCoE concept paper on AI agent identity: transmission of data to a new destination, writes to a production environment, access to personal information, threshold exceedance, self-modification of plans, consecutive exceptions, spawning of child agents, and departure from defined scope. Any of these triggers requires human approval.
Conversely, low-stakes, reversible tasks that do not trigger any of these conditions proceed automatically. This explicit boundary is what makes autonomy and controllability coexist.
6. The Self-Improvement Loop — A System That Detects Its Own Problems
Any system that keeps running will degrade over time. Tasks accumulate, evidence gaps appear, rules drift from reality. Having a human monitor this continuously is not realistic.
This system includes a mechanism that monitors its own state and detects problem conditions. Tasks that are stuck mid-execution (partial), tasks rendered unexecutable because a dependency changed (frozen), actions without associated evidence — these conditions are detected and repair tasks are generated. Additionally, changes in AI technology, MCP specifications, and LLM security are ingested daily, scored for relevance, and prioritized.
The boundary of self-improvement is also explicitly defined. Changes to core policy, major architectural changes, anything that affects external services, changes to rules governing human HITL decisions — these are outside the scope of self-improvement and always require human judgment.
7. The AI Clone Direction
One of the long-term directions this system is working toward is an AI clone — not merely automating tasks, but reproducing my own judgment axes, thinking patterns, and priorities in an AI.
This is less a technical challenge than a governance one. When an AI designed to act on your behalf makes a decision, where does accountability lie? How much judgment can legitimately be delegated? Without embedding those answers into the design, a clone AI becomes a “useful but uncontrollable proxy.”
From the SPA-IT perspective, the AI clone is the domain where HITL density and evidence density must be highest. Every time the clone acts, it creates evidence. Every time it makes a judgment, it passes through a human approval gate. That is my current design position.
Conclusion: “Designed Trust” Versus “Ungrounded Trust”
Many organizations that use AI place implicit trust in a state they describe as “it seems to be working.” No errors means it is running. Logs exist means it is auditable. But “running” and “running as intended” are different propositions.
Evidence chains, HITL boundaries, and self-improvement loops are all mechanisms for converting AI system trust from “implicit” to “grounded by design.” Not to satisfy standards requirements, but to ensure that humans can continuously understand what is actually happening.
The faster AI operates, the more visible the difference between a system where trust is designed and one where it is not — the difference between something you can govern and something that governs you.
This article represents the personal views of the author as of May 2026 and does not reflect the position of any affiliated organization.