Checked at the door
Structured output is parsed against the calling feature’s own schema before any code sees it. Broken output fails loudly rather than leaking into a record.
The foundation under itProduct intelligence
The AI runtime
Every model answer is checked against a schema before it is used.
Meeting extraction, Ask Growth Kit, content drafting and profile writing all reach a model through one server function. The response comes back parsed against the schema that feature declared, so malformed output fails at the boundary instead of landing in a record. Keys stay on the server, and which model a feature uses is one line of configuration.
3provider adapters wired1config file that decides the model0API keys in the browser
11 of 22 in The foundation under it
Interactive example
See it working
This walkthrough demonstrates the implemented backend contract without using an account, credentials, or provider calls.
Interactive example
Explore the decisions this makes
Low-latency model route
Deterministic sample data only. No account, provider, or network connection is used by the interaction.
Highlights
Why it matters
Keys never leave the server
Provider credentials live in server environment variables. Nothing AI-related ships to the browser, and the browser talks only to authenticated routes.
Routing is configuration
config/ai.ts maps each feature key to a provider and model. Changing a model never touches the feature that uses it.
The problem this solves
Without a shared foundation, every team rebuilds these edge cases, differently.
One malformed answer breaks a screen
A model returns something that is nearly the right shape and the code trusts it. The failure shows up later, inside a record someone relies on. Parsing at the boundary makes the failure immediate and obvious.
A key drifting toward the browser
Model calls get added wherever it is convenient. One lands client-side and the credential ships to every visitor. Here the adapters are server-only, so there is nowhere for that to happen.
A model change that touches everything
A provider retires a model and the change becomes a search across the codebase. Here it is one route entry, and every caller keeps its own key.
How it works
The mechanism end to end, as implemented in the repository.
- 1
A feature calls with its own key
Server code asks for text or a structured object, tagged with a feature key such as fast, default or reasoning. Configuration decides which provider and model handle it.
- 2
The call runs on the server
The matching OpenAI, Gemini or Anthropic adapter runs with server credentials. Every route in config/ai.ts points at OpenAI today.
- 3
The answer is parsed at the boundary
Structured output is requested from the provider and then parsed with the declared schema before returning. Invalid output throws rather than passing through.
- 4
The caller gets a typed result
The feature receives a clean object plus token usage, provider and model, so cost and routing are observable without a raw string to re-parse.
Engineering guarantees
What this does and does not promise
Safety boundary
Three provider adapters are wired and nothing fails over on its own when one is down. Model output is a draft for a person to accept, never a fact by itself, and this page cannot promise accuracy. Whether a generation is accepted at all depends on the workspace entitlement described under usage limits.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/features/ai/runtime.tssrc/features/ai/contracts.tsconfig/ai.ts
Questions
Frequently asked questions
Used alongside this
These capabilities share contracts and boundaries with this one.
What the ai runtime rests on
The docs describe the same contracts this page demonstrates.