OpenAI Development & AI Integration

What we build with the OpenAI API

Most requests fall into four shapes, and each is judged by a different test: extraction by accuracy against your schema, assistants by whether the right function was called, search by whether the right passage was found, and voice by latency and cost per minute.

• →Extraction from documents, emails and forms into the fields your database already has
• →Assistants inside your product that call your own functions to look things up or make changes
• →Search and question answering over your content using embeddings
• →Phone and voice agents built on realtime audio

Structured outputs and function calling: output your code can trust

Free text is hard to build on. The approach that holds up is to define the shape you need as a JSON schema, ask the model for exactly that, and validate responses in code before they touch a database or trigger an action. A schema guarantees the shape, not the values, so the check has to cover both: a response that fails is retried or sent to a reviewer, not quietly accepted. Function calling follows the same rule: the model proposes a call and its arguments, and your code decides whether to run it. How much of this a feature needs depends on what it touches.

• →Schemas versioned alongside the code that consumes them
• →Validation on every response, not only in testing
• →Irreversible functions gated behind a confirmation step

Embeddings and retrieval

Retrieval quality decides most question-answering projects, and it is usually a data problem before it is a model problem. The decisions are how documents are split, what metadata travels with each piece, and where vectors live: in the database you already run (PostgreSQL with pgvector, for example, which our database design practice sets up) or in a dedicated vector store when volume or latency calls for one. Which fits depends on the project. Retrieval is worth testing on its own, with questions whose correct source passage is known, before judging the answers built on top of it (our RAG answer walks through the steps).

Voice and realtime

Voice is where latency and per-minute cost stop being abstractions. Our comparison of Twilio, Vapi, Retell and self-hosted phone agents works through the latency floor and per-minute cost of a GPT-4o-based stack, and our OpenClaw phone guide covers keeping an agent's tools available during a realtime call. The practical lesson from both: model selection is the biggest cost lever, so a voice project should be priced at your real call volume before the model is chosen.

More than one provider, when it pays

We rarely recommend depending on a single model provider. Having each feature call a small interface in your code rather than the vendor SDK directly lets you route high-volume, simple tasks to a cheaper model, send harder reasoning to a stronger one from whichever provider scores best (see our Claude page), and fail over when a provider is slow or down. Changing a model then means rerunning the evaluation set, not rewriting the feature. Whether a build needs this depends on the engagement; where it does, the shape is:

• →One interface per capability, not per vendor
• →A fallback model tested against the same evaluation set
• →Per-task model choice recorded in configuration, not scattered through code

Cost controls from the first release

Token spend grows with success, so it should be measured before it surprises anyone. The setup we recommend logs every request with the model, token counts and the feature that made it, and gives each feature a budget and an alert.

• →Prompt caching and shorter prompts for repeated context
• →The smallest model tier that passes the evaluation set
• →Usage dashboards per feature, with alerts on unusual spend