This series documents the design and operation of an evidence-driven, self-improving Dynamic MAS and AI clone environment from the SPA-IT perspective: Security, Privacy, and AI Governance as an integrated discipline.
Part 1 covered the conceptual background: why this is neither a chatbot nor a fixed workflow, and why evidence-driven operation matters.
This second article continues that discussion by organizing the design principles required to place AI agents in an explainable and governable operating state, rather than merely making them run.
This article focuses on governance issues and design judgments, not on implementation details that would make the system directly reproducible. Concrete implementation evidence and architecture details will be addressed in later parts only where they can be shown with appropriate evidence and accountability.
Why This Is Neither a Chatbot Nor a Fixed Workflow
The Limits of Chatbots
A chatbot responds to requests, but it does not manage tasks. Once the conversation ends, the context disappears. There is no structural mechanism for next week’s session to inherit last week’s judgment. Progress, evidence, and approval records do not persist by default.
The Limits of Fixed Workflow Automation
RPA and fixed-sequence automation execute predefined procedures mechanically. Real work, however, changes route depending on context. It often requires examination from multiple perspectives and includes boundaries where human judgment is necessary. Fixed procedures do not have that flexibility.
What Dynamic MAS Solves
A Dynamic MAS, or dynamic multi-agent system, selects and dispatches agents according to the nature of the task, enables them to deliberate, and leaves evidence as work progresses. The design challenge is to combine adaptability to changing conditions with governance-level accountability.
The Core Design: Four Principles
I organize the design into four principles. This is a synthesis from my implementation experience. The important point is that these principles must be treated as an integrated part of an autonomous AI agent foundation.
1. MCP-first: A Standard Tool Bus
Core operations should be routed through standardized protocol interfaces wherever possible. Task creation, evidence attachment, deliberation, notifications, and approvals should be handled through a common interface. Direct CLI calls can remain as fallbacks, but when they are used, recording them in audit logs should be mandatory.
The reason for choosing a standard bus is simple: auditability. If every call is retained as an audit record, it becomes possible to trace who used what, when, and for what purpose. From a security perspective, this localizes the attack surface. From a governance perspective, it centralizes audit points.
2. RDB-backed: Use a Structured Persistent Store as the Source of Truth
AI memory is unstable. Interpretation shifts across sessions. The only fundamental way to address this is to move state management outside the AI.
A structured persistent store, specifically a relational database, should be used as the Source of Truth for task transitions, evidence, rules, and approval records. Even if the AI forgets, the database remembers.
The core of this architecture is that deterministic database constraints provide consistency against probabilistic AI behavior. The principle is not to leave state management to the AI.
3. Evidence-driven: Evidence as a Structural Requirement
Even if an AI claims that a task is complete, the system should not recognize completion without evidence. A completion declaration should structurally require evidence attachment. This prevents completion from depending on AI self-attestation.
In governance terms, completion without evidence is effectively nonexistent. I consider this the most defensible implementation of the accountability expected by ISO/IEC 42001.
There is, however, a tension between richer evidence and privacy or data minimisation. If the system records more evidence, accountability improves, but the evidence itself can become a new risk unless the design defines what is recorded, why it is recorded, and for what purpose it may be reused. This point is easy to miss when Security, Privacy, and AI Governance are treated separately. In an evidence-driven MAS, the goal is not to record more, but to record in a way that is explainable against purpose. I will address this in more detail in a later privacy-focused part.
4. Self-improving: Turning Failure Into an Asset
The system should combine periodic external information intake, small improvement experiments, and escalation design for repeated failures, so that failures and blocked states become improvement candidates.
The system detects its own problem states, such as tasks that remain stalled or tasks whose evidence is not connected, and generates repair tasks. At the same time, core policy changes, major architecture changes, and externally impactful changes are outside the scope of self-improvement and must go through human judgment.
Designing HITL Boundaries
One of the most important questions in AI operation is where human judgment should enter. Full automation is dangerous, while full human judgment defeats the purpose of automation.
In this system, examples of human-approval domains include external publication, changes that affect persistent data structures, operations involving credentials, and changes that affect production environments. This is only one example of HITL boundary design and is not exhaustive. Actual escalation conditions are designed according to risk. I plan to address that in detail in Part 5.
Positioning From an AI Governance Perspective
I emphasize embedding the elements prioritized by ISO/IEC 42001, the NIST AI RMF, and discussions around AI agent identity management at NCCoE: accountability, evidence, HITL, and risk-tier management.
AI governance should not be treated as documentation added afterward. For operational AI agent foundations, governance must be designed into the structure of the system itself.
Conclusion
Making AI run is no longer difficult. What remains difficult is explaining afterward what the AI did and designing the boundaries around AI judgment.
MCP-first, RDB-backed, evidence-driven, and self-improving: these four principles are a design philosophy for addressing that difficulty. Autonomy and governability can coexist when they are designed together.
In Part 3, which will focus on implementation evidence, I plan to show the flow from external input to task creation, agent processing, human judgment, and evidence capture, using evidence and screen examples that can be made public.
This article went through a generation, review, and evidence-capture process using my Dynamic MAS environment, followed by final human review. Before publication, it was checked to ensure that it does not include credentials, internal paths, unimplemented claims, or overly reproducible design details.