AnvaiOps
Four questions, one engine
Identity, memory, metering and evidence over one engine — memory is one face of the product, not the product.
Four questions, one engine
An agent you can actually run in production needs all four answers, and they have to agree with each other. That is the whole reason these are one product and not four: the identity that authorizes a call, the memory it reads, the meter that prices it, and the evidence that proves it happened are the same event seen four ways. Below is exactly what each one is today.
Anvai Identity 🔒 Source preview
An OIDC identity provider with passkey-first administration, available as a source preview for single-organization Linux evaluation, with published limitations. Not hosted, and not a multi-tenant service.
Request access →AnvaiOps MCP Open source
An open-source MCP server that gives agents provenance-rich incident memory — every answer carries where it came from — with a reproducible end-to-end demo you can run yourself.
View on GitHub →Sandhi Open source
An open-source AI usage gateway that meters and attributes every model call made behind a shared key. Drop-in for the OpenAI, Anthropic and Gemini SDKs, so attribution costs you no application changes.
View on GitHub →dq-kernel Open source
An open-source Spark engine that produces exact-arithmetic, digest-bound evidence reports. Nothing asks you to take our word for it: the digests are the point, and you verify them yourself.
View on GitHub →Underneath all four: ProximaDB
An Apache-2.0 Rust context engine, v0.5.1, doing single-node vector retrieval under a published support contract. One engine under four faces is what keeps their answers consistent — and it is open, so you can read it before you trust it. View ProximaDB on GitHub →
Tools alongside, not pillars: SentinelPass (v0.19.1), a credential manager, and AgentBrowser (v1.33.1, installable from our Homebrew tap), a browser agents can drive. Both are shipped and public; neither is part of the control plane.
Why shared memory matters
Your agents — and your engineers — re-solve the same problems every week
Memory is where most teams feel the control-plane gap first. Agents start every session from zero, and teams lose weeks per quarter to tribal knowledge loss and repeated investigations — because nothing remembers what was already solved.
Repeated investigations
The same Kafka lag spike, Postgres connection pool exhaustion, or Kubernetes OOMKill gets investigated fresh every time it recurs — because the RCA from six months ago is buried in a comment thread nobody can find.
Tribal knowledge locked in heads
Your best engineers carry institutional knowledge no one else has. When they leave, go on vacation, or join a different team — that knowledge evaporates.
Slow escalation paths
New engineers escalate everything because they don't know what's been solved before. Senior engineers spend hours on issues they've already fixed three times.
Operational memory in three steps
AnvaiOps connects to your existing tools and surfaces the right fix at the right moment — no workflow changes required.
Connect your stack
Authorize AnvaiOps to read from beta sources such as Jira, Slack, Teams, Confluence, PagerDuty, Datadog, GitHub, and ServiceNow. Access is read-only by default, with real-time webhook ingestion available where configured.
Index & embed
AnvaiOps ingests your historical tickets, threads, and runbooks. We extract RCAs, fixes, and owning teams using AI — then store them as a searchable knowledge index.
Search at incident time
When a new incident opens, engineers search in natural language. AnvaiOps returns relevant historical fixes, root causes, workarounds, and owning-team context with supporting metadata.
The memory face, in detail
Memory is the face with the most shipped surface, so it is the one documented in depth here. Search meaning with vectors, retain context in documents, connect relationships in graphs, and follow changes over time. A control plane adds tenant isolation and governance. Availability is labeled below.
Flagship use cases
Incident memory Beta
Your on-call agent remembers every incident. 20+ connectors (Jira, Slack, PagerDuty, Confluence…) stream your operational history into tenant-isolated hybrid search — vector + BM25 + metadata filters, one query.
Code memory 🔒 Preview
Your coding agent remembers your whole codebase. Code-property graphs + symbol-level embeddings (victor-codegraph), served to any agent over governed MCP.
Workspace & SQL GA
Notebooks with ProximaSession
Jupyter-style notebooks that run inside the per-workspace pod and connect to ProximaDB through an embedded ProximaSession. Markdown + code cells, syntax-highlighted Monaco editor, cell interrupt.
SQL bench
pgwire-compatible SQL bench wired directly to ProximaDB's federated SQL surface. Arrow result streaming, vector-aware result tables, automatic write-statement advisories.
Git-backed workspace files
Every workspace gets an embedded Gitea repo: notebook history, SQL queries, scripts, and config land as commits. Branch, diff, restore — even on a free trial.
ProximaDB capabilities
Statuses below mirror ProximaDB upstream — see the pricing matrix for which tier ships each capability and RELEASE_TAXONOMY.md for the contract.
Vector search GA
Canonical vector CRUD + similarity search over REST v2 / gRPC v2. Production SLA, full semver compatibility.
Hybrid retrieval Beta
Tantivy-backed BM25 fused with vector similarity via RRF or weighted scoring. REST v1 hybrid facade today; gRPC parity in progress.
Federated SQL Beta
VECTOR_SEARCH, GRAPH_QUERY, DOCUMENT_QUERY, LOGS, METRICS table-valued functions in one SQL plane.
ORION graph Beta
Node / edge CRUD, traversal, neighbors, shortest-path APIs. Native graph storage, not a relational fake-out.
Time-series (TST) Beta
Time-stamped tables with ASOF joins, downsampling, and OHLC aggregations. Designed for high-cardinality observability and trading workloads.
Distributed OLAP (DataFusion) Experimental
Ballista-orchestrated DataFusion MPP over cataloged Arrow snapshots. Available on Enterprise; Private Preview on Pro / Business.
Ops & cloud GA
One account, one cloud
Each account is bound to one cloud at signup (Azure, AWS, GCP). Data, workspaces, kernels, files — all in your tenancy, never traversing AnvaiOps infra.
Multi-region workspaces
One account can run workspaces in multiple regions within its cloud — workspace-scoped region picker on creation, immutable thereafter.
SSO by Anvai Identity
Single sign-on through Anvai Identity, our own OIDC provider — passkey-first sign-in, per-client required MFA, scoped API audiences and resource-specific tokens. Bring-your-own enterprise IdP federation is on the roadmap.
Observability + cost controls
Tiered allowances on storage / ingest / embedding / scan with per-tier soft caps. Prometheus metrics for every meter; the calculator below mirrors the runtime gates.
Flexible deployment
Managed AnvaiOps SaaS, private VPC, or fully air-gapped on-prem. Three ProximaDB transports — REST, gRPC, Arrow Flight — fit isolated environments.
Use case · Incident knowledge
The original AnvaiOps workload: connect every incident to its resolution. Slack & Teams bots, 21 ITSM / observability / messaging connectors, hybrid retrieval over tickets and threads. Still a first-class use case, no longer the only one.
Use case · Code intelligence
Code-graph as a service (in private preview): index your repositories into a correlated substrate — one symbol = one graph node + one vector + one relational row. Query impact_analysis (blast radius), transitive callers, and semantic fusion_search over code.
Release stages and availability
Beta, Experimental, Private Preview
AnvaiOps mirrors ProximaDB's four-state release ladder. We never claim a status above the engine's upstream value — see ADR-0014 for the contract.
GA Supported
Production SLA, semver compatibility, full support contract. Vector CRUD & similarity search is the canonical Supported surface today.
Beta Beta
Functional and API-stable; no production SLA yet. Federated SQL, hybrid retrieval, ORION graph, observability runtime, security runtime, TST time-series, event sourcing.
Experimental Experimental
Scaffolded; partial implementation. Distributed cluster execution, full SQL parity, external tables (Iceberg / Delta / Hudi), DataFusion OLAP, Trino / Spark adapters.
Private Preview
Per-account grant for Beta or Experimental capabilities not included in your tier by default. Operator-driven for design partners; request access via the sign-up form.
Explore the open-source engine
P Built on ProximaDB
AnvaiOps is powered by ProximaDB — an open-source multi-model database that unifies the indexes and data planes our knowledge layer depends on. The engine is public and auditable. The intelligence layer is what we build on top.
Multi-model engine
One engine for the multiple index types modern knowledge retrieval requires — unified under a single query plane. No separate search infrastructure to operate or pay for.
Three deployment modes
Server: standalone service — cloud, on-prem, or intranet-isolated. Managed: process lifecycle handled for you. Embedded: single-binary in-process for air-gapped environments. Same engine, three topologies.
Open and auditable
Security-conscious enterprise buyers can inspect the open-source engine. No black-box indexing path, no hidden retention layer. Fork it, audit it, trust it.