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.

Kind 6: The Scheduled Agent

What it is

On a schedule or against a batch, the same defined task, forever: produce the report, refresh the dataset, monitor the sources, summarize the period. The column's private-equity firm gets a single PDF in every deal partner's inbox at Monday 6 a.m., covering news, filings, and earnings across the whole portfolio, so the weekly meeting starts from a shared baseline; its manufacturer's nightly agent turns each day's quality-control reports into a per-site handoff document that surfaces the slow-moving patterns no human reading one shift's data would catch. Unglamorous, compounding, and load-bearing for operating rhythms.

Where TrueFoundry fits

Its risks are the quiet ones. It fails silently: nobody watches a 6 a.m. cron, and provider outages arrive on their own schedule. It drifts silently: the rolling baseline moves. And it rots silently: a hardcoded model ID in a nightly job is a dependency with a vendor-controlled expiry date, retired on the provider's deprecation calendar, not yours. One distinction governs the resilience design: scheduled synchronous calls and asynchronous batch jobs are different problems. For synchronous scheduled calls, a virtual model gives the job a stable logical name with retries, health-aware routing, and fallback across configured targets — so it survives model retirements without an edit and provider outages without a gap, the engineering our failover and load-balancing guide covers end to end. TrueFoundry's Batch API does not support virtual models: batch jobs run asynchronously on a single provider, must target a concrete catalog model, and need job-level monitoring, retry, or resubmission logic instead. On observation, be precise about what's documented: the Metrics Dashboard supports monitoring the job's cost, failure rate, latency, and routing behavior, and budget policies can send spend-threshold milestone alerts to email or Slack — generic job-failure alerting is the domain of whatever external monitoring you attach to the exported telemetry, not a native dashboard feature. Either way, "it ran, on time, correctly" should be a monitored claim rather than an assumed one.

The Six at a Glance

Six agent archetypes, their operating shapes, principal risks, and applicable governance controls.

The Fourth Question: One Plane, Six Configurations

The column's three diagnostic questions — trigger or question, path known or discovered, where judgment stays — sort a problem into an archetype. The fourth sorts the archetype into an operation: whichever you just named, what plane will its calls cross? The arithmetic makes it urgent. Real enterprises run several archetypes at once — the column presents enterprise examples across all six — and six architectures with six bespoke stacks means six implementations of identity, budgets, guardrails, and logging, six places for the auditor to visit. One plane configured six ways inverts that — for the traffic that actually traverses it: the assistant's PII rails, the workflow's injection screens, the autonomous agent's budgets and tool scopes, the team's cross-provider routing, the HITL gates, and the scheduled job's fallbacks are all rules on the same infrastructure once the applications are integrated through the gateway, so the portfolio questions — which model and registered MCP calls did our agents make through the plane this month, what did each archetype cost when tagged through consistent request metadata, and which guardrails fired where — resolve to queries over one gateway telemetry substrate, for the traffic it observed. The Metrics Dashboard groups and filters by custom metadata keys sent in request headers; it does not infer which archetype a request belongs to, so the per-archetype view is a tagging convention applications adopt, not an automatic classification. Even the guardrails' own latency is first-class evidence: the documented Request Traces view records every guardrail's execution time, result, and scope per span.

Boundaries, Stated Plainly

Credit and context: the taxonomy, the three questions, and the deployment examples are the column's, summarized with attribution (the conflict-of-interest disclosure is in the source note at the top). The Deloitte, Databricks, and Moody's statistics are cited from their primary sources directly, with the scope each source states. The archetype-to-instrument mapping, the illustrations, and the summary table are TrueFoundry editorial framing not presented in the column.

Deployment and scope boundaries, stated plainly. "Plane" here means the governed traffic substrate, not the entirety of each business workflow. AI Gateway governs the model traffic routed through it; MCP Gateway governs the registered MCP calls routed through it; Agent Harness supplies a managed runtime — covering orchestration, state, approvals, and observability — for agents built on it (overview). External triggers, cron schedulers, inbox listeners, workflow engines, business databases, and review interfaces sit outside that plane, and self-hosted or third-party applications receive governance only for the traffic that actually traverses the gateway and its configured hooks — TrueFoundry's own traffic-governance guide documents which categories of traffic can and cannot be routed through it. Deployment mode also affects guardrail availability: the TrueFoundry-managed PII/PHI Detection, Prompt Injection, and Content Moderation built-ins are documented only for the TrueFoundry-hosted AI Gateway, and self-hosted and hybrid deployments must configure supported external-provider or custom alternatives (guardrails docs); SQL Sanitizer, Code Safety Linter, Cedar, and OPA do not carry that restriction. Output guardrails apply to non-streaming responses; request bodies are stored subject to logging configuration while trace metadata is always recorded; the Batch API takes concrete model targets. Two further limits of the companion analysis: archetypes hybridize — a triggered workflow that escalates to a HITL approval is two of our sections in one system, which the shared plane handles but clean taxonomy lines understate — and no plane chooses the archetype for you: naming the problem's shape before scoping the deployment remains a human judgment infrastructure can evidence but never supply. Within those boundaries, the claim stands: whichever of the six you choose, and however many you run, the same control-plane vocabulary — identity, budgets, guardrails, audit evidence — applies to the traffic on the plane, with policies tailored to each archetype and the results visible in one place.

References

• Anchor — Bernard Aceituno, "The 6 kinds of AI agent architectures," CIO.com, July 20, 2026 (the six archetypes, deployment examples, and diagnostic questions): cio.com.
• Primary sources for statistics — Deloitte, The State of AI in the Enterprise (38% report enhanced client/customer relationships as an achieved benefit); Databricks, State of AI Agents (multi-agent usage up 327% in less than four months, across 20,000+ organizations on the Data Intelligence Platform); Moody's, Human in the loop study (42% of 600 surveyed risk and compliance professionals say human oversight is mandatory).
• TrueFoundry documentation — guardrails overview (hooks, execution model, enforcement strategies, built-in catalog; official flow diagram and traces image); AI Gateway introduction; MCP Gateway overview (official architecture diagram); MCP authentication & security; access control; budgets; rate limiting; virtual models; Batch API; logging configuration; Agent Harness; Human in the Loop; agent identity and governance; governing traffic through the gateway; Metrics Dashboard (official image).
• This blog — prompt-injection defense at the gateway; PII redaction: gateway vs application; semantic caching; multi-agent A2A governance; TBAC: task-based access control; multi-provider failover and load balancing; real-time cost attribution; what is an Agent Harness?.

One direct quotation under fifteen words is used from the CIO.com column, attributed inline; all other content from the source is paraphrased with attribution. Third-party statistics are cited from their primary sources (Deloitte, Databricks, Moody's) with each source's stated scope. The archetype-to-instrument mapping, summary table, and six original illustrations are TrueFoundry editorial material; the four product images are TrueFoundry's own documentation assets, reproduced with attribution. No endorsement of TrueFoundry by CIO.com or the column's author is stated or implied.

‍