Applied Materials / AI Control Tower Architecture

Agents are cheap. Trust is expensive.

Anyone can stand up a mediocre agent in an afternoon. The control plane (identity, policy, approvals, audit) is what augments them and makes a fleet of them safe to trust with real work, which is also the part worth building right.

Click any layer to see what building it actually means.
Hit Trace a request to watch one move through the tower.

— / 8
idleReady. Trace a request to watch it move through the tower, or click any layer to expand it.
a request enters ↓
01 Control Plane · the tower itself the shell that wraps everything below
Identity & RBAC
Humans and agents get roles, both kept to least-privilege on data and actions.
+
Policy engine
Policy as code. It decides which tools, which model, which data class, and whether sign-off is needed.
+
Approval / HITL
High-risk actions stop and wait on role-based approval. A checker, then an approver.
+
Audit log & compliance
Every action logged to a principal, tamper-evident, ready for SOX-style review.
+
02Agent Runtime · the workers (Hermes)agentic fleet composition
A pool of Hermes agents, each scoped to one role or domain. The control plane decides what tools they get; an agent doesn't grant itself anything.
Role-scoped agent pool
Planning-health, exception-handling, forecasting. Each owns one bounded domain.
Per-agent: orchestrator + skills + memory
Skills are codified, versioned SOPs. Memory is scoped to the role, and the orchestrator runs the loop.
Sandboxed execution
Workspaces are isolated and tool access comes from policy, so one bad agent can't reach far.
tap
governs · constrains · enforces
03Knowledge & Memorycontext layer
Where the tower keeps what it knows, locked down so no agent can reach past its role.
Per-agent persistent memory
Long-term, Honcho-style context, isolated per tenant and locked to one role.
Shared org skill / knowledge library
Shared SOPs as versioned, reviewed skills pushed out to the whole fleet.
Data-classification tags
Labels that tell policy and routing who can see the data, down to which model.
tap
reads / writes · scoped
04Inference Routingmodel-agnostic
No single vendor lock. Policy routes each task by data sensitivity: sensitive work stays on AMAT's own hardware, everything else may reach a frontier model that keeps nothing. Which brain sees what is a permission, not a choice.
Frontier via ZDR
Claude or GPT with zero data retention, for complex reasoning that isn't sensitive.
Self-hosted open weights
Kimi K3 and deepseek-v4-flash on AMAT hardware, for work that can't leave the building.
Eval gates
No model gets to touch anything consequential until it passes the eval harness.
tap
policy-driven routing
05Integration Layerenterprise connectors
Where read and write rights are actually enforced, not inside the agent.
SAP · Databricks · ServiceNow · internal APIs
Planning tables, analytics, ITSM, and internal systems behind one surface with enforced entitlements.
tap
06Observability & Ops
The dashboard. What makes a VP willing to bet on this: a trail of evidence, not a black box.
Tracing · logging · cost metering
Centralized per agent and per team, with cost attribution and full action traces.
Eval harness · SLOs · incident response
Reliability targets that gate what gets promoted and drive how incidents get handled.
watches every layer
07 Deployment · the substrate cloud / hybrid · AMAT infra
Everything above runs on AMAT infrastructure, not on a laptop. Fleet management, config as code, secrets in a vault. Operated like real enterprise software.
The point of all this: the models and the runtime are solved problems via agentic frameworks and harnesses like Hermes, Claude Code, etc. What we actually need to build is the trust layer around the fleet: identity, policy, approvals, audit.