The AI Agents Stack in 2026: What Every Architect Needs to Know
This post was drafted with AI assistance and will be reviewed and published under a human byline.
Everyone is building AI agents in 2026. Not prototypes — production systems handling real customer workflows, financial operations, and infrastructure decisions. The framing has shifted from "can we build this?" to "how do we architect this so it doesn't fall apart at scale?"
The answer requires understanding the full agent stack. Not just the LLM at the top, but every layer underneath it: how memory persists between runs, how tools are discovered and called safely, how data flows in from the real world, and where humans stay in the loop.
This is that breakdown — grounded in what actually runs in production on SchemaBounce ADL, not a theoretical model.
The 6-Layer Agent Stack
┌─────────────────────────────────────────┐
│ Layer 6: Human-in-the-Loop │ Approval gates, escalation, oversight
├─────────────────────────────────────────┤
│ Layer 5: Pipelines & CDC │ Real-world data ingestion, event triggers
├─────────────────────────────────────────┤
│ Layer 4: Tools & MCP │ External capabilities, API calls, actions
├─────────────────────────────────────────┤
│ Layer 3: Memory & ADL │ Persistent state, knowledge graph, decay
├─────────────────────────────────────────┤
│ Layer 2: Orchestration │ Routing, multi-agent coordination, workflows
├─────────────────────────────────────────┤
│ Layer 1: LLM │ Reasoning, generation, tool selection
└─────────────────────────────────────────┘
Each layer has a distinct job. Conflating them — or skipping one — is where most production agent failures originate.
Layer 1: LLM — Reasoning, Not Storage
The LLM is the reasoning engine. It selects tools, interprets results, and generates outputs. What it is not is a memory system, a database, or a source of truth.
The most common architectural mistake in 2025 was treating the context window as memory. It isn't. Context is ephemeral, expensive, and has a hard ceiling. Every token you spend reloading background knowledge is a token not spent on the actual task.
In production, the LLM layer should receive:
- A focused system prompt (role, constraints, current task)
- Retrieved context from Layer 3 (memory), not the raw history
- Tool definitions scoped to what the agent actually needs this run
Model selection matters here. Not every agent needs the most capable model. Routing classification tasks to a smaller, faster model and reserving frontier models for complex reasoning is a real cost lever — agents running at scale can spend 80% of their inference budget on routine work that a smaller model handles equally well.
Layer 2: Orchestration — Routing and Coordination
Orchestration is the layer that decides: which agent handles this task, in what order, and with what handoffs?
In single-agent systems this is trivial. In multi-agent systems — where a team lead routes work to specialists, specialists spawn sub-agents, and results flow back up — orchestration becomes the architectural backbone.
Hub-and-Spoke Routing
SchemaBounce ADL uses a hub-and-spoke model for inter-agent communication. When agents in the same team but different domains need to communicate, messages route through the team lead (the hub) by default. This isn't bureaucracy — it's auditability and blast-radius control. The team lead can inspect, redirect, or halt messages before they reach a specialist.
Marketing Agent → [team lead hub] → SEO Agent
→ Blog Writer Agent
→ Social Media Agent
Direct peer-to-peer communication (bypassing the hub) is possible but audit-logged and requires an explicit reason. Reserve it for time-critical alerts where hub latency is unacceptable.
Workflow Automation
For deterministic, repeatable multi-step work, hardcoded agent-to-agent messaging is the wrong tool. Workflows (modeled as node/edge graphs with trigger, condition, delay, and agent_action nodes) encode the orchestration logic durably. They survive restarts, can be paused and inspected, and produce execution logs per step.
[CDC Trigger: new_deal created]
↓
[Condition: deal.value > $50,000]
↓ yes
[Agent Action: notify account-executive]
↓
[Delay: 24 hours]
↓
[Agent Action: run enrichment pipeline]
The rule of thumb: if you find yourself writing the same routing logic in agent prompts across multiple runs, that logic belongs in a workflow.
Layer 3: Memory & ADL — The Most Underbuilt Layer
Memory is where most agent stacks are underbuilt in 2026. Teams reach for bolt-on libraries, hit structural limits, and refactor. The core problem is that memory isn't one thing — it's at least four distinct concerns:
- Structured entity records — data with a schema (contacts, deals, findings, tasks)
- Unstructured knowledge — observations, preferences, learned facts (text, searchable by meaning)
- Knowledge graph — relationships between entities (WORKS_AT, OWNS, TRIGGERED_BY)
- Memory lifecycle — decay, expiry, namespace isolation
A production memory layer needs all four. ADL handles them as a unified substrate.
Structured Records
adl_write_record(
entity_type="contacts",
entity_id="contact_001",
data={"name": "Alex Chen", "plan": "enterprise", "churned": False}
)
Entity types have schemas. Writes are validated. Records are queryable by field values, not just by ID.
Unstructured Memory with Decay
adl_add_memory(
content="Customer prefers async communication, no calls before 10am",
namespace="customer_prefs",
decay_class="durable", # persists until confidence decays
taint="normal"
)
Decay classes enforce lifecycle automatically:
| Class | Lifetime |
|---|---|
ephemeral | 1 day — per-run scratch notes |
working | 7 days — in-progress task context |
durable | Persistent, 0.9x confidence per 30 days idle |
No TTL cron jobs. No stale facts silently poisoning retrieval.
Knowledge Graph
# Traverse relationships
adl_search_graph(
entity_type="contacts",
entity_id="contact_001",
relationship="WORKS_AT",
direction="outgoing"
)
# Multi-hop: find everyone connected to a company 2 hops out
adl_query_neighbors(
entity_type="companies",
entity_id="company_042",
depth=2,
relationship=None,
max_nodes=50
)
The graph layer is what enables impact analysis ("if this pipeline goes down, which agents are affected?"), dependency mapping, and relationship-aware retrieval that flat vector search can't provide.
Namespace Isolation
northstar:* → read-only, owner-managed truth
domain:{name}:* → domain-scoped
shared:* → cross-agent readable
private namespaces → agent-private
Two agents writing to the same namespace don't collide. Isolation is enforced at the platform, not by naming convention.
Layer 4: Tools & MCP — Capabilities Without Chaos
The Model Context Protocol (MCP) is the emerging standard for connecting agents to external capabilities: APIs, databases, SaaS connectors, internal services. An MCP server exposes a set of typed tools; an agent is granted access to specific servers; the platform mediates every call.
Why MCP Over Direct API Calls
Direct API calls from agent code work until they don't:
- Credentials scattered across agent prompts
- No audit log of what external actions were taken
- No approval gate for destructive operations
- No visibility into which agents are calling which services
MCP centralizes this. Credentials are stored once in the platform. Tool calls are logged. Effectful operations (POST/PUT/DELETE to external APIs) can be gated behind human approval.
Network Scope
Not all MCP servers are equal. ADL tracks networkScope per server:
| Scope | Meaning |
|---|---|
open | Public internet endpoints |
llm-only | LLM inference services |
private-network | VPN-tunneled, reaches internal infrastructure |
restricted | Limited domain allowlist |
An agent calling an internal PostgreSQL replica via MCP uses a private-network scoped server over a VPN tunnel — the agent never sees credentials or connection strings.
Tool Budget Discipline
Tools cost tokens and money. The right architecture limits the tool surface exposed to each agent to what it actually needs. An agent that can see 200 tool definitions spends more tokens on tool selection than one scoped to 15. Grant tools at the agent level, not the workspace level.
Layer 5: Pipelines & CDC — The Real World Feeds the Agent
Agents that only respond to human chat messages are a small fraction of the production use case. Most valuable agent work is event-driven: a record changes in a database, a payment comes through, a customer churns, a deploy fails.
Change Data Capture (CDC) is the mechanism that connects the real world to the agent stack.
CDC to Agent Trigger Pattern
PostgreSQL (orders table)
↓ CDC connector
SchemaBounce pipeline route
↓ entity type: orders
ADL record created/updated
↓ entity trigger
Agent invoked with CDC payload
The agent wakes up because something happened in the real world — not because a human typed a message. This is the pattern behind automated enrichment, anomaly detection, proactive customer outreach, and a dozen other production use cases.
Pipeline Reliability
A pipeline is only as good as its sink reliability. Production pipelines need:
- DLQ (Dead Letter Queue) — failed events land here, not lost
- Retry policy — transient failures retried with backoff
- Monitoring — throughput, failure rate, latency tracked per route
ADL exposes per-route metrics (event count, failure rate, avg latency) so agents can self-monitor pipeline health and alert when something degrades.
Layer 6: Human-in-the-Loop — The Layer Nobody Designs Until It's Too Late
Human oversight isn't a feature you add at the end. It's an architectural layer that determines what the agent can do autonomously versus what requires approval.
The failure mode is binary thinking: either the agent is fully autonomous or it asks for confirmation constantly. Neither works in production. The right model is graduated authority:
Low blast radius + reversible → agent acts autonomously
High blast radius + reversible → agent logs, notifies, acts
High blast radius + irreversible → agent proposes, human approves
External state changes → always gated (POST/PUT/DELETE)
Approval Gate Architecture
In ADL, effectful external tool calls (sending emails, posting to APIs, publishing content, charging cards) are captured as pending actions in the human Inbox before execution. The agent makes the call; the platform intercepts it; the human approves or rejects it in the Actions queue.
This is not a chat-reply approval. "Go ahead" in a message grants nothing. The approval happens in the structured Inbox UI, with the exact arguments visible, and is audit-logged.
Escalation Paths
Agents should have defined escalation triggers:
- Decision exceeds documented authority
- North Star contradiction detected
- Critical alert unacknowledged for 2+ runs
- Contradictory data from multiple sources
Escalation routes to a human position in the org chart (adl_request_escalation), checkpoints the execution, and resumes automatically when the human responds. The agent doesn't spin, retry endlessly, or hallucinate a resolution — it stops and waits.
Putting It Together: A Production Agent Architecture
Here's what the full stack looks like for a real use case — automated deal enrichment when a new CRM contact is created:
[CDC: contact created in HubSpot]
↓ pipeline route → ADL entity record
[Trigger: entity_type=contacts, event=created]
↓
[Enrichment Agent wakes up]
Layer 1: LLM reasons about enrichment strategy
Layer 3: Checks memory for existing company context
Layer 4: Calls Clearbit MCP tool for firmographic data
Layer 3: Writes enriched data back to entity record
Layer 2: Routes finding to account-executive agent
↓
[Account Executive Agent]
Layer 3: Retrieves deal history from knowledge graph
Layer 6: Proposes outreach email → Inbox approval gate
↓
[Human approves email]
Layer 4: Email sent via SendGrid MCP tool
Layer 3: Outreach logged to entity record
Every layer has a job. None of them bleed into each other's responsibilities.
The Architect's Checklist
Before shipping a production agent system, verify each layer:
- LLM: Model sized correctly for task complexity? Context carrying retrieved facts, not raw history?
- Orchestration: Multi-agent routing explicit? Deterministic workflows for repeatable flows?
- Memory: Decay classes set correctly? Namespace isolation enforced? Knowledge graph modeled?
- Tools: MCP servers scoped to agent needs? Credentials in platform, not prompts?
- Pipelines: CDC routes have DLQ and retry policy? Failure rate monitored?
- Human-in-the-loop: Approval gates on all external writes? Escalation paths defined?
If any layer is "we'll add that later" — it won't be later. It'll be a production incident.
What's Changed in 2026
The shift that makes this moment different from 2024's agent hype:
- MCP is the standard — not a nice-to-have. Agents without standardized tool interfaces are integration debt waiting to happen.
- Memory is infrastructure — bolt-on libraries work for demos. Production needs decay, isolation, and graph from day one.
- CDC unlocks event-driven agents — the most valuable agent work happens in response to real-world events, not chat messages.
- Human-in-the-loop is a design constraint — not an afterthought. Systems that can't route to human judgment under uncertainty are liability, not capability.
The teams winning with AI agents in 2026 aren't the ones with the best prompts. They're the ones who treated the full stack as a serious engineering problem.
~1,600 words | Category: Research | Section: SchemaBounce | Target: AI agent architecture stack 2026