# Meridian — Enterprise Platform & Compliance Architecture

**A build dossier for the agent platform behind Meridian.**
Version 0.1 · Prepared for an energy-efficiency engagement and the multi-tenant platform that follows.

---

## 0. Purpose & how to read this

This document is the engineering and compliance blueprint for the Meridian platform: the
system we use to **design, build, test, deploy, operate, and govern AI agents** for
enterprise customers. It is written to be handed to an engineering lead, a security
reviewer, or a prospective customer's compliance team without edits.

It answers, concretely:

- How agents are rolled out, from a scoped workflow to production.
- What the agent **harness** is and why it is the core IP.
- How agents are **tested and validated** — before launch and continuously after.
- What the **deployment pipeline** looks like.
- What **contracts, connectors, and integrations** are required.
- How the platform meets **enterprise compliance** (SOC 2, GDPR/CCPA, NIST AI RMF, EU AI Act) with no gaps.
- How **teams onboard**, with roles, SSO, and multi-tenancy.
- A frank **gap analysis** and a phased **build roadmap**.

> **Reference engagement (client anonymized).** A regional commercial energy-efficiency
> contractor — the energy division of a construction group — runs a high-volume, rules-bound *assessment → eligibility →
> proposal → contract → install → rebate filing* pipeline. It handles utility programs
> (e.g. PSE&G Direct Install, up to 80% incentives) across businesses, municipalities,
> non-profits, and schools. It is an ideal first workload: document-heavy, rule-governed,
> repetitive, and high-value — the exact shape agents excel at, and one where auditability
> genuinely matters (utilities and public entities are involved).

---

## 1. Reference architecture (the layers)

The platform is organized into seven layers. Each is independently ownable, testable, and
auditable.

```
┌───────────────────────────────────────────────────────────────────┐
│ 7. EXPERIENCE      Console · Review queue · Dashboards · Onboarding │
├───────────────────────────────────────────────────────────────────┤
│ 6. GOVERNANCE      Policy engine · Approvals · Audit log · RBAC     │
├───────────────────────────────────────────────────────────────────┤
│ 5. AGENT RUNTIME   Orchestrator · Harness · Tools · Memory · HITL   │
│    (THE HARNESS)                                                     │
├───────────────────────────────────────────────────────────────────┤
│ 4. MODEL GATEWAY   Provider routing · Prompt registry · Caching     │
├───────────────────────────────────────────────────────────────────┤
│ 3. EVALUATION      Datasets · Offline evals · Online scoring · Red  │
├───────────────────────────────────────────────────────────────────┤
│ 2. INTEGRATION     Connectors · Data contracts · Ingestion · RAG    │
├───────────────────────────────────────────────────────────────────┤
│ 1. FOUNDATION      Identity · Secrets · Encryption · Tenancy · Infra│
└───────────────────────────────────────────────────────────────────┘
        Cross-cutting: Observability · Security · Cost control
```

**Design tenets**

1. **Prefer the simplest architecture that clears the bar.** A workflow beats an agent; a
   single agent beats a swarm. Autonomous multi-agent systems can consume on the order of
   **~15× the tokens of a chat** ([Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system)),
   so we reach for them last — reserved for high-value, parallelizable, breadth-first work —
   not first. Knowing *when not to use an agent* is part of the job
   ([Anthropic, *Building Effective Agents*](https://www.anthropic.com/engineering/building-effective-agents)).
2. **Every capability is a permissioned tool.** Agents never get raw access to a system;
   they get a typed, scoped, rate-limited tool that is logged on every call.
3. **Deterministic scaffolding around non-deterministic cores.** Validation, routing, and
   business rules are ordinary, testable code. The model is one component, not the system.
4. **Nothing ships unmeasured.** Promotion is gated on evaluations — of the final output
   *and the trajectory taken* — not opinion.
5. **Everything is reproducible and attributable.** Any production state maps to a versioned
   artifact, a change, and a person.
6. **Humans own consequences.** High-impact actions require explicit human approval.

> **Grounding.** These tenets and the practices below are cross-checked against current
> primary sources (Anthropic, LangChain/LangGraph, OpenTelemetry, and academic surveys) in
> [`RESEARCH.md`](RESEARCH.md), which also records where our own thinking had gaps.

---

## 2. Rolling out agents — the delivery lifecycle

A repeatable, five-stage lifecycle governs every agent from idea to ownership. It contains
risk and makes value provable at each gate.

### Stage 1 — Scope & discovery
- Shadow the workflow; quantify the baseline (time, cost, error rate, volume).
- Build a **process map**, **data inventory**, and **systems-of-record access map**.
- Classify each decision point: **automate**, **assist**, or **escalate to human**.
- Agree success metrics and **promotion thresholds** (accuracy, safety, latency, cost) in writing.
- Produce a lightweight **AI risk assessment** (see §6.4) and data-flow diagram.

**Exit gate:** signed scope, agreed metrics, data access approved, risk tier assigned.

### Stage 2 — Build on the harness
- Define the agent: role, allowed tools, prompts, policies, memory scope.
- Implement each tool with least-privilege access and I/O validation.
- Wrap non-deterministic steps in deterministic checks and business rules.
- All artifacts (prompts, tools, policies) are versioned and peer-reviewed.

**Exit gate:** agent runs end-to-end in a sandbox against synthetic + sample data.

### Stage 3 — Evaluate & harden
- Assemble **golden datasets** from real historical cases with verified outcomes.
- Run offline evals: accuracy, faithfulness, safety, cost, latency.
- Run **adversarial red-teaming**: prompt injection, malformed inputs, jailbreaks, edge cases.
- Document failure modes and define fallbacks for each.

**Exit gate:** all promotion thresholds cleared; sign-off by Meridian + customer owner.

### Stage 4 — Deploy with control
- **Shadow mode:** agent runs in parallel, outputs reviewed, no live effect.
- **Canary:** small % of live traffic, human approval on consequential actions.
- **Full production:** ramped once live metrics hold; kill-switch armed.
- Every release is versioned with one-click rollback.

**Exit gate:** canary metrics within thresholds; runbook and on-call in place.

### Stage 5 — Operate & hand over
- Live monitoring, drift detection, continuous online evaluation.
- Weekly quality review; incidents handled per §10.
- Progressive ownership transfer: **Meridian-run → co-managed → customer-owned**, each with a defined checklist and training.

**Exit gate (optional):** customer team certified to operate; support tier agreed.

---

## 3. Building the harness (the agent runtime)

The harness is the core of the platform and the primary IP. It is the controlled
environment in which agents think and act.

### 3.1 Orchestrator
- Executes the agent loop (plan → act → observe → repeat) with hard limits on steps, wall-clock, and spend.
- Supports **single-agent** and **multi-agent** topologies (e.g. a supervisor delegating to specialist agents — Intake, Eligibility, Proposal, Rebate for the energy pipeline).
- Deterministic control flow where possible; the model decides only what genuinely needs judgment.
- Durable execution: long-running workflows checkpoint and resume; no lost state on restart.

### 3.2 Tool layer
- Every tool is a **typed contract**: name, description, JSON-schema input/output, permission scope, rate limit, timeout.
- **Least privilege by default** — a tool exposes exactly one capability (e.g. `lookup_incentive_rate`, not `query_database`).
- Pre- and post-conditions validated in code; malformed model output never reaches a downstream system.
- Tools are individually versioned and independently testable.

### 3.3 Memory & context engineering
- **Short-term:** scoped working memory per run, discarded or retained per policy.
- **Long-term:** retrieval over customer knowledge (programs, rulebooks, past projects) via the RAG layer (§2/integration), with source citations surfaced to reviewers.
- Strict **tenant isolation**: an agent can only retrieve within its customer's namespace.
- **Context engineering.** We treat the context window as a finite *attention budget* — model recall degrades as tokens grow ("context rot"), so we curate the smallest high-signal token set rather than stuffing everything in. Techniques: **just-in-time retrieval** (agents hold lightweight references — IDs, file paths, queries — and load data at runtime), **compaction** (summarize a near-full context and reinitiate), **structured note-taking** (persist working notes outside the window), and **sub-agent summaries** (specialists return a distilled ~1–2k-token result). ([Anthropic, *Effective context engineering*](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents))

### 3.4 Guardrails / policy engine
- Runs **before** (input) and **after** (output) every step.
- Enforces: PII detection/redaction, allowed-action lists, spend caps, business-rule checks, output schema validation, and content safety.
- Policies are declarative, versioned, and testable in isolation.

### 3.5 Human-in-the-loop (HITL)
- Any action tagged high-consequence pauses and routes to the **review queue**.
- Reviewers approve, edit, or reject; the decision and reviewer identity are logged.
- Configurable per action, per risk tier, per customer.

### 3.6 Model gateway
- Single interface to multiple model providers; routing by task, cost, and latency.
- **Prompt registry**: prompts are versioned artifacts with owners and changelogs.
- Response caching, retries with backoff, structured-output enforcement, token/cost accounting per call.
- Provider-agnostic so a model can be swapped without touching agent logic; **fallback model** on provider outage.

---

## 4. Testing & validation

Agents are treated as critical software. Evaluation is continuous, not a launch checkbox.

### 4.1 The evaluation framework
- **Golden datasets** — curated real cases with verified-correct outcomes; the ground truth.
- **Metrics** — task accuracy, factual faithfulness/grounding, completeness, safety/policy adherence, latency (p50/p95), cost per run, and **trajectory quality** (tool-selection correctness, step efficiency; see §4.6).
- **Automated judges** — model-graded rubrics for open-ended outputs, calibrated against human labels.
- **Human evaluation** — expert review on a sampled slice; the calibration anchor for the judges.

### 4.2 Test tiers
| Tier | What it covers | When it runs |
|---|---|---|
| Unit | Individual tools, parsers, validators, policies | Every commit (CI) |
| Component | A single agent against golden datasets | Every commit (CI) |
| Integration | Multi-agent + real connectors in staging | Pre-release |
| Regression | Full golden suite re-scored | Every prompt/tool/model change |
| Adversarial | Red-team attack library | Pre-release + scheduled |
| Online | Sampled production runs scored live | Continuous |

### 4.3 Adversarial red-teaming
- Standing attack library: prompt injection (direct + indirect via retrieved content), jailbreaks, malformed/hostile inputs, data-exfiltration attempts, tool-abuse, and boundary/edge cases.
- Every discovered failure becomes a **permanent regression test**.
- Aligned to the **OWASP Top 10 for LLM Applications**.

### 4.4 Promotion gates
- Explicit, shared thresholds per metric. A regression on any gate **blocks** promotion.
- Cost and latency are first-class gates, not afterthoughts.

### 4.5 Online (production) evaluation
- Continuous sampling of live runs, scored by judges + humans.
- **Drift detection** on inputs and outputs; alerting on quality, cost, or safety regressions.
- Feedback loop: production failures flow back into golden datasets and red-team library.

### 4.6 Trajectory (agent-path) evaluation
- We score not just the **final output** but the **trajectory** — did the agent choose the right tools, in a sensible order, without wasted or unsafe steps? Output-only evaluation misses agents that reach a correct answer the wrong way (and will fail the next case).
- Per-step assertions on tool selection, arguments, and intermediate state; tool-call success/error rates and step counts tracked as first-class metrics.
- A candid note: agent evaluation is still the industry's weakest link — current methods under-cover cost-efficiency, safety, and robustness ([Survey on Evaluation of LLM-based Agents, arXiv 2503.16416](https://arxiv.org/abs/2503.16416)) — so we treat the eval suite as a living asset, not a finished one.

---

## 5. Deployment pipelines

Standard software-delivery rigor, applied to agents — where an unreviewed change carries
higher stakes.

**Where agents actually run — the runtime.** An agent isn't a script we hand over; it runs on
an **agent runtime** — an always-on cloud service that keeps the agent alive, persists its
state, retries on failure, scales, and supports human-in-the-loop. We stand on a **managed
runtime** rather than build hosting from scratch: AWS **Bedrock AgentCore**, Google **Vertex AI
Agent Engine**, Azure **AI Foundry Agent Service**, **Cloudflare** Agents/Workers, or
**LangGraph Platform**. Our harness (§3) and agents are deployed *onto* that runtime — the
runtime is rented; the harness and agents are ours (see the build-vs-buy split in §5.5).

### 5.1 Environments
`local → staging → production`, each tenant-isolated, with synthetic data in lower
environments and no production secrets outside production.

### 5.2 CI (continuous integration)
On every change: lint, type-check, unit + component tests, security scan (SAST, dependency
/ SBOM, secret scanning), and the **evaluation suite**. Red build blocks merge.

### 5.3 CD (continuous delivery) — "AgentOps"
This build → evaluate → deploy → monitor → improve loop for agents is what the industry now
calls **AgentOps** (CI/CD for agents): the same discipline as software delivery, plus a
mandatory eval gate and human oversight before anything ships.

- **Versioned artifacts** — prompts, tools, models, policies, and configs are all versioned and content-addressed. Any production state is reproducible.
- **Progressive rollout** — shadow → canary → full, with automatic promotion only while live metrics hold. Because agents are **stateful and errors compound**, we prefer **rainbow deployments** (shift traffic to a new version while the old one keeps running, so in-flight agents finish undisrupted) and **resume-from-failure** (checkpoint and continue, not restart) over hard cutovers. ([Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system))
- **Instant rollback** — one action to revert; **kill-switch** to pause an agent or a single capability with no deploy.
- **Change management** — every release is attributable to a person and a reviewed change; production changes are approved and logged (supports SOC 2 change-management controls).

### 5.4 Infrastructure
- Infrastructure-as-code, immutable deploys, containerized runtime.
- Secrets in a managed vault, never in code or images.
- Network segmentation between tenants and between environments.

### 5.5 Reference stack (build vs buy)
A deliberate split — **rent the commodities, build the differentiators.**

| Layer | Choice | Build or buy |
|---|---|---|
| Model (the intelligence) | Anthropic Claude, via API | **Buy** |
| Agent runtime (hosting) | AWS Bedrock AgentCore / Cloudflare / LangGraph Platform | **Buy** |
| Framework (agent logic) | Claude Agent SDK / LangGraph | Buy |
| **Harness** (tools, guardrails, HITL, audit) | Meridian | **Build — core IP** |
| **Agents** (per-workflow) | Meridian | **Build — core IP** |
| **AgentOps pipeline** (eval gate, canary, rollback) | Meridian | **Build — core IP** |
| Evals & observability | Braintrust / LangSmith + OpenTelemetry | Buy |
| Data & secrets | Postgres / managed vault | Buy |

We rent the model and the runtime from the hyperscalers; Meridian's value — and what a customer
pays for — is the **harness, the agents, and the AgentOps pipeline** wrapped around them.

---

## 6. Compliance & audit — the enterprise bar

The platform is built to pass an enterprise security review on day one, not after an
incident. This section is the controls narrative a customer's GRC team will ask for.

### 6.1 Frameworks in scope
| Framework | Relevance | Posture |
|---|---|---|
| **SOC 2 Type II** | Security, availability, confidentiality, processing integrity | Controls built in; readiness → audit on roadmap |
| **GDPR / CCPA** | Personal-data processing, data-subject rights | Data map, DPA, DSAR process, minimization |
| **NIST AI RMF** | AI risk management (Govern/Map/Measure/Manage) | Adopted as our AI governance backbone |
| **EU AI Act** | Risk-tiering of AI systems | Per-workflow risk classification; high-risk controls where applicable |
| **ISO 27001 / 42001** | InfoSec & AI management systems | Aligned; certification is a later-stage roadmap item |
| **OWASP LLM Top 10** | Application-level LLM threats | Mapped into red-team + guardrails |

### 6.2 Audit logging (non-negotiable)
- **Immutable, tamper-evident** append-only log of: every input, model call, tool invocation, policy decision, human approval/override, and configuration change.
- Each record carries: actor (human or agent), tenant, timestamp, artifact versions, inputs/outputs (or hashes where sensitive), and decision rationale.
- **Full replay:** any past run can be reconstructed end-to-end. This is what makes "show me why the agent did X" answerable — for a customer, a utility, or an auditor.
- Defined **retention** and legal-hold support; logs are access-controlled and monitored.

### 6.3 Data protection
- Encryption **in transit** (TLS 1.2+) and **at rest** (AES-256).
- **Tenant isolation** at data, retrieval, and compute boundaries.
- **PII handling:** classification, minimization, redaction before model calls where feasible, and configurable data-residency.
- **Model-provider data terms:** contractual no-training-on-customer-data; zero-retention endpoints where available.
- Data lifecycle: retention schedules, deletion on request, and clean **offboarding export + purge**.

### 6.4 AI-specific governance (per NIST AI RMF)
- **Govern:** an AI policy, named owners, and a model/agent inventory (registry of every deployed agent, its purpose, data, and risk tier).
- **Map:** per-workflow risk assessment (impact, autonomy level, affected parties, failure consequences) → risk tier → required controls.
- **Measure:** the evaluation framework (§4) provides ongoing evidence of performance and safety.
- **Manage:** HITL, guardrails, rollback, incident response, and periodic review of each agent.

### 6.5 Controls matrix (illustrative)
| Control area | Control | Evidence |
|---|---|---|
| Access | RBAC, SSO/SAML, MFA, least privilege | IdP config, access reviews |
| Change mgmt | Peer review + approval on all releases | PR + release records |
| Audit | Immutable log of all agent actions | Replayable run records |
| Data | Encryption, isolation, retention, deletion | Data map, DPA, purge logs |
| Model risk | Eval gates + red-team + online monitoring | Eval reports, drift alerts |
| Human oversight | Approval gates on high-risk actions | Review-queue logs |
| Vendor mgmt | Sub-processor list + provider data terms | DPAs, sub-processor register |
| Resilience | Backups, DR, provider failover | DR test results |
| Vuln mgmt | SAST/DAST, dependency + secret scanning, pen test | Scan + pen-test reports |
| IR | Documented incident + breach process | Runbooks, post-mortems |

### 6.6 Legal & contractual (the paper)
- **MSA** — master services agreement.
- **DPA** — data processing agreement (roles, sub-processors, SCCs where relevant).
- **SLA** — availability, response, and support commitments.
- **IP & ownership** — explicit terms: customer owns its data and outputs; ownership of custom agents and configs defined; no training on customer data.
- **AUP & shared-responsibility model** — what Meridian secures vs. what the customer secures.
- **Sub-processor register** — model providers, hosting, and tooling, with notification on change.
- **Certifications & questionnaires** — SOC 2 report, security whitepaper, and standard responses (SIG/CAIQ) available under NDA.

---

## 7. Security architecture (cross-cutting)

- **Identity:** SSO (SAML/OIDC), MFA, SCIM provisioning; separate identities for humans and agents (agent credentials are scoped and short-lived).
- **Secrets:** centralized vault, rotation, no secrets in code/images/logs.
- **Network:** segmentation by tenant and environment; private connectivity options for enterprise customers.
- **Application:** input validation everywhere, output encoding, dependency and container scanning, SBOM.
- **AI-specific threats:** prompt-injection defenses (input sanitization, retrieved-content quarantine, output constraints), tool-abuse limits, and spend/rate caps to bound blast radius.
- **Testing:** periodic third-party penetration testing; bug-bounty as the platform matures.
- **Monitoring:** security logging into SIEM, anomaly alerting, and access-review cadence.

---

## 8. Team support, multi-tenancy & onboarding

The platform is a product the customer's team logs into — not a black box.

### 8.1 Multi-tenancy
- Hard tenant isolation across data, retrieval, secrets, and audit logs.
- Per-tenant configuration of agents, policies, thresholds, and connectors.

### 8.2 Roles & access (RBAC)
| Role | Can |
|---|---|
| **Owner / Admin** | Manage users, roles, billing, connectors, and policies |
| **Builder** | Configure agents, tools, prompts (in non-prod), request promotion |
| **Reviewer** | Approve/edit/reject actions in the review queue |
| **Operator** | Run agents, monitor, handle day-to-day |
| **Auditor (read-only)** | View logs, evals, and configs — no changes |

### 8.3 Onboarding
- Guided setup: connect systems, configure roles, import knowledge.
- **Role-based training** and runbooks written for operators, not just engineers.
- In-product guidance and a sandbox for safe practice.
- Certification path so a customer team can graduate to **owning** its agents.

### 8.4 Experience surfaces
- **Console** — manage agents, versions, and policies.
- **Review queue** — the HITL workspace for approvals.
- **Dashboards** — throughput, quality, cost, and SLA at a glance.
- **Audit explorer** — search and replay any run.

---

## 9. Observability & FinOps

- **Traces** for every agent run (steps, tool calls, tokens, latency), **metrics** (quality, cost, throughput, SLA), and **structured logs**, unified on one control plane.
- **Standards-based instrumentation:** we emit **OpenTelemetry GenAI semantic conventions** — an `invoke_agent` → `chat` → `execute_tool` span tree with standard attributes (`gen_ai.request.model`, `gen_ai.usage.*`) and token/latency metrics — so traces are portable across vendors, drive per-request cost attribution, and catch token-hungry prompts before they reach production. ([OpenTelemetry](https://opentelemetry.io/blog/2026/genai-observability/))
- **Cost governance:** per-run, per-agent, and per-tenant spend tracking; budgets and alerts; prompt caching (large savings on repeated prefixes) and model-routing to control unit economics.
- **Quality telemetry:** online eval scores and drift, surfaced to the workflow owner with alerting.

---

## 10. Reliability & incident response

- **SLOs** per agent/service; error budgets tracked.
- **Resilience:** backups, tested disaster recovery, and model-provider failover.
- **Incident response:** severity levels, on-call rotation, documented runbooks, customer comms, and blameless post-mortems.
- **Breach process:** detection, containment, notification obligations (GDPR 72-hour awareness), and remediation.
- **Business continuity:** graceful degradation — an agent can fall back to human handling rather than failing the workflow.

---

## 11. Enterprise-readiness gap analysis

An honest view of what "enterprise-grade with no gaps" requires, and the current posture.
Priorities: **P0** = required before first production customer data; **P1** = required to
scale to multiple enterprise customers; **P2** = maturity/differentiation.

| Area | Requirement | Priority | Notes |
|---|---|---|---|
| Audit logging | Immutable, replayable log of all agent actions | **P0** | Core to the value prop; build first |
| Access control | RBAC + SSO + MFA, least privilege | **P0** | Table stakes for any enterprise |
| Data protection | Encryption, tenant isolation, retention/deletion | **P0** | Required before real data |
| HITL | Approval gates on high-risk actions | **P0** | Non-negotiable for regulated work |
| Eval framework | Golden datasets + gates + regression | **P0** | Gate for shipping anything |
| Deployment | Versioning, canary, rollback, kill-switch | **P0** | Prevents silent regressions |
| Guardrails | PII, policy, spend caps, injection defense | **P0** | Bounds blast radius |
| Legal | MSA, DPA, SLA, IP terms, sub-processor list | **P0** | Blocks enterprise procurement without it |
| Online eval | Continuous production scoring + drift | **P1** | Needed as volume grows |
| SOC 2 Type II | Readiness → external audit | **P1** | Enterprise procurement gate |
| Multi-tenancy | Full isolation + per-tenant config | **P1** | Required to serve client #2+ |
| Onboarding | Roles, training, self-serve setup | **P1** | Enables team support & handover |
| Pen testing | Third-party test + remediation | **P1** | Expected in security reviews |
| DR / BCP | Tested backups and failover | **P1** | Availability commitments |
| ISO 27001/42001 | Certification | **P2** | Later-stage trust signal |
| Bug bounty | Public/managed program | **P2** | Maturity signal |
| EU AI Act high-risk | Conformity docs where applicable | **P2** | Only if workloads are in scope |

**Bottom line:** the P0 set is what separates a demo from something a utility-facing,
public-entity-serving business can put its name behind. It is the first build.

---

## 12. Delivery & engagement model

How Meridian engages, prices, and hands over — the operating model behind the platform.

- **Forward-deployed delivery.** Engineers embed with the customer's team to map the real
  workflow and ship the first version *in situ*, rather than handing a spec over the wall —
  the delivery motion that made agent implementations succeed at forward-deployed-engineer
  consultancies.
- **Land narrow, expand on proof.** Start with one high-friction workflow, prove it against
  agreed metrics, then expand to adjacent workflows on the same governed platform.
- **Pricing — three shapes, chosen per engagement:** a fixed-fee **build** (scoped first
  workflow); a **platform subscription** (per-seat / per-tenant for the harness, console, and
  ongoing operation); and, where outcomes are cleanly measurable, **outcome-based pricing**
  tied to a defined unit of work (e.g. a completed, filed rebate). Outcome pricing is the
  fastest-growing model for agent products, but it demands airtight measurement and attribution.
- **Handover, contractually.** Ownership transfers on a defined path — Meridian-run →
  co-managed → customer-owned — with training, runbooks, and a certification checklist, so the
  customer is never trapped in a dependency.
- **Operating requirements for a services + platform company:** a repeatable discovery kit, a
  reusable tool/component library so each engagement compounds, an on-call/SRE function for the
  agents we operate, and a clear internal line between per-customer work and shared platform IP.

---

## 13. Build roadmap (phased)

**Phase 0 — Foundations (weeks 1–4)**
Identity/SSO, tenancy, secrets, encryption, the immutable audit log, and the model gateway.
The non-negotiable base every agent stands on.

**Phase 1 — Harness & first agent (weeks 3–8, overlapping)**
The runtime, tool layer, guardrails, HITL, and the evaluation framework — proven by shipping
the client's **Assessment Intake + Incentive Eligibility** steps to shadow, then canary.

**Phase 2 — Pipeline & remaining pipeline steps (weeks 8–14)**
CI/CD with versioning, canary, and rollback; Proposal, Rebate, and Coordination agents to
production; online evaluation and dashboards.

**Phase 3 — Enterprise hardening (weeks 12–20)**
SOC 2 readiness, pen test, DR testing, sub-processor register, and the full legal pack.

**Phase 4 — Multi-tenant & team enablement (weeks 18+)**
Full multi-tenancy, self-serve onboarding, role-based training, and the ownership-handover
path — the platform ready for the next client and for the client's own team to operate.

---

*Prepared by Meridian. This is a living document; controls and roadmap are reviewed each phase.*