In short
You do not wire an in-app assistant up by hand. The coding agent your team already uses adds the SDK to your app, reads your API and registers your actions, working against a setup token that is good for one app, for 24 hours, and only for the setup endpoints. Pilots have taken about two weeks from installing the SDK to shipping behind a flag.
On this page
Why an agent does this part
Registering an action means describing one of your endpoints: what it is called, what it is for, which parameters it takes and what their types are. That is a translation job across however many endpoints you want the assistant to reach, and it is exactly the kind of work a coding agent with your repository open is better at than a person filling in a form.
The agent is working on your machine, in your codebase, with your API in front of it. Nothing about your API has to be sent anywhere for it to be described.
What the setup token can and cannot do
The agent does not get a key to your account. It gets a setup token, and that token is deliberately small: it works for one app, for 24 hours, only on the setup endpoints, and it ends when the run completes.
Two rules sit behind it and they are the ones worth repeating to whoever asks. A setup agent never changes what a live key serves — whatever is already in front of customers keeps working exactly as it did while the agent is mid-run. And a setup agent never sends Rendel a secret: the values your actions need stay yours.
| A setup token | A live key | |
|---|---|---|
| Scope | One app, the setup endpoints | One app, serving real conversations |
| Life | 24 hours, ends with the run | Until you rotate it |
| Touches what customers see | Never | Yes — that is the point |
| Carries your secrets | Never | No: a saved key goes only to its own host |
What still has to pass
An agent finishing is not the same as being live. A live key is refused until Go live, and Go live is five checks run on our side, not a checkbox you tick: the kind of thing that catches an action registered against an endpoint that is not actually reachable yet.
That ordering is on purpose. The cheap part — describing your API — is automated. The part that decides whether real customers meet it is not.
One operational note while you plan: we may refuse builds below a minimum SDK version, so an app that sat unreleased for a long stretch may need a version bump before it serves anything.
How long it actually takes
Pilots have taken about two weeks from installing the SDK to shipping behind a flag. Most of that is not installation. It is the ordinary work of deciding which three things customers do most, which of those the assistant should be allowed to carry out, and which need a confirmation before anything changes.
The agent gets you to a working assistant in an afternoon. The fortnight is the part where your team decides what it is allowed to do, and that part does not compress.
Questions
The one your team already uses. The setup runs against a documented API with a short-lived token, so an agent that can read your repository and call an endpoint can do it.
No. A setup agent never changes what a live key serves. Whatever is in front of customers keeps serving while a run is in progress.
A setup agent never sends Rendel a secret, and a saved key goes only to its own host. Placeholder values are encrypted at rest.
They run on our side against the app you are about to put live, and a live key is refused until they pass. `/docs/guides/go-live` lists them.
