Skip to content

Product teams

Insighter inside your product

The public API exposes threads, streaming answers, and voice. Ship an analyst inside your own app, scoped per end user, metered per answer.

The week this replaces

Customers keep asking for analytics, and building an analyst into the product is a year of roadmap.

A model with database access is a support incident waiting to happen unless every answer is scoped to the user asking.

If usage cannot be metered per tenant, finance cannot bill it and the feature cannot ship.

POST /v1/threads/{id}/messages with your customer's question.

The reply streams back as server-sent events with the same guardrails, credit metering, and per-user scoping the app uses. A voice endpoint returns spoken answers for phone and kiosk surfaces.

Illustrative conversation. On your data every answer carries sources you can open, and every query is read-only.
  1. AnsweredThe same governed answer your own interface would have produced
  2. ActedMetered to the calling tenant and written into the audit log
  3. WatchingA key cannot read a source the person who created it could not read.

Per answer, metered in credits, with the cost returned on the response.

And then it keeps running

Answer the end user’s question inside the scope their token carries, meter the credits to their tenant, and write the run into the audit log.

On every API call from your productCeiling: set per token
Connects toPublic APIVoice API
Doing the workSSE streamingPer-user scopingUsage metering

Where this goes

Governed autonomy

Work that runs without you, inside limits that only ever narrow, with a record of what it did, what it refused, and what it would not do without asking. Everything on this page is one step toward that.