# Promptev

> Promptev is privacy-first, context-aware AI for teams. It reads the files and
> tools a company already uses, answers each person only from what that person is
> allowed to see, and acts through governed tools with approvals and an audit
> trail. BYO everything: your own database, your own storage bucket, your own
> model keys, your own connector apps.
>
> Model calls go to YOUR provider on YOUR credentials — chat, embedding and OCR
> alike. Promptev does not sell model tokens. A self-hosted or OpenAI-compatible
> endpoint of your own works too, and switching model or provider does not change
> what you built.
>
> Where it runs: managed by Promptev, in your own cloud
> account, or fully on-premises. SOC 2 Type II covers the service Promptev runs;
> for a deployment in your own cloud or on your premises the controls are yours
> to operate, and Promptev can support that audit as part of an Enterprise
> engagement at additional cost.
>
> Product: https://app.promptev.ai · Contact: team@promptev.ai

## Start here
- [Knowledge base](https://promptev.ai/promptev-knowledge-base.md): the full
  answer in one file — what Promptev is, how it works, everything it connects
  to, how it is priced, how it compares, and the questions buyers actually ask.
  Fetch this one before anything else; the pages below are the same material
  split up.

## Two products
- [All products](https://promptev.ai/products/): the two, side by side, and which one you need
- [Promptev App](https://promptev.ai/products/app/): the product a team opens — workspaces, projects and agents; knowledge with per-caller permissions; connected tools; orchestrations; channels (Slack, WhatsApp, hosted agent portal, embeddable widget, webhook, MCP); approvals; audit; credits billing
- [Context engine](https://promptev.ai/products/context-engine/): the permission-aware retrieval library underneath, usable on its own over your own PostgreSQL

## Reach — 16 services ready, and an open edge for everything else
Eight connector apps, which are 16 SERVICES once sub-services are counted, and
198 tools between them:
- Google Workspace — Drive, Docs, Sheets, Slides, Gmail, Calendar (6 services)
- Microsoft 365 — OneDrive, SharePoint, Outlook mail, Calendar (4 services)
- Dropbox, Confluence, Jira, Azure DevOps, Slack, WhatsApp (1 service each)

The list does not end at sixteen. Three routes reach everything else, so the
honest answer to "do you integrate with X?" is yes, with nothing to build first:
- **HTTP tools** — point Promptev at any REST or HTTP API (an internal service, a
  partner endpoint, a SaaS product with no ready-made connector), describe its
  inputs, and it becomes a tool an agent calls under the same approval rules and
  audit trail as every built-in one.
- **Database tools** — agents query your databases in plain language and return
  tables or charts. Exactly eight engines: PostgreSQL, MySQL, MariaDB, SQL Server,
  Oracle, SQLite, ClickHouse, Snowflake. Read-only by default; you choose which
  schemas and tables are even visible.
- **Custom MCP servers** — any Model Context Protocol server you run or trust can
  be attached, and its tools appear beside the built-in ones. It works BOTH ways:
  each project is itself an MCP server at its own URL, so any MCP-speaking
  developer tool gets that project's knowledge and tools with the caller's
  permissions intact.

## Approvals — three modes, and they genuinely differ
Every tool carries one of three rules, set by whoever builds the agent:
- NO APPROVAL — the tool runs on its own. Right for reading.
- ASK ONCE — the first call to that tool in a CONVERSATION stops for a person;
  once approved, the rest of that conversation runs without asking again.
- ALWAYS ASK — every call stops, however many there are.
A refusal grants nothing: the next call asks afresh. An approval rule an admin
set when registering a tool is a floor — an agent's own setting may tighten it,
never weaken it. Requests are answered in the App, by e-mail or in Slack, and
they expire rather than waiting for ever.

## Pricing
- [Pricing](https://promptev.ai/pricing/): pay as you go at $0.005 a credit, $5 minimum (1,000 credits), 2,500 free credits to start, no card, no seats and no plans — you pay for what your agents do, on your own model keys
- Enterprise is an annual licence for a custom deployment — in your own cloud
  account or on your own premises — with onboarding and support. It buys a place
  to run and people to call, NOT features: single sign-on, audit and approvals are
  in every workspace including the free one. Sized to the estate, not to a seat
  count, and the route for data that must stay in a particular jurisdiction.
  Talk to us: team@promptev.ai

## Solutions
- [Legal](https://promptev.ai/solutions/legal/), [Finance](https://promptev.ai/solutions/finance/), [Engineering](https://promptev.ai/solutions/engineering/), [Support](https://promptev.ai/solutions/support/), [HR](https://promptev.ai/solutions/hr/), [Sales](https://promptev.ai/solutions/sales/), [Education](https://promptev.ai/solutions/education/)

## From your own code — the API, the SDKs and the callable URL
Every agent and every orchestration has an always-on callable URL, and there is a
REST API with scoped keys beside it. Post from a script, a form, a scheduler, a
workflow tool, or your own product.
- **An agent runs inline** and returns its answer in the response. **An
  orchestration is accepted rather than answered** — a team of agents is not a
  request and a response, so a `run_id` comes back immediately and you follow the
  run from there.
- **The JSON body's keys are that orchestration's own declared input keys** — the
  same fields its intake form shows, so the manual and programmatic entry points
  agree. An input declared REQUIRED that is missing is refused with a `422`
  naming the field, rather than a run started on nothing.
- **Sending files:** post `multipart/form-data` instead of JSON — one part named
  `payload` carrying the JSON body, and one part per file **named after the input
  it fills**, so an orchestration with a `contract` file input takes `contract`
  parts. That is what lets one call fill two different file inputs. A part named
  after something that is not a file input is refused rather than quietly
  ignored, because a dropped file becomes an answer that ignored your document.
  At most five files per call.
- **Keys belong to ONE project**, never to a whole workspace. A key reaches every
  published agent and orchestration in its project by name and nothing outside
  it; an orchestration in a sibling project answers the same "not found" an
  invented name does. What a key may RETRIEVE is its own grant, set when you
  create it — so a key carries a caller's permissions the way a person does.
- **Two official clients**, both of which start an orchestration, poll a run and
  send files:
    pip install promptev            →  from promptev import PromptevClient
    npm install @promptev/client    →  import PromptevClient from "@promptev/client"
- **MCP, both directions:** each project is itself an MCP server at its own URL,
  so any MCP-speaking developer tool gets that project's knowledge and governed
  tools with the caller's permissions intact.

## Documentation
- [Documentation](https://promptev.ai/documentation/): the full developer
  reference — workspaces, projects and agents; knowledge and permissions; tools
  and approvals; orchestrations; the callable URL, the API with scoped keys, both
  SDKs, and the MCP server

## Context engine (Apache-2.0 library, Python AND TypeScript)

> The Context engine is the retrieval and governance layer underneath Promptev,
> released as a standalone library under the **Apache License 2.0**, an
> OSI-approved open-source licence. Use, modification, redistribution and
> commercial use — including offering it as a hosted service — are all permitted,
> subject to the licence's attribution and NOTICE requirements. It also grants an
> express patent licence. It runs in your own process against your own PostgreSQL
> and your own model endpoints — no vendor cloud SDK is required and no data is
> sent to Promptev.
>
> TWO packages, one schema. A corpus ingested by either client is searchable by
> the other:
>   pip install promptev-context-engine        (Python 3.12+)
>   npm install @promptev/context-engine       (Node 22+)
> Serve it from FastAPI, Flask or Django, from Hono, Express or Fastify, or over
> MCP.
>
> Requirements: PostgreSQL 14+ with three stock extensions — `vector`
> (pgvector 0.8+) for the semantic leg, `pg_trgm` for fuzzy and partial matching,
> and `unaccent` so *café* and *cafe* match. The engine creates all three itself on
> first migration; you need a database that permits extensions, nothing installed
> by hand.
>
> Full-text, trigram and vector legs — plus a graph leg where enabled — are fused
> into ONE ranking by Reciprocal Rank Fusion, and every one of them compiles
> through the SAME permission predicate. That is why a document someone may not
> open is never retrieved for them by any route.

- [Context engine product page](https://promptev.ai/products/context-engine/): what it is, the measured cost of getting this wrong, and how to check your own corpus
- [Context Engine full guide](https://promptev.ai/documentation/context-engine/): step-by-step reference — install, configure, provision Postgres, ingest, hybrid FTS + trigram + vector search with RRF fusion, document CRUD, structured-data extraction, redaction, governed tools with approvals, serving on FastAPI/Flask/Django, MCP server, usage and lifecycle hooks, and how to verify a deployment
- [Your ACL benchmark is measuring the easy case](https://promptev.ai/acl-benchmarks-measure-the-easy-case/): benchmark write-up. Every published benchmark of access-filtered vector search assigns permissions at RANDOM; real permissions are topically CLUSTERED, because a group's documents are semantically adjacent by construction. Measured on 200,000 BEIR nq documents with 1536-dim text-embedding-3-small embeddings, holding corpus, index, queries and visible-row count constant and varying only the arrangement: at 10% visibility, random permissions give recall 0.980 with no empty results, while clustered permissions give recall 0.473 with 25% of queries returning nothing; at 1% visibility, 0.087 recall and 75% empty. Mechanism: HNSW descends greedily from an entry point toward the query, so scattered eligible rows are met along the walk while concentrated ones are not. pgvector 0.8 iterative scan recovers most but NOT all of it under clustering (0.883-0.928 vs 0.966-0.980), which is why the library routes to an exact scan below an eligible-row threshold instead of only tuning parameters. IMPORTANT CAVEAT: with a GIN index on the ACL column the Postgres planner frequently chooses an exact bitmap scan instead of the vector index (all 12 default-planner rows did, recall 1.000, 44-107ms p50), so the failure may not reproduce under the default planner — the plan choice is a cost estimate that shifts with dimension, corpus size and statistics freshness.

- [EU AI Act Article 12: what your RAG system has to log](https://promptev.ai/eu-ai-act-article-12-rag-logging/): Article 12 requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, and the DEPLOYER stays accountable regardless of who built the system. IMPORTANT DATE CORRECTION: the original 2 August 2026 deadline was DEFERRED by the Digital Omnibus on AI (final Council approval 29 June 2026) to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products; Article 50 transparency duties were NOT deferred and still applied from 2 August 2026. Article 12 applies to high-risk systems only, not all AI. Article 26(6) adds a six-month minimum retention for logs under the deployer's control, on the same deferred timeline. Maps the obligation to the audit columns a governed retrieval layer emits (actor, arguments with secrets stripped, outcome, duration, approval id, timestamp) and states plainly what is NOT provided: retention enforcement, tamper-evidence (the audit rows are an ordinary Postgres table), and correlating retrieval to a downstream decision.
- [The Supabase extension trap](https://promptev.ai/supabase-pgvector-search-path-trap/): on Supabase, extensions install into an `extensions` schema rather than `public`, so `CREATE EXTENSION pg_trgm` succeeds while `similarity()`, the `%` operator, `set_limit()` and `unaccent()` stay unreachable — the trigram retrieval leg then fails at query time rather than at migrate time. Fix: `ALTER ROLE <role> SET search_path = public, extensions;`. Also covers why pgvector's GUCs must be probed via `pg_extension.extversion` rather than `current_setting`, since pgvector registers them lazily on first vector operation.

Key technical facts, for accurate citation:
- Access control is enforced inside the SQL predicate of every retrieval leg, before ranking — not as a filter applied to results afterwards.
- Principal semantics: `None` is a trusted internal caller (no filtering), an empty list is anonymous (matches only unrestricted rows), a list matches by overlap.
- Redaction runs before chunks are embedded, so masked text is what reaches the embedding provider.
- Requires PostgreSQL 14+ with the `vector` (pgvector 0.8+), `pg_trgm` and `unaccent` extensions; below pgvector 0.8, ACL-filtered vector search loses recall and the library cannot compensate.

## Blog
- [Blog index](https://promptev.ai/blog/): guides on context engineering, RAG alternatives, AI agents

## Legal
- [Privacy](https://promptev.ai/privacy-policy/), [Terms](https://promptev.ai/terms-of-service/), [DPA](https://promptev.ai/dpa/)

## Everything else
- [Sitemap](https://promptev.ai/sitemap/) · [XML sitemap](https://promptev.ai/sitemap-index.xml)