11
Observability
Audit · tracing · evaluation · outcomes
Know what happened, measure quality and reconstruct material actions.
Enterprise AI architecture
Enterprise AI is an architecture problem before it is a model problem.
A production AI system is not one model endpoint. It is the path between business systems, company data, human and machine identity, retrieval, models, agents, tools, policy, authority and evidence.
TEMRIK enterprise AI architecture is designed around that path: a control layer between the systems that hold company truth and the AI that can interpret, recommend or act on it.
Systems · data · identity · retrieval · models · agents · tools · policy · authority · evidence
REFERENCE ARCHITECTURECONFIGURABLE
The controlled path
01
Company systems + data
Source of truth
02
Identity + access
Who may see what
03
Retrieval + context
What the AI receives
04
Models + agents + tools
Reasoning and capability
05
Policy + human authority
What may happen
06
Audit + evaluation
What can be proven
This is a reference architecture, not a claim that every customer should deploy every layer as a separate service.
First principle
Do not connect the model directly to the company.
Put an architecture between them. The model should not inherit broad database access, application credentials, policy authority or unrestricted action rights simply because it can reason well.
The surrounding system should identify the actor, classify the request, retrieve authorised context, select the model, expose only approved tools, evaluate policy, require human approval where necessary and preserve the operational evidence afterwards.
Reference architecture
Interactive explorer
Inspect the enterprise AI stack layer by layer.
Each layer has a purpose, a common failure mode and dependencies above and below it. TEMRIK sits across the control boundary rather than replacing the systems around it.
Selected control
Business systems
The systems where work and records originate.
Purpose
Provide systems of record and operational capabilities.
Common failure
Direct model connections can create uncontrolled point integrations.
TEMRIK role
Integration through controlled interfaces.
Upstream dependency
Outside the AI stack
Downstream dependency
Data
Eleven layers from systems of record to controlled action.
These layers are logical responsibilities. A real implementation may combine several in one platform, distribute them across clouds, or keep selected services inside a customer environment.
REFERENCE ARCHITECTUREPROVIDER DEPENDENT
10
Human control
Approval · exception · escalation
Keep consequential authority with named people and explicit decision rights.
09
Policy
Tool rights · action rights · risk rules
Evaluate what may happen outside the model, not only inside a prompt.
08
Tools
MCP · APIs · systems
Expose bounded capabilities rather than broad ambient access.
07
Agents
Planning · state · tool use · delegation
Give machine actors defined purpose, identity, scope and stop conditions.
06
Models
Routing · provider · private inference
Select compute by workload, data class, region, capability, cost and latency.
05
Retrieval
Permission-aware search · context assembly
Retrieve only relevant evidence the requesting identity is allowed to use.
04
Access + classification
Tenant · RBAC · sensitivity · boundary
Classify the request, actor and information before model context is assembled.
03
Identity
Users · agents · service identities
Know which human or machine actor is operating and under whose authority.
02
Data
Structured · unstructured · knowledge · records
Keep durable company knowledge and source records outside any one model.
01
Business systems
CRM · ERP · finance · documents · communications · projects
Treat systems of record as the operational foundation, not as a prompt attachment.
Systems + data
Start with systems of record, not a model catalogue.
CRM, ERP, finance, document, project and communication platforms already contain the organisation's transactions and evidence. The architecture should preserve those systems as authoritative sources rather than copying the business into a provider-specific prompt estate.
Structured data
Customers, jobs, transactions, ledgers, schedules and asset records.
Unstructured data
Contracts, correspondence, reports, drawings, PDFs, images and notes.
Knowledge
Policies, procedures, playbooks, standards, approved interpretations and domain context.
Operational state
Tasks, approvals, exceptions, workflow status and decision history.
Identity + access
Every request should arrive with an identity and a boundary.
Enterprise AI introduces machine actors alongside people. Users, agents and service identities need explicit ownership, permissions and delegation paths before company context is assembled.
Role-based access can be part of the design, but higher-sensitivity environments may also use attributes, resource policies, tenant boundaries, network controls and workload identity.
Human user
AI agent
Service identity
Tenant
Role / attributes
Data class
Delegation
Access decision before context assembly
The model should receive the context the authorised actor needs for the specific task, not whatever the integration can technically reach.
Retrieval + context
Retrieval is an access-control problem as well as a relevance problem.
Semantic similarity alone is not enough. Context assembly should respect tenant, identity, sensitivity, source authority, recency and workflow purpose before any retrieved content becomes model input.
Gate 1
Request
Gate 2
Identity
Gate 3
Permission
Gate 4
Data class
Permission-aware retrieval
Search approved sources → rank relevant evidence → preserve citations / provenance → assemble minimum useful context.
Models, agents + tools
Intelligence, agency and capability are different architectural concerns.
The model supplies reasoning capability. The agent adds a loop, state and discretion over next steps. Tools let the system touch the outside world. Each concern should have its own boundary.
OpenAI documents runtimes in which application code can control deployment, storage, approvals and tool integration; Anthropic distinguishes workflows from agents and recommends matching complexity to business value.
Reasoning / generation
Model
Selected by workload policy. Replaceable compute rather than the business operating layer.
Plan / state / delegation
Agent
A machine actor with purpose, identity, limits, stop conditions and an owner.
Read / calculate / communicate / act
Tool
A bounded capability exposed through APIs, MCP or other controlled interfaces.
Policy + human authority
The model can propose. The architecture decides whether anything is allowed to happen.
Policy should evaluate tool rights, action rights, risk class, evidence requirements, financial or contractual thresholds, delegation limits and approval rules outside the model's generated text.
OWASP's Agent Control Standard is directionally important because it treats runtime transparency and policy enforcement as platform concerns rather than asking the agent to police itself.
Decision path
01Proposed actionAgent requests a specific tool or business action.
02Policy evaluationIdentity, data class, authority, evidence and risk are checked.
03Control resultAllow, restrict, request information, escalate or deny.
04Human authorityNamed approver decides where the action exceeds the machine boundary.
05Release + evidenceOnly the authorised action is released and recorded.
Observability + evidence
Production AI needs an evidence plane.
Architecture should preserve enough operational evidence to understand which actor initiated the work, what sources were used, which model and tools participated, what policy decided, who approved the release and what outcome followed.
This does not require exposing private chain-of-thought. The useful enterprise record is the sequence of material system events and decisions.
Logging
Discrete events and structured records.
Tracing
The path across models, tools, agents and services.
Audit
Evidence of identity, policy, approvals and released actions.
Evaluation
Quality, safety, cost, latency and policy performance over time.
Operating model
Centralised and federated architectures solve different organisational problems.
There is no universal topology. Organisation size, regulatory exposure, cloud strategy, data ownership and platform maturity determine how responsibilities should be distributed.
Centralised
A shared AI platform team owns gateways, policy, model access, observability and common services.
Strength
Consistency, reuse and stronger common controls.
Trade-off
Can become a delivery bottleneck if every domain change requires the central team.
Federated
Business domains own more of their agents, retrieval and workflows under enterprise standards.
Strength
Faster domain iteration and clearer local ownership.
Trade-off
Requires mature identity, policy, platform contracts and observability to avoid fragmentation.
Hybrid
Shared control services are centralised while domain teams own bounded workflow logic and data products.
Strength
A practical balance for many larger organisations.
Trade-off
Needs explicit interfaces between platform authority and domain authority.
Deployment boundaries
The control plane, data plane and inference plane do not have to live in the same place.
A controlled architecture can mix managed SaaS, customer cloud services, private networking, provider-hosted models and specialised confidential-compute paths. The correct boundary depends on the workload.
SaaS control plane
CONFIGURABLEThe control layer is delivered as a managed service while customer systems remain connected through scoped integrations.
- Fastest operating model
- Central policy administration
- Requires clear tenant and integration boundaries
Customer cloud boundary
ARCHITECTURE DIRECTIONSelected data, retrieval, execution or gateway components operate inside a customer-controlled cloud environment.
- Greater infrastructure control
- Useful for stricter network requirements
- Operational responsibility increases
Private model endpoint
PROVIDER DEPENDENTSensitive workloads route to a private, customer-hosted or provider-isolated inference endpoint where supported.
- Workload-specific model boundary
- Can reduce provider exposure
- Availability varies by provider and region
Confidential compute path
ARCHITECTURE DIRECTIONHardware-backed confidential computing can protect selected workloads while data is actively being processed.
- Data-in-use protection
- Attestation can strengthen trust
- Not universal across models or accelerators
Residency + integration
Geography is a routing input, not a footnote.
Data residency, model availability, retention controls, private networking and confidential-compute options vary by provider and region. Architecture should express those constraints before a request is routed.
PROVIDER DEPENDENT
API integration
Direct service contracts with explicit authentication, schemas, scopes and error handling.
MCP integration
Standardised tool/resource connectivity where appropriate, with separate policy and trust evaluation.
Event integration
Queues, webhooks and event streams for asynchronous, durable workflows.
Human workflow
Tasks, approvals and escalations integrated into the systems people already use.
Failure boundaries
Good architecture assumes components will fail independently.
Models can degrade, APIs can timeout, retrieval can miss evidence and approvals can stall. The system should know which failures permit retry, which permit fallback and which must stop the workflow.
Model failure
Timeout, malformed output or degraded capability
Fail closed for consequential actions; retry or route only where policy allows.
Retrieval failure
Missing, stale or over-broad context
Surface evidence gaps instead of inventing certainty.
Tool failure
API unavailable, partial write or inconsistent external state
Use idempotency, confirmation and compensating workflows where appropriate.
Identity failure
Actor cannot be confidently authenticated or delegated
Do not expand permissions to keep the workflow moving.
Policy failure
Rule engine unavailable or decision is ambiguous
Default to restrict or escalate according to the workflow risk class.
Agent failure
Looping, unexpected delegation or goal drift
Apply iteration, cost, time, tool and authority ceilings outside the agent.
Human-control failure
Approver unavailable or escalation path unclear
Pause high-consequence release rather than silently bypassing authority.
Observability failure
Evidence trail cannot be completed
Treat loss of required audit evidence as an operational exception.
Architecture review
Review the path from data to action.
The architecture review should start with one real workflow and trace every trust boundary it crosses.
Which systems hold the source of truth?
Which identities can request the workflow?
How is data classified before retrieval?
How are permissions applied to search?
Which models may receive which data classes?
What tools can the agent invoke?
Which actions need human approval?
What happens when a dependency fails?
What evidence is retained?
Can the model or provider change without redesigning the workflow?
Research basis
A reference architecture should be grounded in current platform and risk-management guidance.
These are the primary sources used to shape this page. They describe different platforms and design philosophies; TEMRIK does not imply partnership with any provider and does not present one vendor architecture as universal.
NIST
AI Risk Management Framework
Govern, Map, Measure and Manage frame AI risk as a lifecycle and organisational discipline.
Primary sourceMicrosoft
Azure architecture pattern for AI workloads
A composable AI workload pattern covering application, data, orchestration, model and operational concerns.
Primary sourceAWS
Agentic AI architecture in the enterprise
A layered enterprise reference architecture with agents, model access, tools, knowledge bases and cross-layer controls.
Primary sourceGoogle Cloud
Generative AI security best practices
A typical enterprise generative-AI architecture with security controls around data, services and agent platforms.
Primary sourceOWASP
Agent Control Standard
Runtime transparency, inspectability, traceability and policy enforcement through controls outside the agent.
Primary sourceOpenAI
Agents architecture
Agent runtimes combine models, tools, state, orchestration and application-controlled integration choices.
Primary sourceAnthropic
Building Effective AI Agents
Architecture patterns for workflows, single agents and multi-agent systems with complexity matched to business value.
Primary sourceAWS
Agentic AI Lens design principles
Bounded agents, end-to-end observability, explicit contracts and proportionate human oversight.
Primary sourceRelated architecture
Agentic AI
How agents plan, use tools, maintain state and delegate inside bounded systems.
ExploreAI Security
How company data, model choice, least privilege and action boundaries are protected.
ExploreHuman Control
How consequential decisions remain subject to human authority and escalation.
ExploreHow TEMRIK works
How TEMRIK connects operating rules, systems, evidence and control around AI-assisted work.
ExploreFree field guide
27 Rules of Peace
Architecture is stronger when the rules of authority are clear before AI enters the workflow.
Use the free field guide to think through evidence, escalation, decision rights and the operating rules that sit around AI-assisted work.
Architecture before autonomy
Review your current AI architecture before you give AI more authority.
TEMRIK can help map one workflow across systems, data, identity, retrieval, models, agents, tools, policy, approval and audit—then identify where the control boundary should sit.
Reference architecture only. Deployment topology, data residency, confidential computing, model availability and private networking depend on customer requirements and selected providers.
AI can become more capable.The company does not have to give up control.