Drop-in AI for the product you've already shipped.

Integration assumes you have a product already. There's an existing UI, an existing data model, an existing release train, an existing team — and the question is how to add an AI feature into that surface without re-architecting the product. The deliverables look different too: an integration engagement ships an abstraction layer, a rate-limit posture, a fallback drill, and an eval-gated rollout. A development engagement ships a new AI app from scratch — different shape, different scope, different risk profile.

If you're building the AI product itself (the chat, the agent, the retrieval pipeline as the central UX), route to LLM development or AI agent development. If you have a SaaS product and you want to add Claude or GPT-5 features without re-platforming, that's the ai integration services shape and you're on the right page.

It depends on the workload, not the brand preference. We default to OpenAI for function-calling-heavy agents, voice realtime workloads, and broadest tool-ecosystem needs — GPT-5 plus the Realtime API still leads on those shapes. We default to Anthropic Claude for long-context retrieval, contract-grade instruction-following, and tool-using agents where Sonnet 4.6's behaviour is more predictable across runs.

In practice, most production integrations end up with both behind a proxy. Easy traffic routes to Haiku 4.5 or GPT-5 mini; hard traffic to Opus 4.7 or GPT-5; fallback ladder configured against 429 and 5xx. Single-provider integrations are fine for two-week MVPs; they age badly once the first outage hits.

The four shapes we ship cover most of the inbound. Drop-in API integration runs 1-2 weeks — single feature, single provider, single tenant. Provider abstraction layer build runs 3-5 weeks — gateway, fallback ladder, cost telemetry, observability wired before launch. Sidecar service build runs 4-8 weeks — separate service for the AI feature with its own deploy and eval cadence. Forked fine-tune deploy runs 8-16 weeks because it pulls in P3 LLM (model build) and P12 MLOps (serving infrastructure) as adjacent practices.

Every engagement starts with a 60-minute scoping call. If the surface looks too narrow or too broad to map cleanly to one shape, we say so before any contract gets signed.

Depends on three signals: tenant count, regulatory posture, and how much of the contract is provider-specific. For small-to-mid SaaS teams under 50 tenants with relaxed compliance needs, LiteLLM behind a Cloudflare Worker is usually the right call — Apache 2.0, broad provider coverage, low operational surface. For multi-tenant SaaS with quotas, observability requirements, and a compliance team in the loop, Portkey's managed gateway earns its fee. For regulated enterprises where the gateway itself needs to live inside a VPC with audit-logged config changes, we build an in-house thin gateway in TypeScript or Python — usually 400-800 lines of code that owns the contract, the fallback ladder, and the cost telemetry.

None of these are "the right answer" globally. The wrong shape is the one that doesn't fit your compliance + ops surface.

It means the cost ceiling and the rate-limit live as code. Concretely: per-tenant token budgets stored in Postgres or Redis with TTL, checked before every request; daily cost ceiling per tenant with an alert at 80% and a hard cut at 100%; per-request token budget (e.g. "no single request can exceed 8k tokens of completion") to prevent runaway costs from a malformed prompt; exponential back-off with jitter on 429 and 5xx; cache tier — exact-match cache for repeated identical requests, semantic cache (Redis + a small embedding model) for near-duplicates; burst smoothing via a leaky-bucket queue when provider rate-limits would otherwise drop traffic.

Without these, the post-launch story usually goes: the feature ships, a customer abuses it accidentally, the bill triples, the team panics, the feature gets pulled until the rate-limit work that should've been week 1 finally happens. Better to do it before launch.

Mostly yes. The integration surface is usually three places: an auth-and-secrets seam (provider API keys live in your existing secret manager — Vault, AWS Secrets Manager, GCP Secret Manager, Doppler — not in a new system), a network egress seam (calls to the provider's endpoint go through your existing egress controls), and a data-plane seam (request and response payloads pass through your existing logging / audit pipeline). All three commonly slot into the existing stack — Node, Python, Go, Ruby, Java, .NET — using the provider's SDK or a thin HTTP client.

What does sometimes change: observability gets a new tier (Langfuse or Helicone next to the existing APM), the gateway adds a hop (Workers / FastAPI service / Portkey), and the eval suite is genuinely new tooling (Inspect AI, Promptfoo, RAGAS) because most existing test infrastructure doesn't grade LLM output.

A fallback ladder, wired before launch, drilled monthly. The shape: primary provider (e.g. OpenAI GPT-5) → secondary provider (e.g. Claude Sonnet 4.6) → degraded mode (e.g. a deterministic non-LLM path that returns a "this feature is temporarily reduced" UX) → human queue (e.g. the request lands in a support inbox). The gateway routes based on health checks (rolling latency p95, 429 / 5xx rate, explicit health endpoint), not blind retry — blind retry on a degraded provider just stacks the same failure twice.

The drill: a calendarised monthly exercise where we simulate the primary provider being down (kill the key, blackhole the endpoint, set the gateway health check to fail), watch the fallback chain run through every hop, measure the latency hit, and read the user-facing UX in degraded mode. Most production-grade ai integration services engagements ship this; most that don't, hit their first real outage as a Slack-channel-3am-fire-drill.

Integration is the seam between your existing product and an AI model. Workflow automation is the seam between your existing tools (CRM, ERP, ticketing, data warehouse) and event-driven orchestration with LLM-in-the-loop — different shape, different deliverable. MLOps is the production-ops layer (model serving, drift detection, feature stores, observability platform) that the integration plugs into at scale. AI agent development is when the AI is the product, not a feature inside another product — multi-step tool-using agent with planner / executor / verifier separation.

Most real engagements straddle two of these. We're explicit about the seam: P10 owns "we have a SaaS product, we want to add AI features"; P3 owns "we're building the AI app from scratch"; P12 owns "the AI feature is in production, monitor and operate it." When an engagement spans, we name the seams in writing before scope gets locked.

Part of the integration, always. An ai feature integration without an eval set is a one-shot demo that ages out the week after a provider releases a new minor version and the behaviour drifts. The eval set lives in Inspect AI or Promptfoo; it gets versioned in your repo; it runs in CI on every model upgrade; it gates the rollout flag flips at 1% → 10% → 100%. We ship a starting set of 20-80 examples graded against the actual task — task-specific, not generic — and a process for adding to it from production traces monthly.

Without the eval set, the failure mode is silent regression: the model changes, the integration still returns 200s, and a user-facing quality bug shows up three weeks later in a support ticket. The eval set is the cheapest insurance you can buy on an integration.