Docs/Enterprise Features

title: Enterprise Features description: Compute governance, health monitoring, cross-agent insight discovery, and agent testing in phorvec.

Enterprise Features

The features on this page are Enterprise-tier tools intended for production deployments where multiple agents run continuously, resource consumption must be governed, and reliability needs to be measured and maintained. They unlock with an Enterprise license and are not available on the Community, MCP Pro, MCP Max, or Team tiers.

The Enterprise tier is also the path for embedded deployment (drones, vehicles, robots, industrial devices), air-gapped operation, and OEM redistribution — rights granted under a separate commercial licence. See Pricing, or email licensing@phorvec.com for the current form agreement and a technical discovery call.


Compute Governance (Energy Ledger)

The Energy Ledger is a per-agent token budget system that gives operators control over how much compute each agent is permitted to consume. This is particularly important in multi-agent deployments where a runaway agent could exhaust resources and degrade the experience for others.

How Costs Are Assigned

Every operation type is assigned a cost in abstract "energy" units:

Operation typeCost
Retrieval (vector / context search)1
Storage (write to an agent database)2
ToolExecution (any MCP tool call)3
ModelCall (embedding generation)5
Custom(n)caller-defined

These costs reflect the relative computational weight of each operation. Embedding generation is the most expensive because it runs a neural network forward pass. Retrievals are cheap because the HNSW index is highly efficient.

Budget Tools

ToolPurpose
set_budgetAssign a total energy budget to a specific agent
allocate_budgetsDistribute a pool of energy across multiple agents according to weights or rules
get_spendReturn current spend and remaining budget for an agent or the fleet

Example: set a daily budget of 10,000 units for a single agent:

{
  "tool": "set_budget",
  "arguments": {
    "agent_id": "research-agent",
    "budget": 10000,
    "window": "daily"
  }
}

Denial Counters and Reliability-Based Allocation

When an agent exhausts its budget, subsequent operations are denied and the denial is recorded. get_spend reports the denial count alongside spend totals.

allocate_budgets can operate in reliability-aware mode: agents with lower denial rates and higher health scores (see Agent Health Monitoring below) receive proportionally larger allocations from the pool. This creates a feedback loop where well-behaved agents earn more resources.


Agent Health Monitoring

phorvec continuously tracks six health metrics for every active agent using Exponential Moving Averages (EMAs). EMAs weight recent observations more heavily than older ones, making the metrics responsive to current behavior while smoothing out transient spikes.

The Six Metrics

MetricWhat it measures
coherenceSemantic consistency of outputs over time; low coherence indicates erratic or contradictory behavior
contributionRate of new, non-duplicate knowledge being added to memory
prediction_errorDivergence between what the agent anticipated and what it retrieved; high error may indicate outdated knowledge
latencyMoving average of operation latency in milliseconds
success_rateFraction of tool calls that completed without error
trendDirection and magnitude of change across the other five metrics; positive trend means the agent is improving

Health Tools

ToolPurpose
agent_healthReturn all six metrics for a single agent, with threshold annotations
fleet_healthReturn a summary health report for all agents, sortable by metric

Threshold Alerting

Each metric has a configurable warning and critical threshold in config.toml. When a metric crosses a threshold, it is annotated in the agent_health response with a status of warning or critical.

[health.thresholds]
coherence_warning = 0.6
coherence_critical = 0.4
success_rate_warning = 0.9
success_rate_critical = 0.75

Intervention Suggestions

When one or more metrics are in a warning or critical state, agent_health includes an interventions array with actionable suggestions. Examples:

  • Low coherence → "Run memory_consolidate to resolve contradictory memories"
  • High prediction_error → "Run rag_refresh to update the RAG index"
  • Low contribution → "Review retention policies; the agent may be re-storing known information"
  • Low success_rate → "Check recent failure_summary output for recurring error patterns"

Cross-Agent Insight Discovery (DRE)

The Divergent Reasoning Engine (DRE) is a cross-agent synthesis system. Its purpose is to generate novel insights by forcing combination of knowledge from agents that normally do not share state.

The Problem It Solves

In a multi-agent system, each agent develops a coherent but narrow view of the world. Agents that work on different problems rarely expose their knowledge to each other. The DRE treats this divergence as a signal rather than a limitation: pairs of agents with very different knowledge profiles are the most likely to produce surprising combinations.

How It Works

discover_insights selects a "divergent pair" — two agents whose memory stores have low cosine similarity in aggregate — and performs a forced pierce blend: it queries both agents' stores simultaneously, interleaves the results, and runs a novelty detector over the combined set.

The novelty detector scores each candidate insight by how far it falls outside the convex hull of either agent's individual knowledge, using dual-grounding validation to confirm that the insight is supported by at least one item from each agent (not just one).

Provenance Tracking

Every insight produced by discover_insights carries a provenance record:

{
  "insight": "...",
  "grounded_in": [
    { "agent_id": "agent-a", "memory_id": "abc123", "score": 0.87 },
    { "agent_id": "agent-b", "memory_id": "def456", "score": 0.82 }
  ],
  "novelty_score": 0.73
}

This makes it possible to trace every generated insight back to specific source memories, supporting auditability and allowing downstream validation.


Geometric Failure Recovery

Vector indexes can develop pathological regions over time: dense clusters that make nearest-neighbor search unreliable, or sparse regions where queries return no meaningful results. The repair_search tool addresses these failures automatically.

How It Works

repair_search detects a retrieval failure (defined as a query returning fewer results than expected, or results with uniformly low similarity scores) and invokes the repair vector computation: it re-queries the index with a repaired query vector derived from the centroid of the failure region, filtered to exclude the vectors that caused the failure.

Failure Classification

Each repair is classified by failure type:

TypeDescription
sparse_regionThe query landed in an underrepresented area of the embedding space
cluster_collisionToo many vectors collapsed into the same neighborhood, causing recall loss
index_corruptionThe HNSW graph has a broken traversal path; triggers storage_repair

For index_corruption, repair_search automatically invokes storage_repair to rebuild the affected index segment.


Agent Testing

phorvec includes a structured testing framework for validating agent memory behavior against known-good baselines. This is essential for catching regressions when updating models, chunking strategies, or retrieval parameters.

YAML Test Suites

agent_test accepts a YAML test suite definition:

suite: "coding-agent-recall"
agent_id: "coding-agent"
cases:
  - query: "how do we handle database migrations"
    expected_ids: ["mem_abc", "mem_def"]
    min_score: 0.75
  - query: "authentication strategy"
    expected_tags: ["auth", "security"]
    top_k: 5

Each case specifies a query and one or more assertions: expected memory IDs in the result set, expected tags present in top results, or minimum similarity scores. phorvec runs all cases and returns a structured pass/fail report.

Baselines

agent_baseline captures a snapshot of the agent's current retrieval performance across a standard query set and saves it as a named baseline. Baselines record the full result set, scores, and IR metrics.

agent_baselines lists all saved baselines for an agent with timestamps and summary metrics.

Regression Checks

agent_regression_check compares the agent's current performance against a saved baseline. It reports:

  • Precision, recall, and F1 delta for each query in the baseline
  • Any queries that now return different top-1 results
  • Overall regression score (0 = identical, 1 = completely different)

A regression check should be run after any change to the index configuration, quantization mode, or embedding model.

Benchmarks

agent_benchmark runs a full performance benchmark: it measures query latency, recall@k, and throughput under load for the current agent configuration. Results are returned as a structured report suitable for comparison across configurations or phorvec versions.

IR Metrics

All testing tools report standard information retrieval metrics:

MetricDefinition
PrecisionFraction of returned results that are relevant
RecallFraction of relevant items that were returned
F1Harmonic mean of precision and recall

Precision and recall require a ground-truth relevance set, which is captured at baseline time. This makes the metrics meaningful as long as the baseline is kept up to date.


Server & Management Platform

phorvec includes a self-hosted server component with a web dashboard, REST API, sync engine, and audit infrastructure — all running inside your own environment.

Memory CMS

The Memory CMS lets operators edit agent memories directly from a browser without modifying application code.

  • Edit in place — change any stored memory; phorvec re-embeds the content automatically so the vector index stays consistent
  • No code deploy needed — fixes take effect on the next agent retrieval; there is no restart or redeploy step
  • Hot-patch hallucinations in under 2 seconds — locate an incorrect memory, edit it, save; the corrected knowledge is immediately live

This is particularly valuable in production environments where a prompt or memory correction needs to ship faster than a deployment pipeline can move.

REST API & SDK

The REST API provides full programmatic access to every server-side capability.

  • Full REST API — create and manage agents, insert and search vectors, query audit logs, and manage API keys from any HTTP client
  • TypeScript SDK — the @phorvec/sdk npm package wraps the REST API with typed methods and promise-based calls
  • Multi-tenancy via API keys — issue separate API keys per team, service, or environment; revoke individual keys without affecting others

Differential Sync

Differential sync enables cross-device and cross-instance memory synchronization without transferring full database snapshots.

  • Delta-only transfer — only changed memories are sent over the wire; unchanged vectors are never re-transmitted
  • Conflict detection — vector clocks identify divergent writes precisely, so conflicts are surfaced rather than silently overwritten
  • Conflict resolution — a 3-way merge handles non-overlapping concurrent edits automatically; the dashboard presents a side-by-side diff for cases requiring human judgment

Sync is opt-in; installations with no sync configuration remain fully self-contained.

Docker Deployment

phorvec server ships as a Docker container designed for straightforward self-hosted deployment.

  • Self-hosted container — deploy on any machine that can run Docker; no managed cloud service required
  • Zero login for local development — start with a single docker run command and no configuration; Community Edition runs immediately
  • Air-gapped compatible — pull the image once, load it into an isolated environment, and operate indefinitely without outbound network access
  • No external database required — all data is stored in the persistent volume mounted at /data; SQLite is the embedded storage engine with no separate database server needed

See Deployment Guide for Docker Compose examples and full environment variable reference.

Audit Log (The Vault)

The Vault is phorvec's enterprise audit infrastructure, built on top of the append-only audit log available in all editions.

FeatureCommunityEnterprise
Audit log entriesLast 100 entriesFull history
Export formatsCSV and JSON
Hash chainCryptographic (SHA-256 chained)
Tamper evidenceAny modification to a past record breaks the chain and is detected
RetentionConfigurable (default 1 year, set via AUDIT_RETENTION_DAYS)

The cryptographic hash chain means that any retrospective modification to an audit record — including deletion — is detectable. This supports compliance requirements that mandate tamper-evident logging, including SOC 2 Type II and certain HIPAA audit controls.