01
AI model
The underlying intelligence that interprets input and generates outputs. Models can change without redefining the business operating architecture.
AI operating system · enterprise control plane
AI needs an operating system around it.
The model is not the operating system. Organisations are assembling models, agents, SaaS systems, company data, workflows, tools, playbooks, approvals and human decision rights. The hard problem is coordinating them without surrendering organisational authority.
TEMRIK AI control plane is the architecture we are building around that complexity: a durable layer for identity, policy, orchestration, model choice, human control and evidence.
Company data · identity · policy · models · agents · tools · authority · audit
Reference architecture
Intelligence inside a controlled business system
- 01Business systemsCRM · ERP · finance · documents · communications · project systems
- 02Company dataRecords · knowledge · evidence · operating state
- 03IdentityTenant · user · agent · role · service identity
- 04Playbooks + policyRules · evidence requirements · exceptions · stop conditions
- 05TEMRIK control planeContext · permissions · orchestration · routing · policy evaluation
- 06Model routerCapability · data class · region · provider · cost · availability
- 07Agents + toolsSpecialists · workflows · MCP · APIs · business systems
- 08Dispatcher GateAllow · restrict · request information · escalate
- 09Human authorityNamed decision owner · review · approval · exception
- 10Auditable actionReleased operation · evidence · timestamp · outcome
“AI operating system” is commercial architecture language. TEMRIK is not claiming to be a literal operating-system kernel or a replacement for cloud, identity or database infrastructure.
The definition
What does an “AI operating system” actually mean?
It means the durable enterprise architecture that surrounds AI intelligence: the mechanisms that know who is acting, which company context may be used, what rules apply, which model is appropriate, what tools may be called, when a human must decide and what evidence remains afterwards.
The intelligence can change.The operating architecture should remain.
Seven different things
Stop using “AI” to describe the entire stack.
A model, an application, an agent and a control plane solve different problems. Clear architecture starts by naming the layers correctly.
02
AI application
A product experience that applies one or more models to a defined user need, often with its own interface, data connections and controls.
03
AI agent
A system in which a model can help decide the next step, select tools, retrieve context and pursue a goal over multiple interactions.
04
Workflow
An explicit sequence or graph of business steps, rules and handoffs. Workflows can contain agents without becoming fully agent-directed.
05
Orchestration
The coordination of models, agents, tools, state and workflow execution so the right capability is invoked at the right point.
06
Control plane
The policy and coordination layer that determines identity, context, permissions, routing, approvals, execution boundaries and evidence.
07
AI operating system
TEMRIK's commercial architecture term for the durable control environment around replaceable AI intelligence. It is not a literal operating-system kernel.
Reference architecture
Interactive explorer
Select a layer to inspect the control plane.
Explore how company data, identity, playbooks, models, agents, tools, human authority and audit fit together without turning the model into the operating system.
Selected control
Company data
The durable business records and evidence the AI works from.
What this layer does
Provides controlled business records, knowledge, evidence and operating state.
Why it exists
Company memory should remain durable even when models or providers change.
TEMRIK controls
Which workflow may retrieve which authorised sources and how that context is assembled.
Without it
Models can be given too much context or become tightly coupled to ad-hoc data access.
Adjacent layers
Identity · Context control · Playbooks
Put a control plane between business intent and machine action.
Kubernetes is a useful analogy, not a blueprint. Its control plane manages the desired state of a cluster while worker nodes execute workloads. An enterprise AI control plane similarly coordinates policy and execution around AI workloads—but the business problem is different and the architecture is not a direct technical equivalence.
See the official Kubernetes control-plane components.
1
Identity before intelligence
Resolve tenant, user, agent and role before retrieving context or exposing tools.
2
Policy outside the prompt
Business permissions should not depend only on model obedience. Enforce material boundaries in surrounding software and workflow controls.
3
Context by need
Retrieve the minimum relevant business evidence rather than handing an entire company knowledge base to every model call.
4
Models as replaceable compute
Select models for workload requirements while keeping company memory, rules and action authority in the surrounding architecture.
5
Actions through a gate
A generated result is not automatically an authorised external action. Consequential release can remain subject to explicit policy and human review.
6
Evidence after action
Record the operational facts needed to reconstruct what was requested, what was used, what was approved and what occurred.
Company data plane
The durable intelligence of the company should live outside the model.
Company records, policies, playbooks, permissions, workflow state and approved decisions are long-lived organisational assets. A foundation model is selected compute. The architecture should make it possible to change the model without rebuilding the company around it.
This principle extends the data-control approach described in TEMRIK AI Security.
Source systems
Keep CRM, ERP, finance, project and document systems as authoritative records where appropriate.
Knowledge
Assemble approved operational knowledge without assuming the model itself is the system of record.
Workflow state
Persist tasks, approvals, exceptions and outcomes outside transient model context.
Evidence
Retain the facts needed to support review, audit and future decisions.
Identity
Every request needs an actor and an authority boundary.
As AI systems create more machine actors, identity becomes part of the operating architecture—not a detail hidden inside a prompt. Human users, agents and service identities can require different credentials, roles, tool access, delegation and expiry.
Which organisation owns this request?
Is the actor a human, agent or service identity?
What role and delegated authority applies?
Which data classes may be retrieved?
Which tools are permitted?
What is the action ceiling?
Who owns escalation?
When does the authority expire?
Playbooks + tools
Playbooks
Encode how the work should be done.
A useful operating playbook can define purpose, trigger, inputs, required evidence, decision rules, exceptions, tools, stop conditions, approver and audit requirement. It gives an agent more than a persuasive prompt: it gives the workflow an explicit operating boundary.
See how TEMRIK frames agentic AI and the role of controlled workflows.
Tools
Capability is not permission.
An agent may technically be able to call an API, MCP server, database or SaaS action. That does not mean the business has authorised every operation. Tool definitions, credentials, scopes, policy checks and action gates should reflect what the actor is actually allowed to do.
The same distinction underpins TEMRIK human control: preparation is not permission.
Model routing
Choose the model for the workload. Do not redesign the business for the model.
Modern agent frameworks already treat models and providers as components inside a larger runtime. TEMRIK's architecture direction is to evaluate provider choice against policy, data class and task requirements rather than hard-code one model as the organisation's operating memory.
Routing policy checks
Task and capability
Tenant policy
Data classification
Region and residency
Security requirement
Tool support
Structured-output need
Latency
Budget
Provider availability
Provider availability, retention, region and security features remain deployment-specific. This page does not claim seamless hot-swapping across every provider.
Multi-agent coordination
More agents create a coordination problem, not just more intelligence.
Microsoft's current Agent Framework documents sequential, concurrent, handoff, group-chat and manager-style orchestration patterns. The choice should follow the business process and risk—not a desire to maximise agent count.
Sequential
A defined series of agents or executors, each building on the prior step.
Concurrent
Independent specialist tasks run in parallel before results are reconciled.
Handoff
Responsibility transfers to another specialist when context or rules indicate.
Manager / supervisor
A coordinating agent or workflow allocates work among specialists.
Deterministic workflow + agents
Explicit business process controls the path while agents are used only where model reasoning adds value.
Human control
Dispatcher Gate
The model can propose. The architecture decides whether the action may leave.
A control plane can separate model output from external authority. Depending on the workflow, a proposed action may be allowed, restricted, sent back for information or escalated to a named human approver.
Example control state
- Agent result
- Prepared
- Policy check
- In boundary
- External action
- Locked
- Decision owner
- Human approver
Evidence + audit
Operational evidence matters more than pretending to capture every thought.
An enterprise control plane should be able to preserve material operational facts such as actor, tenant, goal, model/provider, retrieved sources, tool calls, policy result, approvals, released action and outcome. That supports review without requiring private model chain-of-thought.
- Event 1
Goal
- Event 2
Context retrieved
- Event 3
Model/provider
- Event 4
Tool request
- Event 5
Policy result
- Event 6
Human approval
- Event 7
Released action
- Event 8
Outcome
Security boundaries
Do not ask the model to be the only security control protecting the model.
Secure agent systems increasingly use controls in the surrounding architecture: identity, gateways, permissions, sandboxes, tool policies, approval steps and observability. AWS and Google both now expose managed agent infrastructure that reflects this separation.
Read TEMRIK AI Security for the deeper data and model-independence architecture.
Data boundary
Keep tenant, classification and retrieval scope explicit.
Tool boundary
Expose only required operations and credentials, using least privilege.
Action boundary
Separate preparation and recommendation from consequential execution.
Agent boundary
Define ownership, purpose, permissions, delegation and revocation.
Provider boundary
Treat model endpoints as selected compute environments with provider-specific controls and limitations.
Audit boundary
Capture operational evidence without relying on private chain-of-thought.
Implementation
Build the operating architecture around one real workflow.
Enterprise AI architecture becomes credible when it is tested against actual business work, actual permissions and actual exception cases. TEMRIK's implementation philosophy is to prove the boundary before expanding autonomy.
See the current TEMRIK implementation path and how controlled workflows move from context to permission.
- 01
Choose one bounded workflow
Start with work that is frequent, measurable and important enough to justify control.
- 02
Map systems and data
Identify the systems of record, required evidence and data classifications.
- 03
Define identity and authority
Name the actors, permissions, action ceilings and human decision owners.
- 04
Encode the playbook
Make rules, evidence requirements, exceptions and stop conditions explicit.
- 05
Connect models and tools
Use the minimum data and tool access required for the workflow.
- 06
Test the boundaries
Run normal, edge, malicious, missing-data and tool-failure cases.
- 07
Activate bounded authority
Release only the scope that has been operationally accepted.
- 08
Observe and expand
Use evidence, exceptions and outcomes to decide whether more autonomy is justified.
Future architecture
The company should be able to adopt better intelligence without losing its operating memory.
Models will continue to change. Agent frameworks will change. Protocols, providers and tool interfaces will change. The durable layer is the company's own identity, data boundaries, playbooks, authority rules, evidence and integration architecture.
The goal is not to freeze the AI stack.It is to make change survivable.
Primary research
The control-plane idea is visible across current enterprise agent architecture.
These are primary or authoritative sources used to frame this page. Their inclusion does not imply a partnership, certification or TEMRIK implementation of every referenced capability.
Kubernetes
Kubernetes Components — control plane
A useful infrastructure analogy: Kubernetes separates control-plane components that manage cluster state from worker-node components that execute workloads.
OpenAI
Agents SDK
Models, tools, orchestration, handoffs, guardrails, human review, state and observability are treated as distinct parts of an agent system.
Anthropic
Trustworthy agents in practice
Describes agent behaviour as the interaction of model, harness, tools and environment, reinforcing that the model is only one layer.
Microsoft
Agent Framework concepts and orchestrations
Separates agents, workflows and the agent harness; the framework also supports multiple orchestration patterns and human-in-the-loop controls.
AWS
Amazon Bedrock AgentCore observability
Shows production agent infrastructure extending beyond the model into runtime, identity, gateway, memory, tooling and observability.
Google Cloud
Vertex AI Agent Engine
Managed agent infrastructure includes runtime, memory, code execution, identity, observability and production management around agent applications.
NIST
AI Risk Management Framework
Frames AI risk management across organisational governance, mapping, measurement and management rather than as a model-only activity.
The operating principle
See how TEMRIK becomes the control layer.
Start with one valuable workflow and map the data, identity, playbook, model, tools, human authority and evidence it requires.
Status: architecture direction. Specific integrations, providers and production controls depend on the deployment configuration and verified implementation evidence.