Future State Platform
Design Principles
- Deploy inside the client’s Azure tenant so identity, data, network, and operations stay aligned with client controls.
- Separate control-plane change from runtime execution so platform governance does not require redeploying every workload concern.
- Treat knowledge grounding, evaluation, and observability as platform capabilities rather than optional add-ons.
- Reuse Agent Primitives as the shared execution substrate instead of duplicating orchestration logic inside each domain solution.
- Split repositories only after service contracts and delivery boundaries are stable enough to avoid premature fragmentation.
Platform Planes
| Plane | Purpose | Primary Containers |
|---|---|---|
| Experience Plane | Operator, builder, and approval experience | Mission Control Portal |
| Control Plane | Tenant, policy, solution pack, and release management | Platform API, Governance and Registry Service |
| Runtime Plane | Agent execution, tool invocation, and escalation control | Runtime Orchestrator, Tool and Action Gateway |
| Knowledge Plane | Ingestion, curation, and grounded retrieval | Knowledge Pipeline, Context and Retrieval Service |
| Operations Plane | Quality gates, experimentation, auditability, and value tracking | Evaluation and Experiment Service, Observability and Value Service |
| Data Plane | Persistent state and event backbone | PostgreSQL, Blob Storage, AI Search, Service Bus |
Relationship To Agent Primitives
NeuralOps should not own every low-level agent concern itself. The future-state model assumes that Agent Primitives continues to provide reusable agent lifecycle and execution capabilities, while NeuralOps adds tenant-aware governance, domain solution packaging, knowledge operations, and measurable business value on top.
Container View
This view shows the future-state platform decomposition inside NeuralOps.
Architecture diagrams for NeuralOps are being migrated to Mermaid/Excalidraw C4 format. Placeholders will be replaced with embedded diagrams in a future update.
Deployment View
The ideal runtime target is a client-owned Azure landing zone with separate application, data, and control concerns.
Governed Execution Flow
This dynamic view highlights the design intent for grounded, policy-aware, human-reviewable execution.
What The Model Optimises For
- Faster separation of policy and configuration changes from runtime scaling concerns
- Cleaner packaging of domain accelerators as reusable solution packs
- Better support for tenant-specific approval, audit, and operational workflows
- A platform shape that can evolve from the current accelerator codebase without pretending the current system is a clean-sheet build