Retail and e-commerce
Order questions by the thousand, most of them lookups and a few of them disputes; agents that act on orders and need to be told what they may touch.
See the retail and e-commerce page
Solutions
Build with Inferbase
Build guides by industry and by use case: where Inferbase sits, which features carry it, the routing policy to create, and code that was run before it was published.
By industry
Where the work looks like yours
Six industries, each with the shape of its traffic and the guides that fit it. One guide serves several industries, because the use cases repeat.
Financial services
Documents that must become fields without a mistake, policies and regulations to answer from with a citation, and actions that wait for a person.
See the financial services page
Healthcare and life sciences
Forms and referrals to read into records, protocols to answer from, intake over the phone, and a pool of models you can name to an auditor.
See the healthcare and life sciences page
Software and developer tools
Documentation that answers the same questions daily, agents that edit code, and a bill that should follow the work rather than the hardest request.
See the software and developer tools page
Customer operations and contact centres
Calls and chats where the first second decides, handoffs that have to reach a person, and spend that has to stay inside a cap per conversation.
See the customer operations and contact centres page
Legal and professional services
Contracts and filings to extract from and to answer questions over, with retention and the model pool decided before the first document is sent.
See the legal and professional services pageBy use case
The build guides
Six today. Each follows the same template, so what you learn on one carries to the next.
Customer supportBuild guide
Customer support assistant
A support chat that answers from your documentation with sources, hands off to a person when it should, and shows which model Inferbase routed each answer to and why. One API key, no vector database, embedded on any site with one script tag.
Read the guide
RAGBuild guide
RAG over a knowledge base
Retrieval stays in your stack; the generation call goes to Inferbase with the model set to auto, routed per question on how hard it is, with the context window sized to your retrieval and the privacy decision made where the data flows. Built from scratch on Postgres with pgvector, with the agentic shape included.
Read the guide
AgentsBuild guide
Coding agents
An agent loop where the planning call and the tool-calling steps are routed on what each one is, the loop stays on one model while a tool call is open, and the tools the agent may call are governed by policy. Built from scratch with a sandbox, four tools and one session per run.
Read the guide
ExtractionBuild guide
Document extraction to JSON
Turn invoices, forms and letters into JSON that matches your schema. The schema rides on the request, routing serves only models with verified structured-output support, retries are idempotent, validation decides what goes to a reviewer, and every record carries the model and the cost that produced it. Built as a worker pipeline on Postgres.
Read the guide
AgentsBuild guide
Agents with tools and MCP
An operations agent whose tools are an allow-list in the policy, whose MCP servers are declared, whose consequential actions wait for approval, and whose runs are bounded and recorded. Your client calls the tools, or Inferbase calls the declared servers itself. Built on the Responses API.
Read the guide
VoiceBuild guide
Voice agent
Speech in, speech out, on one key: transcription, a routed answer kept short and fast, and speech synthesis streamed so the first audio arrives before the sentence is finished. Built as a turn service with a browser client, for turn-based use: an IVR, an in-app helper, a voicemail that answers. Measured at 7 to 13 seconds a turn today, it is not a real-time phone agent, and the guide says what would make it one.
Read the guideDefinition
What a build guide is
A reference architecture written for the person who will build it, from the problem to the call that runs.
A build guide names the problem and who has it, draws where Inferbase sits in the stack, lists the product features the design rests on with their documentation, states the routing policy to create stage by stage, and walks the build step by step with code. It is meant to be copied.
In every guide the product sits in the same place: at the generation call, behind one OpenAI-compatible API. Retrieval, tools, memory and orchestration stay in your stack. What changes between use cases is the policy, which is why each page spends a section on it, and why the code sends model: "auto" and nothing else about the model.
Method
How every build guide is built
The same rules on every page, held by a test, so a guide cannot ship half-written or with code nobody ran.
Written as a build guide
What you build, the problem, the architecture in four figures, the stack, the build step by step with code, the policy, security, evaluation, operations, scaling, troubleshooting. Thirty to forty minutes of reading, written for the person who will build it.
Code that was run
Every call, in Python and TypeScript, is run against the public API and type-checked against the SDK types before it is published. The page says on what date.
Figures with a source
A cost or latency figure appears only where we measured it, with the date and the method. Where nothing was measured, the page shows nothing.
Policy, not code
What changes between easy and hard, cheap and strong, managed and your own keys lives in the routing policy. The code sends model auto and stays the same.
FAQ
Questions about the build guides
A worked design for one use case: the problem it solves and who has it, the architecture with Inferbase placed in it, the Inferbase features it rests on, the routing policy to create, the code to run in Python and TypeScript, and what was measured. Each build guide is meant to be copied, not admired.
At the generation call. Retrieval, tools, memory and orchestration stay in your stack; the request that asks a model for an answer goes to Inferbase, which chooses the model, applies your policy and guardrails, serves it, and returns the decision with the response. The diagrams draw that boundary explicitly.
Every snippet is run against the public API before it is published, and the page says on what date. The snippets use the OpenAI SDKs with the base URL changed, which is the whole integration.
From measurements we made ourselves, each named with its date and method on the page that shows it. Where nothing was measured, the page shows nothing rather than an estimate.
Yes. A routing policy can build its pool from Inferbase managed models, from provider keys and cloud accounts you connect, or both. The code sends model auto in every case; the policy decides whose credential serves.
The guides on model routing for RAG and for coding agents are the long-form companions: the reasoning in depth. The build guides are the build. Each links to the other.
Every build guide has its call in both languages. The customer support assistant also has a complete application in the open-source quickstarts, which is the assistant running on inferbase.ai. Further quickstarts follow the build guides.
Each page has a button that opens the Playground with the build guide prompt filled in and routing on auto, so you can watch the decision for that kind of request before writing a line.
The one closest to what you are building. If you already have an OpenAI-compatible call in production, any of them is a base URL change away; start with the support assistant for the smallest complete example.
Put intelligence in the middle.
One gateway in front of every model, with your policies applied and every decision on record. Start on the free plan with 5,000 requests a month, no card required.