The MiRuntime reference architecture separates responsibilities that are often collapsed into a prompt or agent loop. The separation is conceptual: a production implementation can combine services, but it should preserve explicit contracts and trust boundaries.
Key takeaways
- Identity, authorization, budgets, and evidence cross every layer.
- Policy decisions must be evaluated outside the model’s natural-language output.
- Every consequential side effect should have a typed action, lifecycle state, and evidence event.
1Application
Captures user intent and presents reviewable outcomes.
- Inputs
- Objective, identity, user interaction
- Outputs
- Run request, review, approval
- Failure mode
- Ambiguous objective or hidden consequence
- Keep outside the prompt
- Final user authorization and product policy
2Runtime orchestration
Maintains state, schedules steps, budgets work, and selects recovery paths.
- Inputs
- Run contract and observations
- Outputs
- State transitions and work dispatch
- Failure mode
- Loops, stale workers, or unbounded budgets
- Keep outside the prompt
- Lifecycle authority cannot live only in a prompt
3Policy and permissions
Evaluates identity, risk, data, tools, and required approvals.
- Inputs
- Subject, action, resource, context
- Outputs
- Allow, deny, transform, approve, escalate
- Failure mode
- Ambient authority or policy bypass
- Keep outside the prompt
- Credentials, policies, and decisions remain typed
4Memory and context
Selects scoped, attributable, current information for the run.
- Inputs
- Sources, memory scopes, retention rules
- Outputs
- Context projection and provenance
- Failure mode
- Stale, poisoned, excessive, or prohibited memory
- Keep outside the prompt
- Consent, deletion, and source authority
5Tools and connectors
Executes typed actions through bounded adapters.
- Inputs
- Validated arguments and scoped credentials
- Outputs
- Structured result, side effect, artifact
- Failure mode
- Partial writes, exfiltration, timeouts, injection
- Keep outside the prompt
- Permission and side-effect class
6Model adapters
Normalizes model capabilities, streaming, tools, budgets, and errors.
- Inputs
- Context, prompt contract, model route
- Outputs
- Candidates, plans, embeddings, scores
- Failure mode
- Invalid output, provider failure, capability mismatch
- Keep outside the prompt
- Model selection and provider policy
7Evidence and telemetry
Preserves operational traces and user-facing execution evidence.
- Inputs
- Events from every layer
- Outputs
- Timeline, artifacts, metrics, incident record
- Failure mode
- Missing correlation, sensitive overcollection, silent effects
- Keep outside the prompt
- Retention, access, and evidence semantics
Complete execution sequence
- Capture intent: normalize the objective, requester identity, risk class, and success criteria.
- Select context: apply scopes, provenance, data-class rules, freshness, and prohibited-data filters.
- Plan: ask one or more models to propose steps under explicit budgets and tool contracts.
- Validate: check schemas, policy, authority, dependencies, and likely side effects.
- Gate: require approval when risk or policy demands an independent decision.
- Act: execute in a bounded workspace with short-lived credentials and controlled egress.
- Observe and recover: inspect results, retry safely, compensate, roll back, or escalate.
- Close: produce artifacts, evidence, remaining uncertainty, and a terminal lifecycle state.
Control plane and runtime plane
The control plane manages identity, policy, provisioning, routing, configuration, lifecycle, and organization-wide observability. The runtime plane hosts an isolated session: its workspace, model adapters, tools, memory view, checkpoints, and artifacts. Evidence spans both planes so an investigation can connect a policy decision to the action it governed.
Deployment patterns
Local
Policy, memory, tools, and models execute on a user-controlled endpoint. Strong placement control, limited by local capability.
Hybrid
Local control selects remote models or services while preserving scoped data flow, approvals, and local evidence.
Cloud-managed
A provider provisions isolated runtime sessions and centralizes policy and operations. Contract clarity is critical.
Edge
Latency-sensitive runtime components execute near devices, with intermittent upstream coordination.
Federated
Independent runtimes exchange bounded tasks or evidence through explicit identity and protocol contracts.
Failure and recovery paths
| Failure | Runtime response | Evidence |
|---|---|---|
| Tool timeout | Idempotent retry, alternate connector, or pause | Attempt count, timeout, chosen recovery |
| Policy denial | Stop, transform request, or seek approval | Rule, subject, action, decision rationale |
| Invalid model output | Schema repair, constrained retry, alternate model | Validation failure and revised attempt |
| Partial side effect | Rollback or compensating action | Before/after state and compensation result |
| Uncertain objective | Pause and ask the user | Ambiguity and unresolved decision |
Evidence and discovery
Architecture pages expose one canonical URL, one H1, reviewed UTC metadata, source IDs, related-reading links, and JSON-LD that matches visible content. Public discovery files point back to these canonical pages rather than creating separate bot-only explanations.
- Use visible headings and tables as the source of truth.
- Keep schema markup aligned with the page title, description, audience, reviewed date, topics, and cited sources.
- Use the content catalog and route inventory for discovery, not for granting tool or write authority.
- Reject generated summaries that imply certification, guaranteed rankings, or live readiness without deployment evidence.
Downloadable architecture
The SVG preserves the complete layer labels and cross-cutting concerns for design reviews, print, and architecture documentation.
Status: MiRuntime editorial reference artifacts. These files are not an SDK, certification, or industry standard.
Source record
References
- AI Runtime Infrastructure Primary source
Christopher Cruz. arXiv. Published 2026-03; last reviewed 2026-06-20 UTC. Research paper.
- Model Context Protocol Specification — 2025-11-25 Primary source
Model Context Protocol project. Model Context Protocol. Published 2025-11-25; last reviewed 2026-06-24 UTC. Protocol specification.
OpenTelemetry project. Cloud Native Computing Foundation. Published Current specification repository; last reviewed 2026-06-24 UTC. Official specification.
National Institute of Standards and Technology. NIST. Published 2023-01-26; last reviewed 2026-06-20 UTC. Government framework.