Notifications
Clear all
Topic starter
19/08/2026 3:43 pm
TL;DR: Six AI agent archetypes create different governance boundaries, and TruFoundry’s analysis argues the right control plane depends on whether the system is a conversational assistant, triggered workflow, autonomous agent, or human-in-the-loop design. The key assumption collapse is that one access model can govern all agent behaviours, because execution timing, tool reach, and approval needs diverge by architecture.
NHIMG editorial — based on content published by TruFoundry: Six AI Agent Architectures and the Controls Each One Needs
By the numbers:
- 38% of organizations report enhanced client or customer relationships as an achieved benefit through AI initiatives, according to Deloitte.
- 42% of 600 surveyed risk and compliance professionals say human oversight is mandatory, according to Moody's.
- Multi-agent usage rose 327% in less than four months across 20,000+ organizations on the Data Intelligence Platform, according to Databricks.
Questions worth separating out
Q: How should teams govern AI assistants, workflows, and autonomous agents differently?
A: Teams should govern them by runtime behaviour, not by model family.
Q: Why do autonomous AI systems create more identity risk than normal automation?
A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person.
Q: What breaks when streaming assistants rely on output guardrails alone?
A: Output guardrails cannot inspect a complete response before the user sees it when the system streams tokens in real time.
Practitioner guidance
- Map each AI workload to a named architecture Classify every assistant, workflow, autonomous agent, and human-in-the-loop system by how it executes, not by which model it uses.
- Place guardrails at the correct execution boundary Apply input screening before the model reads trigger data, apply output inspection only where complete responses exist, and avoid assuming the same hook works for streamed and non-streamed paths.
- Assign distinct identities to agent roles Give each independently governed agent a separate principal, scoped tools, and observable traces, then restrict cross-agent delegation to the minimum needed for the task.
What's in the full article
TruFoundry's full article covers the operational detail this post intentionally leaves for the source:
- Specific gateway enforcement points for input validation, output inspection, and logging across different agent patterns.
- Documented configuration prerequisites for streaming assistants, triggered workflows, and autonomous agents.
- The control mapping between MCP traffic, Agent Harness approval gates, and managed orchestration boundaries.
- The article's summary table and diagnostic questions for choosing the right agent architecture.
👉 Read TruFoundry's analysis of six AI agent architectures and control boundaries →
Six AI agent architectures: what controls do teams need?
Explore further
19/08/2026 4:21 pm
Six archetypes are not a maturity ladder, they are six different identity problems. Treating assistants, workflows, autonomous agents, and human-in-the-loop systems as one category creates policy drift, because each architecture concentrates risk in a different plane. The control point may be the conversation surface, the trigger payload, the agent identity, or the approval gate. Practitioners should map governance to runtime shape, not to the generic label "AI system".
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to SailPoint research.
A question worth separating out:
Q: Who should be accountable for AI agent approvals and audits?
A: Accountability should sit with the human owner of the agent path, the application owner, and the identity governance process together. The agent cannot be the sole accountable subject because it is not a governance endpoint. Teams should tie approvals, logs, and access reviews to the person or team responsible for the agent’s use.
👉 Read our full editorial: Six AI agent architectures expose distinct control boundaries
