Architecture & compliance dossier · v0.1
The blueprint, in the open.
The engineering and compliance plan for the Meridian platform — the system we use to design, build, test, deploy, operate, and govern enterprise AI agents. Written to be handed to an engineering lead or a security reviewer without edits.
Reference architecture
The platform is organized into seven layers. Each is independently ownable, testable, and auditable — with observability, security, and cost control cutting across all of them.
| Layer | Responsibility |
|---|---|
| 7 · Experience | Console, review queue, dashboards, onboarding |
| 6 · Governance | Policy engine, approvals, audit log, RBAC |
| 5 · Agent runtime (the harness) | Orchestrator, tools, memory, human-in-the-loop |
| 4 · Model gateway | Provider routing, prompt registry, caching |
| 3 · Evaluation | Datasets, offline evals, online scoring, red-team |
| 2 · Integration | Connectors, data contracts, ingestion, retrieval |
| 1 · Foundation | Identity, secrets, encryption, tenancy, infra |
Design tenets
- Prefer the simplest architecture that clears the bar. A workflow beats an agent; a single agent beats a swarm. Autonomous multi-agent systems can burn ~15× the tokens of a chat, so we reserve them for high-value, parallelizable work — knowing when not to use an agent is part of the job.
- Every capability is a permissioned tool. Agents never get raw access — only typed, scoped, rate-limited, logged tools.
- Deterministic scaffolding around non-deterministic cores. Validation and business rules are ordinary, testable code; the model is one component, not the system.
- Nothing ships unmeasured. Promotion is gated on evaluations — of the output and the trajectory taken — not opinion.
- Everything is reproducible and attributable to a versioned artifact, a change, and a person.
- Humans own consequences. High-impact actions require explicit approval.
Rolling out agents
A repeatable five-stage lifecycle governs every agent from idea to ownership, containing risk and making value provable at each gate.
- Scope & discovery. Shadow the workflow, quantify the baseline, map data and system access, classify each decision as automate / assist / escalate, and agree promotion thresholds in writing.
- Build on the harness. Define the agent, its tools, prompts, and policies as versioned, peer-reviewed artifacts; wrap non-deterministic steps in deterministic checks.
- Evaluate & harden. Assemble golden datasets from real cases, run offline evals and adversarial red-teaming, document failure modes and fallbacks.
- Deploy with control. Shadow → canary → full production, with human approval on consequential actions, a kill-switch, and one-click rollback.
- Operate & hand over. Monitor, run continuous online evaluation, and progressively transfer ownership: Meridian-run → co-managed → customer-owned.
The harness (agent runtime)
The harness is the controlled environment in which agents think and act — the platform's core IP.
Orchestrator
Runs the plan–act–observe loop with hard limits on steps, time, and spend. Supports single- and multi-agent topologies — e.g. for the energy-efficiency pipeline, a supervisor delegating to Intake, Eligibility, Proposal, and Rebate specialists. Durable execution checkpoints long workflows so no state is lost on restart.
Tool layer
Every tool is a typed contract — name, schema'd I/O, permission scope, rate limit, timeout — exposing exactly one least-privilege capability (lookup_incentive_rate, not query_database). Pre- and post-conditions are validated in code, so malformed model output never reaches a downstream system.
Memory, context & guardrails
Scoped short-term memory per run; long-term retrieval over customer knowledge with source citations and strict tenant isolation. Context engineering treats the window as a finite attention budget — just-in-time retrieval, compaction, and structured note-taking keep the high-signal tokens in and the noise out. A declarative policy engine runs before and after every step — PII redaction, allowed-action lists, spend caps, business-rule and schema checks.
Human-in-the-loop & model gateway
High-consequence actions pause and route to a review queue where a person approves, edits, or rejects — every decision logged. A provider-agnostic model gateway handles routing, a versioned prompt registry, caching, structured-output enforcement, cost accounting, and fallback on provider outage.
Testing & validation
Agents are treated as critical software; evaluation is continuous, not a launch checkbox.
| Tier | Covers | Cadence |
|---|---|---|
| Unit | Tools, parsers, validators, policies | Every commit |
| Component | One agent vs. golden datasets | Every commit |
| Integration | Multi-agent + real connectors | 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 | Continuous |
Metrics span accuracy, faithfulness/grounding, completeness, safety, latency, and cost — scored by calibrated automated judges anchored to human review. Adversarial testing covers prompt injection (direct and via retrieved content), jailbreaks, hostile inputs, and tool-abuse, aligned to the OWASP Top 10 for LLM Applications; every finding becomes a permanent regression test. Explicit, shared promotion gates — including cost and latency — must be cleared to ship, and drift is monitored continuously in production. We evaluate the trajectory, not just the final answer — tool-selection correctness, step efficiency, and path safety — because an agent can reach a right answer the wrong way and fail the next case.
Deployment pipelines
Agents run on a managed agent runtime in the cloud — AWS Bedrock AgentCore, Cloudflare, Google Vertex AI Agent Engine, or LangGraph Platform — with our harness and agents deployed on top. The runtime is rented; the harness and agents are ours. On top of that, standard software-delivery rigor applies, where an unreviewed change carries higher stakes.
- Environments: local → staging → production, tenant-isolated, with no production secrets outside production.
- CI: lint, type-check, unit/component tests, security scans (SAST, dependency/SBOM, secret scanning), and the eval suite — a red build blocks merge.
- Versioned artifacts: prompts, tools, models, policies, and configs are all versioned and content-addressed; any production state is reproducible.
- Progressive rollout: shadow → canary → full, promoting only while live metrics hold — via rainbow deployments (both versions run so in-flight agents finish undisrupted) and resume-from-failure, since agents are stateful and errors compound.
- Instant rollback & kill-switch: revert or pause a single capability with no deploy.
- Change management: every release is reviewed, approved, and attributable — supporting SOC 2 change controls.
- Observability: traces, metrics, and logs on one control plane, emitted with OpenTelemetry GenAI semantic conventions (an
invoke_agent → chat → execute_toolspan tree) so telemetry is portable and drives cost/FinOps attribution. - AgentOps: the build → eval → deploy → monitor → improve loop (CI/CD for agents) — an eval gate must pass before anything ships to the runtime.
Compliance & audit
The platform is built to pass an enterprise security review on day one — not after an incident.
| Framework | Posture |
|---|---|
| SOC 2 Type II | Controls built in; readiness → external audit on roadmap |
| GDPR / CCPA | Data map, DPA, DSAR process, data minimization |
| NIST AI RMF | Adopted as the AI governance backbone |
| EU AI Act | Per-workflow risk-tiering; high-risk controls where applicable |
| ISO 27001 / 42001 | Aligned; certification is a later-stage item |
| OWASP LLM Top 10 | Mapped into red-team + guardrails |
Audit logging — non-negotiable
An immutable, tamper-evident, append-only log captures every input, model call, tool invocation, policy decision, human approval, and config change — each with actor, tenant, timestamp, artifact versions, and rationale. Any past run can be replayed end to end. That is what makes "show me why the agent did X" answerable for a customer, a utility, or an auditor. Retention and legal-hold are defined; logs are access-controlled and monitored.
Data protection
Encryption in transit (TLS 1.2+) and at rest (AES-256); tenant isolation across data, retrieval, and compute; PII classification, minimization, and redaction before model calls where feasible; contractual no-training-on-customer-data with zero-retention endpoints where available; and clean offboarding export and purge.
AI governance (NIST AI RMF)
- Govern: an AI policy, named owners, and a registry of every deployed agent — its purpose, data, and risk tier.
- Map: a per-workflow risk assessment (impact, autonomy, affected parties, failure consequences) that sets the risk tier and required controls.
- Measure: the evaluation framework provides ongoing evidence of performance and safety.
- Manage: human-in-the-loop, guardrails, rollback, incident response, and periodic review of each agent.
Autonomy without accountability isn't enterprise-ready — it's a liability. Every control here exists to make an agent's actions provable.
Contracts & integrations
The legal and connective tissue enterprise procurement requires:
- MSA, DPA, SLA — services, data processing (with SCCs where relevant), and availability/support commitments.
- IP & ownership — the customer owns its data and outputs; custom-agent ownership is defined; no training on customer data.
- Shared-responsibility model — a clear line between what Meridian secures and what the customer secures.
- Sub-processor register — model providers, hosting, and tooling, with change notification.
- Assurance pack — SOC 2 report, security whitepaper, and SIG/CAIQ responses available under NDA.
- Connectors — typed integrations to the systems the work already lives in, each with a documented data contract.
Team support & onboarding
The platform is a product the customer's team logs into — with hard multi-tenant isolation and per-tenant configuration.
| Role | Can |
|---|---|
| Owner / Admin | Manage users, roles, billing, connectors, policies |
| Builder | Configure agents/tools/prompts (non-prod), request promotion |
| Reviewer | Approve, edit, or reject actions in the review queue |
| Operator | Run agents, monitor, handle day-to-day |
| Auditor | Read-only access to logs, evals, and configs |
Onboarding is guided — connect systems, set roles, import knowledge — with role-based training and runbooks written for operators, a safe sandbox, and a certification path so a customer team can graduate to owning its agents.
Delivery & engagement model
How we engage, price, and hand over — the operating model behind the platform.
- Forward-deployed delivery — engineers embed with your team to map the real workflow and ship the first version in situ, not a spec over the wall.
- Land narrow, expand on proof — one high-friction workflow first, proven against agreed metrics, then adjacent workflows on the same platform.
- Pricing, chosen per engagement — a fixed-fee build, a platform subscription (per-seat / per-tenant), or outcome-based pricing tied to a defined unit of work where it's cleanly measurable.
- Contractual handover — Meridian-run → co-managed → customer-owned, with training and a certification checklist so you're never trapped in a dependency.
Enterprise-readiness gap analysis
An honest view of what "enterprise-grade, no gaps" requires. P0 = required before first production customer data; P1 = required to scale to multiple enterprises; P2 = maturity.
| Requirement | Priority |
|---|---|
| Immutable, replayable audit log | P0 |
| RBAC + SSO + MFA, least privilege | P0 |
| Encryption, tenant isolation, retention/deletion | P0 |
| Human-in-the-loop approval gates | P0 |
| Eval framework + promotion gates | P0 |
| Versioning, canary, rollback, kill-switch | P0 |
| Guardrails (PII, policy, spend, injection) | P0 |
| MSA, DPA, SLA, IP terms, sub-processors | P0 |
| Online eval + drift detection | P1 |
| SOC 2 Type II (readiness → audit) | P1 |
| Full multi-tenancy + per-tenant config | P1 |
| Onboarding, roles, training | P1 |
| Third-party penetration test | P1 |
| Tested DR / business continuity | P1 |
| ISO 27001 / 42001 certification | P2 |
| Bug-bounty program | P2 |
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.
Build roadmap
- Phase 0 · Foundations (wk 1–4): identity/SSO, tenancy, secrets, encryption, immutable audit log, model gateway.
- Phase 1 · Harness & first agent (wk 3–8): runtime, tools, guardrails, HITL, and eval framework — proven by shipping the energy client's Assessment Intake + Eligibility steps to shadow, then canary.
- Phase 2 · Pipeline & remaining agents (wk 8–14): CI/CD with versioning, canary, rollback; Proposal, Rebate, and Coordination agents to production; online eval and dashboards.
- Phase 3 · Enterprise hardening (wk 12–20): SOC 2 readiness, pen test, DR testing, sub-processor register, full legal pack.
- Phase 4 · Multi-tenant & enablement (wk 18+): full multi-tenancy, self-serve onboarding, training, and the ownership-handover path — ready for client #2.
This is a living document — controls and roadmap are reviewed each phase. The complete version is available as ARCHITECTURE.md.
Bring your reviewers
We'd rather answer the hard questions early.
Send us your security questionnaire and your toughest workflow. We'll bring the evidence.