Why this section exists
The seven-layer reference architecture defines the Machine Intelligence Runtime boundary: application, orchestration, policy, memory, tools, model adapters, and evidence. This section explains how to build inside that boundary with established software architecture practices.
It is implementation-oriented editorial guidance. It is not a product claim, an SDK claim, a certification scheme, or evidence that MIR is a settled industry standard. Clean Architecture, cloud design patterns, and established risk-management guidance provide useful engineering vocabulary; MiRuntime applies that vocabulary to governed model-driven execution. Source: Clean Architecture guidance Source: Cloud design patterns Source: NIST AI RMF
Architecture map
From logical boundary to deployable system
Clean Architecture for MIR
Place state, authority, use cases, ports, adapters, and infrastructure without coupling the runtime core to providers.
02 · Patterns
Runtime Design Patterns
Map Adapter, Strategy, Saga, Event Sourcing, CQRS, Circuit Breaker, Specification, and State Machine to MIR layers.
03 · Execution
Event-Driven Orchestration
Represent long-running work, approvals, checkpoints, recovery, and termination as durable state and typed events.
04 · Infrastructure
Inference Infrastructure
Understand model-serving constraints without collapsing MIR into a model server or leaking provider details inward.
05 · Placement
Deployment Trade-offs
Choose local, modular, distributed, managed, edge, hybrid, or federated placement while preserving logical controls.
06 · Lifecycle
MLOps, Lineage, and Agent Drift
Version runtime profiles with models, prompts, tools, policies, and evidence schemas; detect behavioral change over time.
Core principle
Reasoning can be probabilistic. Runtime authority cannot be implicit.
The model may
- Reason about a bounded objective.
- Propose a plan or tool action.
- Summarize evidence.
- Rank candidates or alternatives.
The runtime owns
- State and lifecycle.
- Authority and policy decisions.
- Validation and side effects.
- Recovery, termination, and evidence.
How to use the deep dive
Start with clean boundaries and design patterns. Move to event-driven orchestration when runs outlive a request, require approval, or must recover. Use the inference and deployment pages to place components against latency, locality, hardware, and operational constraints. Use the lineage and drift page to make deployment changes reviewable over time.
Production practice identifies established software-engineering controls. Emerging practice identifies patterns being adapted to agentic systems. Research synthesis identifies conclusions that still require workload-specific validation.
Source record
References
Microsoft. Microsoft Learn. Published Current documentation; last reviewed 2026-06-23 UTC. Official architecture guidance.
- Cloud Design Patterns Primary source
Microsoft. Azure Architecture Center. Published Current documentation; last reviewed 2026-06-23 UTC. Official architecture guidance.
National Institute of Standards and Technology. NIST. Published 2023-01-26; last reviewed 2026-06-20 UTC. Government framework.