PrimeSwarm

Overview

PrimeSwarm is a production-grade autonomous agent orchestration platform built in Rust. It provides a complete cognitive API for deploying, governing, and monitoring AI agents in enterprise environments. The core thesis is that agent safety must come from mathematical constraint, not post-hoc monitoring — unsafe actions should be physically incapable of forming, not just flagged after execution.

The 10-Layer Governance Stack

No competing framework (LangChain, AutoGPT, CrewAI, OpenAI Assistants) offers more than 3 of these capabilities. PrimeSwarm offers all 10:

1. PII Sanitization — SSNs, account numbers, and NPI are stripped from context before agent interaction, replaced with cryptographic hashes
2. Adversarial Defense — TPNN spatial constraints prevent prompt injection attacks from forming valid output vectors
3. Fairness Gates — Automatic Adverse Impact Ratio calculation using the Four-Fifths Rule. Swarms trigger Pre-Effect Refusal if bias is mathematically detected
4. Human-in-the-Loop Approval — Swarms with convergence scores below 98% halt and enter a secure queue for cryptographic sign-off
5. Cryptographic Audit Receipts — HelixDB captures the exact vector state and topology at execution, creating immutable receipts
6. SIEM Integration — Real-time security event forwarding to Splunk and Datadog
7. Zero-Trust JWT Authentication — Every API call authenticated with JWT tokens and RBAC
8. GDPR Retention — Session data with configurable retention policies
9. Hardened Sandboxing — Docker with 6 security layers plus WASM backend for code execution
10. MCP Tool Protocol — Pluggable external tools via JSON-RPC 2.0 with declarative configuration

Architecture

The system is built on Axum (Rust web framework) with Tokio async runtime. Agents are defined declaratively in a catalog (YAML), and the cognitive API handles:

• Session management — durable sessions with resume capability
• Streaming chat completions — SSE-based real-time token streaming
• Tool execution — sandboxed Docker/WASM execution with resource limits
• Governance pipeline — every request passes through all 10 layers before reaching the model
• Durable agent memory — Continuity Ledger (SQLite, WAL mode) + EMR consolidation pipeline

Durable Agent Memory (Continuity Ledger + EMR)

Agents now remember across sessions with governed memory instead of chat dumps:

• Continuity Ledger — SQLite-backed durable store with WAL mode and foreign-key checks. Memory records carry type (decision/evidence/architecture), status (draft/verified/archived), confidence, provenance weights, and canonical SHA-256 Ghost Matrix receipts
• EMR Pipeline — consolidation with Ebbinghaus forgetting-curve decay (decisions age faster than architecture), token-budgeted short-term memory, and abstention gating — when evidence is ambiguous, agents abstain rather than confabulate
• Conflict detection — new claims that contradict prior records surface conflicts instead of silently overwriting; supersession lineage is tracked
• Reinforcement Sidecar — prevents "recalled often = truth" bias by separating reinforcement signals from evidence strength
• MCP memory tools — emr_remember, emr_recall, emr_upsert for governed memory operations over the MCP tool protocol

Spatial XR Command Center

A Dual-Front conversational intelligence surface with five governed agent cores:

• Visual Intelligence — aesthetic/design analysis; emits VISUAL_HANDOFF_V1 when a visual brief is complete
• Structural Intelligence — diagrams, hierarchy, Mermaid/topology analysis
• Linguistic Intelligence — forensic analysis, threat decode, negotiation (TPNN-governed)
• Strategic Analyst — OODA-loop reasoning: Observe, Orient, Decide, Act
• Systemic Analyst — policy/movement analysis, cognitive firewall

Every routing decision emits a Ghost Matrix receipt. The VISUAL_HANDOFF_V1 token enforces a byte-stable completion phrase plus SHA-256 prompt hash — paraphrases are rejected, so the render lane can never reinterpret a visual brief. Secure wipe consolidates decisions to the Continuity Ledger (fail-closed without explicit user request) rather than persisting chat transcripts.

Testing & Deployment

27 end-to-end integration tests cover all endpoints, governance gates, authentication flows, memory pipeline durability (TPNN redaction, conflict detection, supersession lineage), and Spatial XR routing/handoff/export/secure-wipe. Helm chart with Horizontal Pod Autoscaler for Kubernetes deployment. The TypeScript React UI SDK provides streaming chat components with session resume.

Regulated Industry Pathways

PrimeSwarm is built for regulated industries where every AI decision must be auditable, every output must be traceable, and every failure must fail closed. The five pathways below are the most common adoption patterns we see across finance, medical, and legal sectors. Each one is a pre-validated configuration of the governance stack, tuned to the regulatory constraints of that domain, and deployable in weeks rather than quarters.

Finance — Algorithmic Trading & Risk Decisioning

The problem. A trading desk or lending platform wants to use LLM-driven analysis for trade signals, risk scoring, or customer-facing financial advice. Regulators (SEC, FCA, MiFID II) require explainability, audit trails, and the ability to reconstruct any decision after the fact. A hallucinated trade signal or an unexplainable denial is a reportable incident.

What we deploy.

• Governance stack — PII redaction, prompt-injection defense, and fairness gates tuned to fair-lending constraints (ECOA, CFPB). Every trade signal or risk score passes through all 10 governance layers before reaching the model.
• Deterministic receipts — every decision emits a Ghost Matrix SHA-256 receipt capturing the exact prompt, model, gate states, and output. These receipts are the audit trail. They are tamper-evident and replayable.
• DGV verification — the same DGV test cards you can see in the registry are run against the deployed configuration before go-live. The client receives a signed verification report listing which test cards passed, which escalated to HITL, and which were denied.

Setup process.

1. Technical (weeks 1–3) — We map the client's existing decision flow (trade signal pipeline, risk model, customer-facing chatbot) to the PrimeSwarm governance pipeline. This includes defining the ONLY Lang governance scripts that encode the client's specific compliance rules, configuring the fairness gates against their protected-class definitions, and wiring the receipt store to their existing audit infrastructure (Splunk, Datadog, or direct SIEM feed).
2. Hosting (week 4) — We deploy to the client's preferred environment. For finance clients this is typically their own VPC (AWS, GCP, or on-prem) behind their existing network controls. The Helm chart deploys to Kubernetes with HPA autoscaling. We configure the Continuity Ledger to use their managed PostgreSQL or SQLite-with-WAL depending on their durability requirements. No data leaves their environment.
3. Maintenance (ongoing) — We provide a quarterly governance review where we re-run the DGV test card suite against the live configuration, review any escalated HITL decisions for patterns, and update ONLY Lang scripts to reflect regulatory changes. The client retains full control of the deployment — we do not hold the keys. Critical updates (new attack patterns, new regulatory requirements) are delivered as versioned ONLY Lang scripts that the client reviews and deploys on their own schedule.

Medical — Clinical Decision Support & Patient Communication

The problem. A hospital system or digital health platform wants to use AI for clinical decision support, patient triage, or patient-facing communication. HIPAA requires PHI protection, the FDA requires traceability for clinical decision support software, and any ungrounded recommendation is a patient safety risk.

What we deploy.

• PHI redaction — the PII/PHI governance layer strips protected health information before it reaches the model. The redaction rules are configurable per the client's data classification (ICD-10 codes, free-text notes, lab results).
• Abstention gating — when evidence is ambiguous, the agent abstains rather than confabulating. This is the EMR pipeline's core safety property: the agent says "I don't have enough evidence" instead of inventing a recommendation. For clinical decision support, this is the difference between a useful tool and a liability.
• HITL escalation — high-stakes decisions (medication interactions, triage escalation, discharge instructions) route to a human reviewer before reaching the patient or the EHR. The HITL flow is auditable: the reviewer's decision is logged with a timestamp and identity.
• Provenance receipts — every clinical recommendation carries a receipt linking it to the source evidence (lab values, clinical guidelines, prior notes). This is the audit trail the FDA expects for clinical decision support software.

Setup process.

1. Technical (weeks 1–4) — We map the clinical workflow (triage, decision support, patient messaging) to the governance pipeline. This is more involved than finance because the abstention rules and HITL thresholds are domain-specific. We work with the client's clinical leadership to define which decision classes require HITL, which require abstention, and which can be automated. The ONLY Lang scripts encode these thresholds. We configure the Continuity Ledger to store clinical memory (prior decisions, patient context) with Ebbinghaus decay tuned to clinical relevance — recent lab values matter more than six-month-old notes.
2. Hosting (week 5) — Medical clients almost universally require on-prem or private-cloud deployment. We deploy to the client's existing HIPAA-compliant infrastructure. The governance stack runs inside their network boundary. No PHI crosses the boundary. If the client uses a cloud LLM provider (Azure OpenAI, AWS Bedrock), we configure the governance stack to call that provider through the client's existing private connectivity (PrivateLink, VPC peering) so PHI never traverses the public internet.
3. Maintenance (ongoing) — Clinical governance is not set-and-forget. We provide a monthly review of HITL escalations, abstention rates, and any near-miss events. We update ONLY Lang scripts when clinical guidelines change (new drug interactions, updated screening protocols). The client's clinical informatics team retains editorial control over the governance scripts — we provide the tooling and the updates, they approve and deploy. Annual re-verification runs the full DGV suite against the live configuration and produces a report for the client's compliance team.

Legal — Contract Analysis & Regulatory Research

The problem. A law firm or legal tech platform wants to use AI for contract review, regulatory research, or client-facing legal guidance. The risks are different from finance and medical: the primary concern is not patient safety or market integrity, but professional liability. A hallucinated citation is malpractice. An ungrounded legal opinion is a disciplinary risk.

What we deploy.

• Provenance-first architecture — every legal claim, citation, or contract clause analysis must trace back to a source document. The governance stack enforces this: the agent cannot emit a legal assertion without a provenance receipt linking it to the source. This is the core differentiator for legal AI — not the model, but the provenance enforcement.
• Boundary enforcement — the agent operates within a defined scope (the matter, the jurisdiction, the document set). It cannot pull in external context or "general legal knowledge" that isn't grounded in the provided sources. This prevents the most common legal AI failure: confident assertions based on training data rather than the actual case.
• Receipt store — every analysis produces a receipt trail that can be presented to a court, a regulator, or a malpractice insurer. The receipt shows what the agent was asked, what sources it used, what it concluded, and what it declined to conclude.

Setup process.

1. Technical (weeks 1–3) — We map the legal workflow (contract review, due diligence, regulatory research) to the governance pipeline. The key configuration is the boundary definition: which document sets the agent can access, which jurisdictions apply, and which assertion classes require human review. We define ONLY Lang scripts that enforce the client's professional responsibility rules (e.g., "do not advise on jurisdictions where the firm is not licensed"). The provenance store is configured to the client's document management system (iManage, NetDocuments, or direct filesystem).
2. Hosting (week 4) — Legal clients typically prefer private-cloud or on-prem deployment due to attorney-client privilege concerns. We deploy to the client's environment with the governance stack running inside their privilege boundary. If the client uses a cloud LLM, we configure it through private connectivity. The receipt store is deployed on the client's infrastructure — we do not retain copies of privileged documents.
3. Maintenance (ongoing) — We provide quarterly governance reviews focused on boundary violations (did the agent ever attempt to pull in out-of-scope sources?), abstention patterns (where did the agent decline to conclude?), and HITL review rates. We update ONLY Lang scripts when the client's practice areas expand or when regulatory changes affect the boundary definitions. The client's knowledge management team retains control of the document sets and the boundary definitions.

Cross-Industry — Internal Knowledge Agents

The problem. A regulated company (any sector) wants to give employees an internal AI assistant for policy questions, internal knowledge lookup, and operational guidance. The risk is that the agent leaks confidential information across business units, gives advice outside its competence, or produces outputs that create regulatory exposure (e.g., an HR agent giving legal advice).

What we deploy.

• Scoped knowledge boundaries — the agent operates within a defined knowledge domain (HR policies, internal engineering docs, compliance procedures). It cannot access documents outside its scope. This is enforced at the governance layer, not at the prompt level.
• Role-based gating — different employee roles see different outputs. An engineer asking about compensation policy gets a different response than an HR business partner asking the same question. The governance stack enforces this before the model sees the prompt.
• Full audit trail — every internal query is logged with the employee's identity, the question, the sources used, and the response. This is the audit trail for internal compliance reviews and for responding to regulator inquiries.

Setup process.

1. Technical (weeks 1–2) — This is the fastest pathway. We map the internal knowledge domains to governance scopes, configure role-based access rules against the client's identity provider (Okta, Azure AD, Google Workspace), and define the boundary scripts. The Continuity Ledger is configured to store organizational memory (policy decisions, prior answers) so the agent improves over time without re-asking the same questions.
2. Hosting (week 3) — Typically private-cloud or on-prem. The governance stack runs inside the corporate network. If the client uses a cloud LLM, we configure private connectivity. The audit trail feeds into the client's existing SIEM.
3. Maintenance (ongoing) — Quarterly review of scope violations, role-gating effectiveness, and knowledge boundary integrity. We update boundary scripts when the client reorganizes or adds new business units. The client's IT team retains control of the identity integration and the document scope definitions.

How We Engage

Every engagement follows the same structure regardless of pathway:

• Discovery (week 0) — We review the client's regulatory constraints, existing infrastructure, and decision workflows. We identify which DGV test cards are relevant to their use case and which governance layers need custom configuration. Output: a deployment plan with a timeline and a verification report template.
• Build (weeks 1–4) — We configure the governance stack, write the ONLY Lang scripts, and run the DGV test card suite against the configuration. The client reviews and approves every governance script before deployment. No script goes live without client sign-off.
• Deploy (week 4–5) — We deploy to the client's environment, configure the receipt store and audit feeds, and run a final verification pass. The client receives a signed verification report listing every test card result.
• Maintain (ongoing) — Quarterly governance reviews, DGV re-verification, and ONLY Lang script updates. The client retains full control of the deployment, the keys, and the governance scripts. We provide tooling and expertise, not a black box.

Related industry pages: Finance & trading · Healthcare · Legal & compliance · Enterprise AI · Accounting & audit

DGV Enforcement Gate Integration

The DGV enforcement gate is the write-path front door for PrimeSwarm deployments: every governed tool call is authorized at proposal time (T₀) and re-checked at execution time (T₁) — permission to act is not continuing authority to act.

What that adds on top of the in-process governance stack:

• Verified identity — JWT/OIDC-bound agent identity; the sub claim is the actor, not a self-declared string
• Signed agent-to-agent envelopes — the A2A pattern PrimeSwarm's multi-agent work needed: Ed25519-signed envelopes, admin-provisioned keys, replay protection, and revocation checks on both parties
• Fail-closed revocation — if the authority store is unreachable, the gate denies rather than assumes; revoked actors propagate to peer gates via signed gossip (~60 ms measured)
• Human approvals as a protocol — policies can require N verified approver signatures before a token executes
• Framework adapters — LangChain (govern_all_tools) and CrewAI adapters mean governed execution for agents that were not built inside PrimeSwarm

This integration is live in the Minuta CRM: 18 write and credit-spend tools run governed calls whose signed evidence lands in the CRM audit stream — and is inspectable in the CRM itself at Settings → Governance.

The gate now also sits in front of the memory write path, not just tool calls: before a claim persists to the Continuity Ledger, PrimeSwarm calls DGV's /govern for real, and an ALLOW's signed receipt is attached to the record as evidence — bound into the record's own integrity hash, not appended alongside it. DGV configured but unreachable fails the write closed rather than falling back to local-only admission silently.

What is open source vs commercial

This matters for procurement. Here is the exact line:

Open source (MIT / Apache):

• The DGV verifier — the CLI that runs all 89 test cards and produces receipts. Clone it, build it, run it. No license required.
• The ONLY Lang compiler and WASM target — the DSL that encodes governance constraints. Inspect it, extend it, embed it.
• The DGV test card registry — all 89 card definitions in JSON. Use them as a compliance reference.
• The ONLY Lang WASM runner — try it at /try without signing up.

Commercial (Guard, Estate, Federation):

• The PrimeSwarm governance runtime — the 10-layer pipeline that sits in front of your LLM and enforces the gates in production.
• The Continuity Ledger — durable agent memory with Ebbinghaus decay, abstention gating, and conflict detection.
• Spatial XR — the Dual-Front command center and agent cores.
• HITL escalation infrastructure, SIEM integration, and the deployment tooling (Helm chart, HPA, identity integration).

The line is simple: you can verify the gate works without buying anything. You need a commercial license to run the gate in production. The verifier is open so you can trust the proof. The runtime is commercial because running it in production is the product. See the offer sheet for pricing.

Try it now: Run the ONLY Lang verifier in your browser at /try — no signup required. Browse all 89 test cards at /dgv/registry. See how PrimeSwarm fits your existing stack at /integrations. Compare approaches at /compare. Developer docs at /docs.