Use case · AI
Production agents, wired like the rest of your app.
Streaming chat, typed tools, retrieval over your own data, and traces that survive the agent into the same observability dashboard. The four sub-systems an AI product needs are wired into the registry before your first commit.
What's in the box
The four sub-systems every AI product needs.
Eleven capabilities grouped by the buyer-side question they answer. Pick a cluster, read what you actually get, and ship it.
Conversational agent
The user-facing surface. How the agent talks to the user, and stays coherent past the first reply.
Streaming responses
Tokens stream token by token over server-sent events, no WebSocket plumbing, no 4-second silence before the first character. The cursor sits at the end of the stream until completion, and the user can cancel mid-stream without orphaned tokens.
Conversation memory
Conversation state persists across turns and sessions. The agent reads prior messages before each step, so 'what was that variable again?' works without rebuilding the prompt inline. Memory writes go through the same observability contract as the rest of the app.
Pausing for clarification
When the model needs more input, the agent pauses the run and asks the user a typed choice. No 'context has gone, please re-enter' surprises — the run resumes with the new input appended.
conversational-agent
Agent rungpt-5 + tools
- planI need billing data for org_2nK9xR
- billing.readGET /v1/orgs/org_2nK9xR/billing
- ok{ mrr: 1127, plan: "pro", seats: 8 }
- planFormat the answer for the user
Run complete - 4 steps, 1.4s, 847 tokens
Tool integration
Where the agent stops being a chat and becomes useful — the contract surface where it touches the rest of your app.
Typed tool schema
Tools are TypeScript functions; the schema is the contract your agent calls. Inputs and outputs are typed against the same registry your UI reads, so a tool that compiles in your app compiles for the agent.
Hono + oRPC bridges
Procedure types from your existing oRPC router flow into the agent's tool manifest. The agent consumes the contract, not the implementation — no drift between what your UI does and what the agent does.
Auth + rate limits, applied
Auth and rate limits follow the same rules when the agent calls as when a user does. Every tool call carries the org context, so a customer-scoped tool only reads that customer's data.
tool-integration
RequestoRPC
GET
contract: ORG_READ. auth: session
Response...
{
"id": "org_2nK9xR",
"name": "Acme Labs",
"plan": "pro",
"mrr": 1127,
"seats": 8,
"stripe_customer_id": "cus_R8x2Wq"
}Knowledge retrieval
How the agent grounds itself in your domain — without re-training, without a second database.
pgvector, indexed at write time
Postgres + pgvector is the index. The same Drizzle schema your app reads, the same pgvector index the agent queries. No second database to provision, no second backup to schedule, no second connection pool to monitor.
Score + rerank
Search returns scored chunks the agent reads in order. Top results carry enough context for grounding; the agent cites the chunk IDs in its reply so the user can audit what fed the answer.
Documents and KB articles
The same ingestion pipeline handles docs, KB articles, and product schema — anything with a version and a slug. Old versions are pruned automatically so the agent never answers from stale context.
knowledge-retrieval
queryhow does billing handle dunning
- kb_8821dunning sequence runs every 48h...94%
- kb_8810Failed charges retry after 24h...78%
- kb_8798Customer portal shows invoice history.61%
- kb_8754Webhook fires on subscription.cancel.42%
Production operations
How the agent stays correct, fast, and observable the day a customer files a support ticket about a wrong answer.
Run traces
Tool calls, latency, errors, and token counts land in the same waterfall your HTTP routes already use. One OpenTelemetry pipeline. Errors tagged with tool name and call site so a 500 in production has a runtime.
Replay from a trace ID
Every run has a trace ID you can replay from the operator console. Re-run with the same inputs, compare outputs, ship a fix without ever touching production traffic.
Token + cost budgets
Per-run, per-user, per-org. Hard limits surface in the dashboard before the bill does. No month-end surprise when the agent hit an unbounded loop over the weekend.
production-operations
- GET /checkout142ms
- |auth.verify12ms
- |fetch45ms
- |db.query62ms
- -cache.set23ms
Stack
What runs on day one.
Next.js
AI SDK
OpenAI
pgvector
Resend
Process
How an AI product ships.
- Step 01
Define the agent in TypeScript
Tools, memory, and routing live in the same source as the rest of your app. The AI SDK reads them and wires the runtime.
- Step 02
Index what the agent should know
Docs, KB articles, product data — pgvector indexes them in one query. No second database, no second dashboard.
- Step 03
Ship. Every tool call is on the trace.
Tool calls stream into the same observability contract as your HTTP routes. Replay any run from the trace ID.
Built on this
Four templates, each on its own surface.
Production-ready starter templates, each deployed at its own URL. Used as the reference set for what the registry can ship.
Explore
Related use cases.
Related
SaaS apps
Multi-tenant B2B SaaS with auth, billing, and a working dashboard on day one.
Read more
Related
API backends
Service-only backends with type-safe RPC and zero frontend overhead.
Read more
Related
Mobile backend
Auth, sync, and push notifications for native apps, on the same backend.
Read more
Two doors
Use it yourself, or have us ship it for you.
Self-serve gives you the registry and the templates. Engagement gives you the team that built it. Pick the door that fits the timeline.