Set up with AI, in detail
Which agents run the setup file, what the agent changes in your code and in the console, the token it carries, and what to do when it gets stuck.
Set up with AI is the short version. This page is what happens underneath: the agents and how to start them, every step the file asks of the agent, what the setup token can and cannot do, and how to recover when a run stops halfway.
The agents
The console gives you one prompt for each of six coding agents, and it is the same prompt for all of them: Claude Code (the app, an editor or the terminal), Codex, Gemini CLI, Cursor in Agent mode, Windsurf's Cascade and GitHub Copilot's agent mode. Paste it into the agent, opened in your project. It asks the agent to fetch the setup file into the project root with curl and follow it, and it names, in your words, the file's address, the SDK's source and what goes to https://rendel.ai/api/setup, so an agent that checks what it sends out knows you asked for it.
The file is Markdown with skill frontmatter (name: rendel-setup), so it also works moved into .claude/skills/, .agents/skills/ or .cursor/rules/; it tells the agent to use its new path.
The agent needs to run shell commands in your repository: it calls the setup API with curl, builds your app, and runs its tests. On Windows it runs those commands in Git Bash or WSL.
What the agent does
The file is generated when you fetch it, for your app, with the current SDK versions in it. It has no instructions fetched from elsewhere: everything the agent follows is in the one file. In order:
| # | Step | In your code | In the console |
|---|---|---|---|
| 0 | Start | Nothing | Claims the session (panel: Agent connected) and reads what Rendel already knows: your links, what was read from your website, the current configuration, both publishable keys, the SDK snippets and the JSON Schema of every request |
| 1 | Discover | Nothing; reads only. Platform, router, HTTP layer, sign-in, theme (and dark theme), fonts, logo, languages, screens, API calls, in-app help | A discovery report and a plan, shown on the panel |
| 2 | Install | The SDK dependency, Rendel.init (test key in debug builds, live key in release builds), iOS permission strings, and a way in that fits the app: a launcher button or a button in its own bar | — |
| 3 | Identity | identify at sign-in and on a restored session, reset at sign-out, and userToken handing over the token your app already sends to its own API. Skipped for an app with no sign-in | — |
| 4 | Appearance | themeMode if the app has its own light/dark setting, or is always light | Your colours, corner radii, font and card style into the draft, with a dark theme if the app has one; the logo from the repository. Rendel answers with any contrast problems, and the agent fixes them once |
| 5 | Experience | — | The assistant's name, tone, instructions, guardrails, topics it won't discuss, languages, welcome title and line, and up to four suggestions, into the draft |
| 6 | Knowledge | — | Your public pages as links (Rendel fetches them), and texts written from your code: what each main screen is for, in-app FAQ, plans and prices, refund and cancellation rules, a summary of the terms |
| 7 | Screens | registerRoute for each screen a user might ask to open, through your own navigation | The same screens declared, so the console can show them as planned until a build registers them |
| 8 | Actions | registerAction only where the call cannot be made from a server (see the table) | Every other API call as an HTTP action Rendel's server makes. One that needs a shared key is saved off |
| 9 | Verify | Runs your tests, analyzer and a debug build; runs the app once with the test key if it can, or asks you to | Waits until Rendel sees the app call in and its manifest arrive, then compares the screens and actions in it with what it registered |
| 10 | Test | — | Waits for knowledge to be indexed, then asks Rendel to run a smoke test. If it fails, rewrites what fell short once and runs it once more |
| 11 | Leave-behind | Asks you before adding a short Rendel section to AGENTS.md or CLAUDE.md; checks the file is ignored; commits on rendel/setup | — |
| 12 | Complete | Deletes the setup file | A summary, the files it changed, and your to-dos. The session ends and the token stops working |
The order is deliberate. The SDK goes in early so your app can call in as soon as you run it. The console steps come before the screens and actions because they are quick and knowledge indexes in the background meanwhile. Screens come before actions so a screen's values can be tied to what an action returns.
The rules it is given
The file opens with rules that hold for the whole run:
- Run
git statusfirst and ask you if the tree is not clean; then work on a new branch. - Never put the setup token in code, in
.envor in any file, and never commit it. - Only publishable keys go into your code: the test key for debug and development builds, the live key for release builds.
- Never send Rendel your API secrets, your users' data or the contents of
.env. - Never fetch your website itself; send the address and let Rendel read it.
- Only add to existing screens and flows, and build after every step that changes code.
- Report progress only for the steps that happen in code, in batches.
- Where unsure, assume, say so in the report, and carry on; ask only before something destructive.
- If it cannot go on at all — the SDK will not install, the project did not build before it started, the app is neither Flutter nor web — report that and stop.
Where it writes
| Lands as | Live users see it | |
|---|---|---|
| Appearance, logo | The draft config | Published when the setup finishes |
| Experience | The persona draft | Published when the setup finishes |
| Knowledge | Sources marked AI setup, indexed as soon as they are written | Once indexed — but a live key is not served until you go live |
| HTTP actions | Actions marked AI setup, on unless one needs a key | After you go live |
| Screens | Planned on the Screens page | Once a build that registers them runs |
Every write is keyed by a name the agent chooses (external_key, such as screen:settings/subscription or GET /v1/orders). Running setup again updates what is there instead of adding a second copy, and a key you entered by hand on an action is kept.
Nothing the agent writes deletes anything. Where something has gone from your code, a later sync archives it.
Token and security
The file's only secret is the setup token, rd_st_ and 24 hex characters.
- It lasts 24 hours and only works on Rendel's setup API (
/api/setup/*), for this one app. - It cannot reach a live app. Once the app has gone live, every setup request answers
409 app_live; changes after that go through Sync with code, where a person reviews them. - It cannot publish by itself. Appearance and Experience land in drafts that only your test key sees. When the agent reports back, Rendel publishes them and goes live if the four Go live checks pass; the token has no request that does either.
- It cannot read conversations, users, or any key but the two publishable ones, which are public by design.
- It cannot carry a secret. No request has a field a password or API key could go in. An endpoint that wants a shared key is saved switched off, and you enter the key in the console.
- It goes only in the
Authorizationheader, never in a URL, so it does not end up in proxy logs. It does show on the agent's command lines; that is expected, and why it is short-lived and narrow. - Rendel stores only its hash. A copy of the database hands nobody a working token.
- One at a time. The first agent to start owns the session and a second is refused. Fetching a new file mints a new token and stops the old one at its next request. Finishing, failing or pressing Stop ends it too.
Your website is read by Rendel's servers, through the same guard that keeps a linked knowledge page from reaching private addresses — never by the agent. An agent holding a token should not also be reading pages someone else wrote.
Every change the agent makes is in your app's audit log under setup:<session id>, so it is never mistaken for the person who started the session. Settings → AI setup sessions lists past and running sessions with their summaries, and cancels a running one.
If it gets stuck
| What you see | What it means | What to do |
|---|---|---|
| A step turns red with Your agent got stuck | The agent reported that it could not go on, with its reason | Fix what the reason names (often the project did not build before it started), then get a new file and run it again. What it already wrote stays and is updated, not duplicated |
| Your agent is quiet after 15 minutes | No request for a while | Look at your agent: it is usually waiting for you to approve a command or answer a question |
The agent says the token is invalid (401) or the session closed (410) | A newer file replaced it, it ran out after 24 hours, or someone pressed Stop | Get a new file |
409 already_claimed | Another agent started this file first | Get a new file for the agent you want |
409 app_live | The app has gone live | Use Sync with code |
| Building and verifying never turns green | The app has not called in with the test key | Run the app once. If it still does not appear, check that Rendel.init runs at startup and uses the test key |
| Test conversation fails | Fewer than 80% of the smoke test's answers were grounded in knowledge or backed by an action | Read the answers on Overview. Sharpen the descriptions of actions that were not used, add the knowledge that was missing, and press Run smoke test |
| Test conversation fails and every answer is an error | A problem on Rendel's side, not in your setup; the agent's line on the panel says a server problem, not this configuration | Change nothing. Press Run smoke test again later |
flutter pub get fails on the SDK | The machine cannot reach GitHub | The package is in a public repository; check the network or proxy |
| The app is not Flutter or web | The agent stops at Discover and says so | There is no SDK for it yet. Native iOS, native Android and React Native are planned |
Whatever the agent wrote into the console stays editable there, on the Knowledge, Actions, Screens, Appearance and Experience pages. If it stopped partway, get a new file and run it again: it picks up what is already there.
Writing your own agent
The file is one client of a documented API. If you run setup from a CI job or your own tooling, the Setup API reference has every endpoint, body and answer.