Architecture
How it comes together, end to end.
One reference implementation, from the data to the agent to the security operations center, with orchestration holding it together.
The full picture
Three disciplines, one system.
Most programs fund AI, data and security separately. They only work when designed together, and held together by orchestration and an operating model: the process, control plane, release gates and accountable owners that run them.
One system, several views
This diagram is the main view. The other pictures on this site and in the papers describe the same system for a different purpose. None is a separate framework to buy or implement.
The architecture
The agentic enterprise, layer by layer.
People and agents work in redesigned processes on top of five layers. Security frames every layer, and orchestration and operation run beside them. The names match the capability map and the product layers below.
Security, across every layer · identity for people and agents, labels, enforcement at the data, monitoring
People and agents
Redesigned business processes. Agents act within the authority of the person they serve, and a person stays in the loop for consequential actions.
AI and experience
ReasoningToolsMemoryOrchestrationGuardrailsEvaluationCatalogObservability
Foundation modelsAdapted modelsReportingSelf-service
Access and interfaces
Data APIsAI gatewayAgent toolsRetrievalCommand path for writes
Meaning and knowledge
Semantic layerOntology and knowledge graphMetadataMaster dataSearch
Context for the answer, never a grant of access.
Data platform
Data productsDomain platformsPipelinesStorageVector storage
Access is enforced here: masking and row access, every time.
Sources
Operational applicationsDocumentsExternal data
Orchestration and operation
- Release gates and evaluation
- DataOps, DevOps, model operations
- Quality and lineage
- FinOps: cost per completed task
- Request evidence: who asked, which versions, which policy decision, what happened
Operating model, underneath
Accountable owners, decision rights, skills and funding for running, not only building.
Vendor neutral. Three requirements anchor this design: identity for every agent, meaning separate from access authority, and evidence that lets an authorized reviewer reconstruct a request.
The capability map
63 capabilities, mapped to the same layers.
The ownership view of the same system shown at the top of this page.
Ownership gaps stall more programs than technology does. The worksheet lists every capability with a one-line description and blank columns for current owner, accountable owner, decision rights and gaps. It assigns no owners: the right owner depends on your organization.
AI and experience
What the business uses · 13
Reporting and analytics, Self-service exploration, Data-driven applications, Data science sandbox, Prompt and instruction library, Foundation models, Model adaptation, Agents, Agent orchestration, Agent memory, Agent evaluation, Agent catalog, Agent observability
Access and interfaces
The nervous system · 6
Data APIs, Virtualization and federation, AI gateway, Retrieval services, Agent tool interfaces, Command path for writes
Meaning and knowledge
The brain · 8
Metadata, Semantic layer, Ontology and knowledge graph, Information architecture, Master and reference data, Chunking and embeddings, Data marketplace and search, AI asset search
Data platform
The brain’s data products · 12
Batch integration, Streaming and messaging, Pipeline orchestration, Data pipelines, Schema detection, Data modeling, Data preparation, Data storage, Vector storage, Cloud hosting, Containers, Accelerated compute
Sources
Systems of record · 3
Purpose-built databases, Operational applications, External and web data
Security, across every layer
The immune system · 7
Identity and access for people, Identity for agents, Single sign-on and zero trust, Classification and labels, Data protection, Monitoring and logging, Threat detection and response
Orchestration and operation, across every layer
The body and control plane · 10
Data quality, Lineage, Data architecture standards, Responsible AI, DataOps, DevOps, Model and AI operations, FinOps, Release gates, Request evidence
Operating model
Underneath all four · 4
Data and AI strategy, Upskilling and training, Research and talent programs, External workforce
The layers
One example combination of products.
AI and experience
Assistants and agents, the model platform, and tools exposed through the Model Context Protocol
Snowflake CortexAmazon BedrockMCP
Access and interfaces
Governed APIs and narrow agent tools
Hasura DDNAWS API Gateway
Meaning and knowledge
Ontology and enterprise catalog, semantic views, and tested transformations
data.world (ServiceNow)Snowflake semantic viewsdbt
Data platform
Warehouse and open tables, with tag-based masking and row access policies (tag-based row access in preview)
Snowflake HorizonApache Iceberg
Security, across every layer
Identity for people and agents, classification, data loss prevention, and the security operations center
OktaMicrosoft Entra Agent IDCyeraMicrosoft PurviewSIEM and SOAR
Orchestration and operation, across every layer
Pipelines, release gates, tracing, and change and incident management
Apache AirflowCI/CDOpenTelemetryServiceNow
Examples, not endorsements. The architecture depends on the contracts between layers, not on these products. A substitute must keep the same contracts and controls. Richard has worked closely with several vendors named here as a customer and practitioner. No vendor reviewed or paid for this content.
Orchestration
The process and technology that hold it together.
Control plane
One record of what was approved: versions, policies, owners and the conditions of each release.
Release pipeline
Every change, to data, model, prompt, tool or policy, passes the same gates.
Policy propagation
Each rule declares its source, targets, latency, drift check, rollback and owner.
Observability
One request ID from the user through every agent, tool and source, into the SOC.
Runbooks and recovery
Tested restriction, rollback and revocation, run by your own team.
Operating model
The data group owns meaning, the cyber group owns labels and enforcement rules, the AI owner owns the capability, and the business owns the outcome.
Use case · synthetic reference example
A claims assistant, traced end to end.
A claims examiner asks who is connected to an assigned case, its status, and which procedure applies. This read-only architecture pattern supports the synthetic claims preparation guide: team A, group disability, region 2. Events within the assigned case are included; prior-claims history, internal notes, decisions, payments and customer contact are excluded from its narrowed release.
- 01
The examiner signs in through single sign-on. The assistant runs under its own agent identity, registered to the claims owner, with a defined role.
- 02
The request carries a short-lived token scoped to this examiner and this agent: only what both are allowed.
- 03
A fixed sequence resolves claim status, the related parties and the applicable procedure. Cross-case search and note tools are unavailable in the narrowed runtime.
- 04
Claim status comes from a certified data product through a narrow API. Tag-based masking hides fields this examiner may not see.
- 05
Procedure documents were classified and labeled by the DSPM tool. Retrieval returns only documents this examiner may read, for this tenant.
- 06
One document contains hidden instructions to email the file outside the company. The agent has no tool that can send externally; the attempt is refused and flagged.
- 07
The answer separates facts from interpretation, cites its sources and flags an unresolved party match for the examiner.
- 08
Every step is traced with the agent’s identity, the user, the tools, the data labels and each policy decision, and streamed to the SOC.
- 09
Days later, the agent starts requesting claims outside the examiner’s assigned book. Each call is denied; the repeated denials alert the SOC, and a playbook suspends the agent identity and opens an incident for the owner.
- 10
When an examiner leaves, the identity provider removes access, and the revocation test shows the assistant stops using it within the tested window.
- 11
The trace, the refused instruction, the incident and the revocation test become release evidence. The owner decides whether to restore the agent, and on what conditions.
All records and outcomes here are synthetic. The steps illustrate architecture and incident handling, not a client deployment or an executed test. The versioned workflow record and completed release decision define the worked guide’s accepted scope and held dependencies.
Total cost of ownership
The business case approves the tip. Ownership pays the rest, every year.
Build, licenses, vendor fees, integration and pilot compute are visible at approval. Twelve recurring costs arrive after it, and the architecture above is what keeps them in bounds.
Go deeper
The full reference implementation.
The paper sets out the architecture diagrams and product detail layer by layer, the security model for agents and the security operations center, and two use cases traced end to end: anti-money-laundering alert investigation at a bank, and this claims workflow at an insurer. Twenty-two pages, free, no form.
Agentic delivery
Faster code still needs authority, independent checks and learning.
Coding agents can draft, test and execute changes within bounded tools and identities. The loop starts from governed intent, validates independently of the agent that made the change, releases under named authority and feeds what operation reveals back into intent.
Next step
See how this would fit your stack.
A free sixty-minute session with Richard to examine one workflow, what is blocking it and whether there is a useful next step.