SPHR Enterprise Agentic Multi-Purpose Harnesses — Multi-Tenant Knowledge, Memory & Cost — Part 5

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

Running many companies' agents on one platform raises three questions at once: what agents know, what they remember, and what they cost — each answered per tenant, without the tenants ever bleeding into one another. This is the final part of our series on the SPHR Enterprise Agentic Multi-Purpose Harnesses, building on the control plane you own, agent identity, runtime governance, and the OWASP controls. Here we cover the knowledge-versus-memory split, the four kinds of memory an agent actually keeps, per-tenant cryptographic isolation strong enough to offboard by destroying a key, and FinOps enforced at the same action layer that governs behavior.

Knowledge vs memory, revisited

Part 1 introduced the split; multi-tenancy is where it earns its keep. Knowledge is authored, curated, and read-only — reference material agents query and cite, changed only through the approval pipeline. Memory is emergent and written back — what agents learn as they work, updated at runtime. Keeping them in separate stores with separate lifecycles is not tidiness; it is a safety control. If conversation noise could flow into authoritative reference docs, one tenant's stray turn could corrupt the knowledge every future answer is grounded in. Knowledge is broadly shared within its scope and slow-changing; memory is scoped tightly and fast-moving. Different materials, different stores, different rules.

Memory is four things, not one

"Agent memory" is really four distinct things, and treating them as one is how retrieval turns to mush. A harness partitions them:

• Working memory — current task state, alive for the duration of the work and then discarded.
• Episodic memory — conversation history: what was said and done, in order.
• Semantic memory — learned facts, vector-searchable, so an agent can recall a relevant fact without replaying the whole conversation.
• Procedural memory — learned workflows: how a task was accomplished, reusable next time.

They can share a backing store — in a harness, the same pgvector/PostgreSQL store that holds knowledge embeddings also backs memory — but they differ in lifespan and access pattern, so they are partitioned rather than merged. Because project context is shared, a fact one subagent learns becomes available to every subagent and member on that project, which is powerful and is exactly why the isolation below has to be airtight.

Per-tenant cryptographic isolation

Multi-tenant isolation that rests on a WHERE tenant_id = ? clause is one forgotten filter away from a breach. A harness isolates cryptographically. Each tenant has its own customer-managed key (CMK), with the tenant bound into the encryption context so a wrong-tenant decrypt fails cryptographically, not just by policy. Tenant context travels in signed tokens and session tags rather than a database column, and PostgreSQL Row-Level Security (RLS) is the in-database backstop that survives a forgotten filter. Offboarding is a crypto-shred: destroy the tenant's key and its data is unrecoverable, which is a far stronger deletion guarantee than chasing rows across a store. And a tenant's home region is recorded and drives storage and compute routing, so residency obligations are met by construction. The benchmark we hold ourselves to is simple: a wrong-tenant decrypt must fail, provably, before a tenant is onboarded.

FinOps at the action layer

Autonomous agents create spend that scales with behavior, not headcount — the cost shape we unpacked in FinOps for autonomous AI agents. Multi-tenancy sharpens it: you must know not just what the platform cost, but what each tenant cost. The answer reuses the interception point from runtime governance: because every model and tool call already flows through one point carrying a scoped agent identity and tenant context, you tag each call with the agent, task, and tenant that triggered it. That yields clean cost attribution and per-tenant chargeback from one trail instead of a raw aggregate invoice. On top of it sit per-tenant quotas — rate and token limits that stop a noisy neighbor from starving everyone else — and cost caps enforced deny-by-default: per-task operation limits, per-agent daily and per-tenant monthly budgets, anomaly detection, and a kill switch. An action that would blow the budget simply does not execute.

Notice how the pieces reinforce each other. The scoped per-agent identity from Part 2 is what makes a cost line attributable to a tenant at all; the interception point from Part 3 is where both the policy decision and the cost meter live; and the per-tenant key from this part is what keeps one tenant's data — and its usage record — from ever resolving under another tenant's context. Isolation, governance, and FinOps are not three subsystems bolted together; they are three views of the same action layer. That is the whole argument of this series: build the layer once, own it, and knowledge, identity, policy, audit, tenancy, and cost stop being features you rent and become properties you can prove.

A multi-tenant readiness checklist

Before you run more than one company's data through one agent platform, confirm all five:

• Knowledge/memory split. Are authored knowledge and written-back memory in separate stores, so conversation noise cannot pollute authoritative reference material?
• Memory partitioned. Are working, episodic, semantic, and procedural memory kept distinct rather than dumped into one blob?
• Crypto isolation. Does each tenant have its own key, with wrong-tenant decrypt failing cryptographically — not just a tenant-id filter and RLS?
• Crypto-shred offboarding. Can you delete a tenant by destroying its key, and is a home-region residency route recorded?
• Cost caps at the action layer. Is spend attributed per tenant and capped deny-by-default, so a runaway loop cannot run up an unbounded, unattributable bill?

Continue the series

This is Part 5, the finale, of the series on the SPHR Enterprise Agentic Multi-Purpose Harnesses:

• Part 1 — The control plane you own
• Part 2 — Agent identity and zero trust
• Part 3 — Governance at runtime
• Part 4 — The OWASP Agentic Top 10, controlled
• Part 5 — Multi-tenant knowledge, memory, and cost (you are here)

For the operating model these five parts assemble into, see the seven pillars of production-ready agentic AI and the enterprise agent control plane.

How SPHR helps

SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We design harnesses that run many tenants safely on one platform: authored knowledge kept apart from four kinds of written-back memory, per-tenant cryptographic isolation you can offboard with a key destruction, and FinOps — attribution, quotas, and deny-by-default cost caps — enforced at the same action layer that governs behavior. As an Anthropic partner working model-agnostic and multi-cloud, we make the isolation and the economics hold whatever engine sits underneath. If you are putting more than one customer's data through agents, let's design the tenancy properly.

Frequently asked questions

What's the difference between agent knowledge and agent memory?

Knowledge is authored, curated, and read-only — reference material agents query on demand and cite, changed only through an approval pipeline. Memory is emergent and written back — what agents learn as they work, updated at runtime. They live in separate stores with separate lifecycles so conversation noise cannot pollute authoritative reference material. Knowledge is broadly shared; memory is scoped tightly to a project or tenant.

What are the four types of AI agent memory?

Working memory holds current task state; episodic memory holds conversation history; semantic memory holds learned facts and is vector-searchable; and procedural memory holds learned workflows. They can share a backing store but differ in lifespan and access pattern, so a harness partitions them rather than merging them — which keeps retrieval relevant and lets each type expire or persist on its own schedule.

How do you isolate multiple tenants on a shared AI platform?

With per-tenant cryptographic isolation, not database columns alone. Each tenant has its own customer-managed key with the tenant bound into the encryption context, so a wrong-tenant decrypt fails cryptographically; tenant context travels in signed tokens rather than a WHERE clause; PostgreSQL Row-Level Security (RLS) is the in-database backstop; and offboarding is a crypto-shred — destroy the tenant's key and its data is unrecoverable. Home-region residency routing keeps data where it must live.

How does FinOps work for autonomous AI agents?

The same interception point that authorizes each action also meters it, so every model and tool call is tagged with the agent, task, and tenant that triggered it. That gives clean cost attribution and per-tenant chargeback from one trail rather than a raw aggregate invoice. Per-tenant quotas prevent noisy-neighbor starvation, and cost becomes a first-class, observable metric instead of a quarter-end surprise.

How do you enforce a cost cap on an AI agent?

At the action layer, deny-by-default for spend. Per-task operation limits reject a runaway loop before it fans out; per-agent daily and per-tenant monthly budgets draw a hard ceiling; anomaly detection flags a run behaving unlike its history; and a kill switch suspends an agent that breaches a threshold. An action that would blow the budget simply does not execute — the same enforcement point that governs behavior governs cost.

This series describes the pattern-level architecture of the SPHR Enterprise Agentic Multi-Purpose Harnesses, built on public technology — the Microsoft Agent Framework (MAF) and Agent Governance Toolkit (AGT), pgvector/PostgreSQL with Row-Level Security, and OpenTelemetry. Implementation details are generalized.