A capable model needs controls, integrations and operating capabilities around it. We call these harnesses. This blueprint assigns sixteen clear responsibilities—from checking permissions to verifying outcomes—so teams can decide who owns each one and what proves it works.
THE ARCHITECTURE
One model. Sixteen boundaries.
Runtime is the outer plane; Knowledge is nearest the core. Rings group concerns, not priority or deployment dependencies.
15 / Retrieval
What information matters now?
Assemble the smallest sufficient context for each step, inside a token budget: hybrid retrieval, reranking, graph traversal, iterative refinement, compaction and tool search.
The compute, scheduling, networking and resilience substrate every other harness sits on — Kubernetes across public and private cloud, GPU-aware and multi-tenant from the start.
Ingredients
Kubernetes clusters across public and private cloud, with a private path for regulated workloads
GPU scheduling, quota and gang-scheduling so accelerators are not idle
Storage, queues, service mesh, secrets distribution and network policy
High availability, disaster recovery and capacity planning
Serve, version and scale the models — proprietary and open-weight — with predictable latency and cost, and keep them swappable so no single provider becomes load-bearing.
Ingredients
Inference serving: batching, KV cache, tensor and pipeline parallelism
Model registry and version pinning, including deprecation calendars
Routing between model tiers, plus fallbacks when a provider degrades
Embedding and reranking endpoints used by retrieval
Capacity and quota per tenant on shared accelerators
The surfaces where people meet the system — and where they steer it: channels, streaming, sessions, clarification, provenance display and the approval moments that make autonomy safe.
Ingredients
Channels: web, mobile, chat platforms, voice and public API
Streaming and partial-result rendering so long tasks stay legible
Session and conversation state at the edge
Clarification prompts when the task is under-specified
Approval and review surfaces for human-in-the-loop checkpoints
Provenance display: what the answer was based on and how confident it is
Runtime enforcement on every call, plus the agentic attack surface: non-human identity, injection and PII defence, output validation, supply chain, circuit breakers and kill switches.
Ingredients
Deterministic checks pre-call, in-loop and post-call
Prompt-injection and jailbreak defence, including on retrieved content
PII and PHI detection and redaction in both directions
Output validation against schema and policy before anything executes
Non-human identity: one identity per agent, tool and server; just-in-time scoping
Supply-chain controls: signing, scanning, pinning, SBOM and AIBOM
Circuit breakers and kill switches with a tested revocation path
6GovernanceWhat autonomy is allowed, and how does it evolve?+
Decide how much independence each action may have, prove it with policy-as-code and human checkpoints, and run the change control that lets the system improve safely.
Ingredients
Risk-based autonomy tiers: autonomy level as a function of action impact, uncertainty, identity, data sensitivity, regulation, reversibility and confidence
Human-in-the-loop and human-on-the-loop checkpoints at durable pause points
Policy-as-code compiled into gateway and runtime enforcement
Registries for agents, prompts, models, tools, skills, datasets and policies
CI/CD, canary and shadow release, with rollback
Audit trail, lineage and evidence packs for regulators
Feedback capture flowing into fine-tuning, distillation and prompt change
Incident process and post-incident change
7ObservabilityWhat happened — and what did it cost?+
Make any task reconstructable end to end and attribute its cost: OpenTelemetry GenAI spans carrying trace, thread and task IDs, the acting identity, the policy decision and the token spend.
Ingredients
Distributed tracing across model calls, tool executions, retrieval, memory and agent runs
Correlation IDs that survive handoffs, queues and human approvals
Time-travel debugging: replay of prompts, delegations and memory state at failure
Quality and drift monitoring, including silent-failure detection
Token metering, budgets, chargeback and cost per successful task
Standard contracts at every boundary so frameworks stay replaceable: MCP downward to tools and data, A2A sideways to peer agents, OpenAPI and AsyncAPI to the rest of the estate.
Ingredients
MCP servers and clients for tools, resources and prompts
A2A agent cards, task lifecycle and artifacts for agent-to-agent work
OpenAPI and AsyncAPI contracts for conventional services and events
Registries: which agents, tools and skills exist, at which version, owned by whom
Version and deprecation policy across protocol revisions
Supply-chain scanning of third-party servers and skills
Plan and decompose the task, route work to the right agent or tool, checkpoint durably so long tasks survive restarts, and stop cleanly when budget or policy says so.
Ingredients
Planning and decomposition; orchestrator-worker and handoff patterns
Durable checkpoints, retries and idempotency for side-effecting steps
The action surface: typed tool contracts, packaged skills, an explicit read-versus-write authority model, and isolation strong enough for code the model wrote.
Ingredients
Tool contracts with typed inputs, outputs and error semantics
Skills as packaged, versioned capability (SKILL.md and equivalents)
Read-versus-write authority classification for every tool
Sandboxing for generated code and untrusted execution
Idempotency, dry-run and rollback for side-effecting tools
Keep discriminative and optimisation models in the architecture as first-class tools and routing signals — often cheaper, faster and more accurate than asking a language model.
Ingredients
Classifiers for routing, triage, intent and safety pre-screening
Rerankers and scorers supporting retrieval
Anomaly detection and forecasting feeding agent decisions
Optimisation and constraint solving where the answer is a plan, not prose
Feature store, training pipelines and drift monitoring for these models
Shared, machine-usable meaning: ontologies, a semantic layer, agreed metric definitions and regulation expressed as knowledge the agent can reason over.
Ingredients
Domain ontology and taxonomy — entities, relationships, business rules
Semantic layer and metric definitions so one term returns one number
Glossary and synonym mapping between business and system vocabulary
Regulation as knowledge: rules the agent must understand, distinct from policy it must obey
Stewardship: who owns each definition and how changes are reviewed
Governed access to source systems with lineage and entitlements attached — the data plane behind retrieval, deliberately separate from the tool plane that takes actions.
Ingredients
Connectors and data servers exposing systems of record to agents
Data contracts: schema, freshness and quality guarantees per source
Lineage from source through transformation to the answer
Entitlements: row and column security carried through to the agent
Federated query across warehouses, lakes and operational stores
Classification of sensitive fields before anything is indexed
Assemble the smallest sufficient context for each step, inside a token budget: hybrid retrieval, reranking, graph traversal, iterative refinement, compaction and tool search.
Ingredients
Hybrid retrieval (lexical plus dense) with reranking
GraphRAG and structured retrieval where relationships matter
Agentic, iterative retrieval that refines its own queries
Context pruning and compaction to fight bloat
Token budgeting per step and per task
Tool search: retrieving relevant tool definitions instead of loading all of them
Decide deliberately what persists beyond a task — working, episodic, semantic and procedural memory — with an explicit write policy, retention limits and poisoning controls.
Ingredients
Working memory within a task and session
Episodic memory: what happened before, per user and per tenant
Semantic memory: durable facts learned about the domain and the user
Procedural memory: how this organisation does a task
Write policy — what earns a place in memory — plus TTL and forgetting
Redaction, tenant partitioning and the right to erasure
The model remains fixed at the center. Four concern planes appear from the inside out: Knowledge, Execution, Trust, and Runtime. Each plane then divides into four equal segments with shortened harness names. The legend provides each harness explanation and ingredients.
OPERATING RESPONSIBILITIES
Control the whole release.
01
DevOps
Deliver software
Version code, test contracts, build reproducibly and recover compatible releases.
02
MLOps
Manage learned behaviour
Track data and model lineage, validate statistical quality and monitor drift.
03
LLMOps
Evaluate meaning
Version prompts and retrieval, evaluate grounded answers and control model use.
04
AgentOps
Control delegated action
Bind identity and authority to each action; govern tools, memory, workflow and outcomes.
Responsibilities accumulate where applicable. This is a useful operating model, not a requirement that every agent deploy every capability from every era.
A REPRODUCIBLE RELEASE
Version the system. Not just the model.
One release manifest links the artifacts, their provenance and the authority that approved them. Select an artifact to inspect its ownership and recovery implications.
Separate the jobs that fail differently, change at different speeds, or answer to different owners.
The harnesses are not products and the planes are not deployment layers. They are a vocabulary for deciding where a responsibility belongs—and where evidence must cross a boundary.
ILLUSTRATION / SWITCH A HARNESS OFF
Absence is easier to see than architecture.
Choose a boundary to remove from the reference task. This is a scripted illustration, not a live model simulation.
Step 14 / BOUNDARY REMOVED
A retrieved document contains an instruction. The agent follows it and exposes restricted data.
Security, Safety & Guardrails would screen retrieved content again inside the loop.
Discuss your workflow