Six AI Agent Architectures—and the Controls Each One Needs

On July 20, CIO.com published Bernard Aceituno's The 6 kinds of AI agent architectures, distilling three years across hundreds of enterprise deployments into six archetypes a CIO should recognize on sight. The taxonomy's strength is that it refuses hierarchy: none of the six outranks the others; the skill is matching the archetype to the problem's shape. The column closes on a sentence that hands the platform world its homework: "adoption, governance, trust — only gets easier if the architecture is the right fit" (this post's one quotation from the source). Each of the six fits differently — and the six do not share the same control points. This article maps the model and tool traffic behind each archetype — not the complete application runtime — to documented capabilities in TrueFoundry AI Gateway, MCP Gateway, and Agent Harness. Each kind gets its own section: what it is, then where the documented controls bind it, with the configuration prerequisites stated. A summary table follows the six, and a fourth diagnostic question closes the argument.

Kind 1: The Conversational Assistant

What it is

The chat-based partner a person opens when they want to think out loud — the archetype most enterprises meet first, and the one the column reports people fall in love with when it's built right: constantly updated information, persistent user-level memory, tools that act on the user's behalf, and a citation on every factual claim. In Deloitte's State of AI in the Enterprise survey, 38% of organizations report enhanced client or customer relationships as a benefit already achieved through their AI initiatives. The column's examples show the range: a global law firm whose associates start research from a citation-backed answer over the firm's accumulated precedent instead of an hour in document management, and a wealth manager whose clients get grounded portfolio answers on a Sunday. If the enterprise is a building, this is the front desk: it never sleeps, it cites its sources, and everyone in the lobby talks to it — which is precisely the operational point.

Where TrueFoundry fits

The dominant risk is the conversation surface itself: people paste what they paste, models answer what they answer, and volume scales with seats. The binding instruments are the request path's two ends. llm_input guardrails run PII and secrets detection with mutate mode — the pasted credential is redacted and the request continues, so protection never teaches users to route around the sanctioned path (the argument of our gateway-vs-application PII analysis; note that the TrueFoundry-managed PII/PHI built-in is documented for the TrueFoundry-hosted gateway — self-hosted and hybrid deployments configure a bring-your-own-key or external-provider alternative) — and llm_output checks can inspect the completed response — on non-streaming paths. The documented boundary matters for this archetype in particular: output guardrails need the complete response, so they are skipped when stream: true is set, while input guardrails run regardless of streaming mode (guardrails docs). Conversational assistants are among the workloads most likely to stream, so a streaming assistant needs a deliberately chosen output-safety strategy: a non-streaming path for sensitive requests; a client that buffers the complete streamed response, validates it, and only then displays it — accepting that this gives up token-by-token presentation; or input-only guardrails accepted as the trade, with post-stream validation understood as detection after delivery. The execution model is otherwise engineered for this archetype's latency budget: input validation runs in parallel with the model call, and if validation fails while the model is still running, the gateway cancels the in-flight request so you don't pay for a response you were going to discard (same docs). Around the hooks: team-scoped budgets for seat sprawl, and semantic caching — assistant traffic often contains repeated or semantically similar questions, so where freshness and response-variance requirements permit caching, it is a cost instrument before it is a latency one.

Kind 2: The Triggered Workflow

What it is

The pattern that runs silently: an email arrives, a ticket is created, a file lands in a folder, and the agent executes a process mixing reasoning with determinism. No user adoption required, because no user sees it — the column's insurer wakes up to an underwriting inbox that arrives pre-classified with risk fields extracted, and its private-equity firm finds each inbound CIM screened, memo-drafted, and posted to deal-tracking before anyone opens the file. It is the enterprise mail room, upgraded: nobody visits it, everybody depends on it, and its virtue is that it fits cleanly into the audit and change-control processes IT has run for decades.

Where TrueFoundry fits

The calm reputation conceals a demanding threat model: this archetype executes unattended on untrusted input. Every inbound email, attachment, and dropped file is a potential prompt-injection payload — instructions hiding in the very content the workflow was built to read, the attack class our gateway injection-defense guide details. Binding instruments: input-side guardrails screening the trigger payload before the model reads it — the managed Prompt Injection built-in on the TrueFoundry-hosted gateway, or a documented external-provider alternative on self-hosted and hybrid deployments — tool restrictions keeping the workflow's write-surface minimal (MCP Gateway docs), and rate limits so a mail-bomb doesn't become a thousand autonomous executions. The column's audit-friendliness observation holds on the plane, with the mechanics stated precisely: every request routed through the gateway records trace metadata — cost, token usage, latency, and request metadata — regardless of logging settings. Logging configuration separately controls whether request and response bodies are stored and, when they are, which sensitive values are redacted in the stored copy. Teams should define both the audit evidence they require and the content they are permitted to retain.

Kind 3: The Autonomous Agent — with Sub-Agents

What it is

Given a task, it plans its own steps and calls its own sub-agents. The column is precise about where it belongs — multi-source research, complex cross-system lookups, deep-dive investigations: processes where the path isn't specified in advance, but the tools are. Its consulting-firm example scopes early-stage engagements by choosing for itself which sub-agents to consult across proprietary databases, engagement archives, licensed market data, and public filings, then produces a structured briefing with its supporting evidence and rationale attached; its technology-company example investigates production incidents by forming a hypothesis and following it through monitoring, logs, and deployment systems until it reaches a defensible root-cause summary for an engineer. The right analogy is a detective, not a courier: you specify the case and the badge's limits, never the route.

Where TrueFoundry fits

"The path is discovered" is a cost and blast-radius statement: the path is not statically bounded by a workflow definition, so token counts and tool sequences are less predictable — until controls make them predictable. Binding instruments: budgets and rate limits as the mandate's hard edges; per-sub-agent tool scoping through the MCP registry, with Cedar and OPA policy guardrails available for fine-grained, default-deny control over which tools each sub-agent may touch (guardrails docs); and step-level traces in the Agent Harness — which are how a discovered path becomes a reviewable one. A precision worth keeping: these are execution traces — model calls, sub-agent turns, tool invocations, timing, cost, and results — an operational audit trail of observable actions, not access to a model's hidden chain of thought. One documented detail matters enormously here: guardrails evaluate every tool call separately — an agent that calls five tools gets five independent checks, so autonomy never outruns inspection.

Kind 4: The Multi-Agent Team

What it is

Several specialized agents, each with its own role and toolset, coordinating through a shared protocol — where the column argues the next wave of enterprise quality gains comes from. Databricks' State of AI Agents report measures 327% growth in multi-agent-system usage in less than four months — platform telemetry drawn from more than 20,000 organizations on its Data Intelligence Platform, not a population-wide measure. The signature technique is the proposer-critic loop: one model produces, a second — with a different prompt and often a different provider — evaluates against explicit criteria, the way a newsroom pairs writers with editors. The column's bank runs drafting, brand-compliance, and jurisdiction-disclosure agents whose disagreements surface to a human with clauses flagged; its pharma company runs retriever, reader, critic, and synthesizer agents over medical literature, and credits the critic pass for the medical affairs team trusting the output enough to act on it.

Where TrueFoundry fits

The team multiplies whatever a single agent had — identities, tool reaches, token flows — and adds a seam the column highlights without pricing: the critic being a different provider's model means, in a bespoke stack, a second integration, second credentials, second logging path. The gateway removes much of that provider-specific connection and credential plumbing: the unified, OpenAI-compatible API puts the drafting model and the critiquing model behind one schema (gateway docs). What it does not do is implement the loop. The application or Agent Harness still owns the orchestration — sequencing the turns, constructing the critic's evaluation criteria, carrying state between roles, handling disagreement, and deciding when to revise, stop, or escalate — and a shared request schema does not make providers semantically interchangeable. The multiplied risk is attribution, and the documented model is specific about it: individual agent attribution requires a distinct registered Agent Identity for each independently governed role — the per-agent principal every agent must present when it touches the MCP Gateway or Agent Gateway. A Virtual Account, by contrast, represents a service or application and is appropriate where agent-level identity is not required; assigning several agents one Virtual Account collapses them into a single gateway caller. Identity answers who the agent is; the associated Agent Registration and scoped gateway policies then define who may call the agent, whom it may act on behalf of, and which downstream tools or services it may reach (the docs note some capabilities on that page are rolling out incrementally). When the roles coordinate agent-to-agent at scale, the protocol-layer governance is the subject of our multi-agent A2A analysis. Tool calls flowing between roles cross the pre- and post-invoke hooks like anyone else's: per-hop inspection.

Kind 5: The Human-in-the-Loop Agent

What it is

The column makes a clear correction to the autonomy discourse: the practical target is selective automation rather than maximum autonomy. The agent handles the mechanical 80% while human judgment remains at the consequential moments. In Moody's global survey of 600 risk and compliance professionals, 42% said human oversight is mandatory. Its health-system example assembles clinical evidence and drafts prior-authorization letters that a nurse case manager approves, edits, or rejects in seconds inside the existing workflow tool; its property manager's agent parses a tenant's HVAC emergency, matches the vendor, drafts the work order — and a person approves in Slack before anything goes out, after which the agent emails the vendor, reassures the tenant, and closes the loop. In the column's experience, this is the archetype that turns skeptical teams into enthusiastic ones.

Where TrueFoundry fits

This is the archetype with the most direct product primitive: Agent Harness implements the core HITL mechanism — pausing a sensitive tool call, surfacing the tool name and arguments, and resuming only after an explicit allow or deny (Human in the Loop docs), configured on the sensitive operations and only those. The surrounding review experience — who receives the request, where it appears, how long it may wait, what happens after timeout — remains workflow design, and approvals complement rather than replace authorization. The design risk is ergonomics — a gate that takes minutes gets bypassed; a gate on everything becomes noise — so the discipline is task-shaped access, granting and gating by what the task warrants, the model our TBAC analysis develops. The built-in guardrail catalog supplies the gate's mechanical screens so human attention concentrates on judgment: when attached to the pre-tool hook, the documented SQL Sanitizer can block DROP, TRUNCATE, and WHERE-less deletes before the downstream tool executes them, and the Code Safety Linter likewise flags dangerous shell patterns on the hooks it's configured for (guardrails docs) — the guardrail's existence alone doesn't intercept anything; the hook attachment does.

‍