Who it is for
For administrators
You decide which models the workbench uses, where they run, whose keys pay for them, how much may be spent, and who may do what. The product records every model call with its cost, refuses what your rules forbid before anything leaves, and keeps each organization's data separate in the database itself.
What changes for you
-
Model use you can govern
One place sets which provider and model serves each task, which keys pay, and what may leave your network. Nobody wires a model into a document by hand.
-
Spend you can predict
Every call is costed as it happens, budgets alert and stop, and regenerating a chain of work shows an estimate from past runs before it starts.
-
Changes you can test
Before you switch a model or a prompt, run the reference initiatives and compare the scores with the last run, metric by metric.
-
A setup you can hand over
An administrator guide covers every setting the application has, and a runbook puts the product on a virtual machine of your own with TLS, backups, and a restore drill.
Your models, local or hosted, with your keys
The product calls models through one gateway with three adapters: OpenAI, Anthropic, and any server that speaks OpenAI's interface (an OpenAI-compatible endpoint), which covers model servers you run yourself. You pick the provider and model per task, add organization keys, and choose whether members may use personal keys, which take precedence over the organization's. Each key says whether requests leave your control, and restricted content is only ever sent to a private one.
A local embedding service ships with the product as an optional container: start it with the database, and the setup offers to connect your organization to it, so search understands meaning as well as words without sending a passage anywhere. (An embedding model turns a passage into numbers that capture its meaning; that is what search by meaning compares.) Moving later to a hosted embedding model builds a new index beside the old one and switches over only after the retrieval evaluation has compared them.
Every cost visible, nothing shown as free
Every model call writes an accounting row with the organization, the person, the task, the model, the key used, and the tokens. Costs come from the prices you enter per model; a call without a price is reported as unpriced, never as zero. Budgets per organization, person, or initiative raise an alert at the fraction you choose and can stop spending. Each initiative shows its spend by stage, workflow, run, and model.
People, roles, and sign-in
Invite members with roles: admin, product, reviewer, and engineering read-only, which combine. Sign-in is by email and password, with lockout after repeated failures. The sign-in layer already supports OpenID Connect, the standard behind most single sign-on, and is tested against an identity provider, so connecting your own later is configuration rather than a rebuild. You decide per organization whether stages interview their users, and how many rounds of questions a run may ask.
Know whether a change made things better
Before you change a model or a prompt, run the reference initiatives. Each run goes from idea to bundle with no human input and is scored with deterministic metrics and a judge, a second model that scores the output against a written rubric and gives its reasons. Two runs are compared metric by metric with their configuration differences, and a metric that moves beyond its tolerance is flagged for your verdict. Retrieval has its own evaluation, which gates any change to how documents are split or indexed.
Each organization kept apart
Every piece of an organization's data, from documents to model calls, belongs to that organization. The database enforces it with row-level security, a rule in PostgreSQL that filters every query by organization, and the application's data layer adds the organization to every query as well. The isolation tests try to read one organization's data as a member of another, through every entry point the application has, and must find nothing. The two fictional demo clients are loaded side by side for the same reason.
Where it runs
One application and PostgreSQL, which also holds the search indexes and the job queue. Run it on one computer with Docker Compose, or follow the demo-stage runbook to put it on one virtual machine behind TLS, with files in an object store, the encryption key from the environment, a nightly database dump and file copy, and a restore you have practiced. Moving to a server changes configuration, not the product.
Operations in view
Pages for sources and their sync history, background jobs with their progress and the jobs that failed for good, plugins and their health, usage, metrics, index health, knowledge cost per source, the audit log, and registered design systems with their contrast reports. Connectors and workflows are plugins that declare what they may reach, and you see those permissions before you enable one. The operations runbook covers failed syncs, re-indexing, and backups.