Embed stories
Three things product teams actually ship on Novo Agents, told the way you would plan them: the ask, what ships, what is underneath in plain words, and why the assembled alternatives don't get you there. Each story ends at a runnable example.
1. The support agent inside your product
The ask: "Our users file tickets that a person triages for an hour. I want an agent in the product that reads the ticket, checks the account in our admin, drafts the fix, and waits for a human click before anything real happens."
What ships: an agent embedded in your support view. It reads the ticket, browses your internal admin in a hosted browser session, drafts the refund or the config change, and then stops. Your reviewer sees the exact proposed action in your UI, edits it if they want, and clicks approve. The agent finishes and the whole run, every step, is in the thread your user already sees.
Underneath, in plain words: the agent pauses on any consequential tool call and waits for a human click, for days if it has to. Your approval endpoint gets a signed webhook before anything fires, and deny is a first-class answer the agent works around. The browser is Novo-hosted with nothing for you to run, and outside content the agent reads is fenced so it can't smuggle instructions.
Why the assembled alternatives don't: pausing a live agent mid-tool-call and resuming it two days later without losing the run requires durable execution under the loop, an interaction store, and stream-resume semantics. That is three infrastructure projects before the first ticket is triaged.
Build it: Build a tool approval hook, then Render a human review inbox and the Interactions API.
2. The research copilot that survives your deploys
The ask: "We want a research panel in our app: the user asks, the agent works for ten minutes across the web and our data, and the panel shows progress live. It cannot die when we deploy or when the user's train goes into a tunnel."
What ships: a panel in your product where every step streams in as it happens: searches, page reads, drafts. The user closes the laptop, reopens it, and the stream picks up exactly where it left off. You ship on Friday afternoon and running research jobs don't notice.
Underneath, in plain words: a run is not a request. It survives crashes, deploys, and dropped connections because it executes durably on Novo's side; your UI just reconnects with the last event id it saw and replays from there. Completion is an explicit terminal event, so your panel never guesses whether it's done.
Why the assembled alternatives don't: on a raw model API the run lives inside one HTTP response on one process. Making it survive your own deploy means building durable execution, event history, and resume cursors around the model call, and keeping all of it correct as your traffic grows.
Build it: Reconnect a dropped stream, then Build a React run UI and Streaming.
3. The metered agent you resell
The ask: "We're adding agents to our SaaS and charging for them. Finance needs to know what each customer's agents cost us, and billing needs a number we can put on their invoice."
What ships: each of your customers gets agent features priced on your terms. Every run carries a hard budget so a runaway task stops before it costs you money. At the end of the month, one API call gives you cost per customer, and your invoice line is that number times your margin.
Underneath, in plain words: issue one Novo API key per customer and every run's cost lands against it, in fractional cents, grouped however billing wants: by key, by day, by band, by thread. budgetCents is enforced with a typed terminal reason, so overruns are a state you handle, never a surprise on the bill.
Why the assembled alternatives don't: token bills attribute spend to your account, at best to a project. Turning that into per-end-customer cost means metering every model call, tool second, and sandbox byte yourself, then keeping the ledger honest through retries and crashes. Novo's ledger is the product.
Build it: the Usage API and Credits API, then Pricing for the metering catalog.
The pattern
Each story is the same four moves: call one API, stream every step into your UI, gate the consequential parts on your humans, and read the receipt. The parts you keep are the parts you'd never outsource anyway: your prompts, your domain tools, your transcript, your UX.