SPHR Enterprise Agentic Multi-Purpose Harnesses — The Control Plane — Part 1

Part 1 of 5 · SPHR Enterprise Agentic Multi-Purpose Harnesses

Architecture diagram of the SPHR agentic harness control plane — personas, rules, models, and memory held in a portable store the organization owns, with model-agnostic reasoning tiers mapping to models behind an AI gateway.

Every enterprise adopting AI agents hits the same wall on the way to production: the parts that matter most — the agent's rules, its knowledge, and its identity — end up locked inside someone else's platform. Change vendors and you re-author everything. That is the problem the SPHR Enterprise Agentic Multi-Purpose Harnesses were built to solve. A harness is a governed, multi-tenant, multi-agent platform built on the Microsoft Agent Framework (MAF) 1.0 and the Agent Governance Toolkit (AGT), where a chat-driven orchestrator spins up governed subagents on demand — the production pattern we described in the enterprise agent control plane. This first part is about the foundation the whole thing rests on: a control plane the organization owns. We cover why lock-in happens, what "owning the control plane" actually means, how personas stay model-agnostic through reasoning tiers, and the single authored-and-governed pipeline everything flows through.

Where agent knowledge, rules, and identity get trapped

When you build an agent inside a proprietary managed platform, the convenience is real — until you look at where your intellectual property lives. The persona that defines how the agent behaves, the rules that constrain it, the curated knowledge it reasons over, and the identity it acts under are all expressed in that platform's schema, stored in its managed services, and enforced by its runtime. None of it is portable. Swapping the model behind the agent means re-testing inside the vendor's tooling; moving clouds means rebuilding; and the audit trail that proves what the agent did is whatever the platform chose to expose. The lock-in is not a licensing line item — it is architectural. The design principle we start from is the inverse: the control plane is the portable core the organization owns, and the vendor services are replaceable parts around it.

What "own the control plane" means

Owning the control plane means the assets that define your agents live in portable storage you control, not inside a vendor's knowledge service. In a harness, a NoSQL control-plane store holds the collections that matter: personas and their scope-of-work, rules and contracts, the tool allow-list and model catalogue, version and lineage bindings, the memory store, shared project context, a schema/type registry, and a tamper-evident audit log. Two rules keep it clean. First, secrets never live in the control plane — the registries hold only references, and the actual keys and tool credentials resolve at call time from a separate secrets vault. Second, the control plane is the serving layer, while the human-authored source of truth is the Open Knowledge Format (OKF) — vendor-neutral markdown with YAML frontmatter, versioned in Git, diffable and PR-reviewable. Agents never read OKF directly; they read the ingested control-plane documents, so the authoring format can be swapped without an agent noticing. That separation is what makes the core portable.

Model-agnostic through reasoning tiers

The fastest way to get locked in is to hardcode a model. We avoid it with a fixed taxonomy of reasoning tiers. A persona never references a model by name; it references a tier — reasoning-high, reasoning-standard, or fast for generation work, plus a separate embedding tier used only for vectorizing knowledge and memory. A model registry maps each tier to a concrete model behind the AI gateway. Swap the model behind reasoning-standard and every persona that uses that tier picks up the change with no edit, no re-authoring, and no redeploy of the agents themselves. That is what "model-agnostic AI agents" means in practice: not a vague aspiration, but a config indirection that survives the model market moving underneath you — and it will. The one deliberate exception is the embedding tier: because changing the embedding model forces a full re-embed of everything indexed, that choice is locked once data is indexed, and we treat it accordingly.

One pipeline: author, approve, version, govern

The same discipline applies to everything an agent touches. Personas, rules, contracts, tools, and models are all created and published through one pipeline rather than a dozen ad-hoc paths. An author drafts a persona and its scope in an authoring UI; an approval workflow gates it so only approved versions proceed and rejected ones loop back; a test-and-eval harness validates a persona or a model before go-live; and promotion runs dev → staging → prod. Because OKF lives in Git, the approval gate is a pull request, each promotion is a branch, and every change is an auditable commit. Tools and models are catalogued the same way: the tool/MCP registry records each connector's endpoint, schema, credential reference, OAuth scopes, and version; the model registry records each model by tier, endpoint, key reference, and version. One consistent pattern means one place to reason about change — and one lineage to audit.

Knowledge is not memory

A harness keeps two kinds of information deliberately apart, because collapsing them is a quiet way to corrupt an agent. Knowledge is authored, curated, and read-only — the reference material agents query on demand, grounded and cited. Memory is emergent and written back — what agents learn as they work. They live in separate stores with separate lifecycles for a reason: if conversation noise could flow into authoritative reference docs, every future answer would inherit the pollution. Knowledge is broadly shared and changes only through the authoring pipeline above; memory is scoped tightly and updated at runtime. We go deep on memory — its four types, and how per-tenant isolation and cost controls wrap it — in Part 5 of this series. For now the principle is enough: authored knowledge and emergent memory are different materials, stored and governed differently.

A control-plane ownership checklist

Before you trust any agent platform with production work, check who actually owns the pieces that define your agents. If several answers are "the vendor," that is where your next migration will hurt:

  • Portability. Are personas, rules, and curated knowledge stored in a format and a store you can export and run elsewhere — or only inside a vendor's managed service?
  • Model independence. Does a persona reference a reasoning tier (swappable by config) or a hardcoded model (swappable only by re-authoring)?
  • Secrets hygiene. Does the control plane hold only references, with keys and credentials resolved from a separate vault at call time?
  • One pipeline. Are knowledge, tools, and models all authored, approved, versioned, and promoted through the same auditable path?
  • Source of truth. Is there a human-readable, diffable, version-controlled record — such as OKF in Git — that is independent of the runtime serving store?

Continue the series

This is Part 1 of a five-part series on the SPHR Enterprise Agentic Multi-Purpose Harnesses:

  • Part 1 — The control plane you own (you are here)
  • Part 2 — Agent identity and zero trust: short-lived attested identities and per-action authorization
  • Part 3 — Governance at runtime: a deterministic policy kernel and tamper-evident audit
  • Part 4 — The OWASP Agentic Top 10, controlled: ASI01–ASI10 answered with concrete controls
  • Part 5 — Multi-tenant knowledge, memory, and cost: isolation and FinOps at the action layer

For the broader category this sits inside, see the seven pillars of production-ready agentic AI and our honest scorecard in Hermes vs. a governed enterprise agent.

How SPHR helps

SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We design and assemble harnesses where the control plane is yours: personas, rules, curated knowledge, and identity in portable storage, model-agnostic through reasoning tiers, and everything authored, approved, versioned, and governed through one pipeline. As an Anthropic partner working model-agnostic and multi-cloud, we build so the engine stays swappable while the controls — and your intellectual property — stay with you. If your agents' rules and knowledge are trapped in someone else's platform, let's talk about a control plane you own.

Frequently asked questions

What is an agent control plane?

An agent control plane is the layer that holds and governs everything that defines your agents — personas, rules, contracts, the tool allow-list and model catalogue, memory, project context, and a tamper-evident audit log — in storage the organization owns. In a harness it is a portable NoSQL store, separate from the agent runtime and from any single vendor's managed services, so the assets that make your agents valuable stay with you rather than inside a platform you rent.

What does model-agnostic actually mean for AI agents?

It means a persona references a reasoning tier — such as reasoning-high, reasoning-standard, or fast — rather than a specific model. A model registry maps each tier to a concrete model behind the AI gateway, so swapping the model behind a tier updates every persona that uses it with no re-authoring. The one exception is the embedding tier: because changing the embedding model forces a full re-embed of indexed data, that choice is fixed once data is indexed.

Why keep agent knowledge and memory in separate stores?

Knowledge is authored, curated, and read-only; memory is emergent and written back as agents work. If they shared one store, conversation noise could pollute authoritative reference material, and every future answer would inherit the corruption. Keeping them in separate stores with separate lifecycles means knowledge changes only through the authoring pipeline, while memory updates at runtime within tight scope.

What is OKF and why author agents in it?

OKF (Open Knowledge Format) is a vendor-neutral format — markdown files with YAML frontmatter — used as the version-controlled source of truth for authored personas and concepts. It is human-readable, diffable, and PR-reviewable in Git, so approvals are pull requests and promotions are auditable commits. Agents never read OKF directly; they read the ingested control-plane documents, so the authoring format can be swapped without any agent noticing.

How does owning the control plane reduce vendor lock-in?

Because the assets that define your agents — personas, rules, knowledge, identity bindings, and audit — live in portable storage and a version-controlled source of truth you control, not inside a vendor's managed service. Models are referenced by tier, not hardcoded; secrets resolve from a separate vault; and one authored pipeline governs change. Vendor services become replaceable parts around a core you keep, so switching a model, a cloud, or a tool does not mean re-authoring your platform.

This series describes the pattern-level architecture of the SPHR Enterprise Agentic Multi-Purpose Harnesses, built on public frameworks — Microsoft's Agent Framework and Agent Governance Toolkit, the Model Context Protocol (MCP), and the Open Knowledge Format (OKF). Implementation details are generalized.