Worked examples
Each page here is one complete build, written for a person who is not an engineer and who has a coding agent (Claude Code, or Claude Desktop connected to the Bicycle Studio MCP) doing the typing. Every page follows the same shape:
- What you will have at the end. The screen, the email, the number.
- What the agent will ask you before it builds. The questions it should put to you, and the sample numbers it should show you so you can check them against something you already know.
- The pieces it creates. Every app, function, agent, workflow or schedule, by name.
- The steps, in order. Steps marked Only a person cannot be done by the agent: Studio refuses, and the agent must give you a link and wait.
- How to test it.
- How to switch it off.
- Copy for your agent. A prompt you can paste into your coding agent to start the build.
If you have not connected a coding agent yet, start with Connect a coding agent and How the agent works with you. If you have never published an app, do Your first app first.
The six examples
| Example | What it builds | What it teaches | Time |
|---|---|---|---|
| KPI app with a code function | Two tiles (today's orders, failed-order %) computed by a small Python function, with "as of" and Refresh | Functions, declared queries, page-load reuse, the first-publish confirmation | About 1 hour |
| Triage button backed by an agent | A list of yesterday's failed orders; each has a Triage button that routes it to payments, stock or other, with a two-sentence summary | Agent functions, progress lines, Cancel, queues, never running an agent on page load | About 1 to 2 hours |
| Weekly digest email with a screenshot | An email every Monday morning with last week's failed orders by reason and a screenshot of an app, sent only after you approve it | Workflows, steps, when guards, try runs, gated publishes, the approvals inbox, pausing a schedule | About 2 hours |
| Train a model weekly, predict daily | A workflow that trains a small model each week, predicts each day, and a Predict button in an app that shows the result | Workflow blobs, safe model files (skops, not pickle), calling a workflow from an app | About 2 hours |
| What changed, and why: Detect and Explain | An answer to "what moved in failed orders last week, and what drove it", then the same analysis shared with everyone who opens the app | analysis_run and analysis_result, declared analyses, what workflows cannot do yet | About 45 minutes |
| Chat that answers from your functions | The app's Ask AI chat answers "what was the failed % on 20 September?" by calling your KPI function instead of guessing | Functions in chat, exposing a function to agents, checking a run in Runs | About 45 minutes |
The examples build on each other: 2, 4, 5 and 6 reuse the app and function from example 1. You can do them in any order, but the agent will need the KPI function from example 1 for most of the others.
Rules every example follows
Read these once; every page assumes them.
- Preview first. Every example is built on the Bicycle preview environment, which exists for testing, before anything goes to production at
https://app.bicycle.ai. Ask your Bicycle contact for the preview address if you do not have it. - Only allowed email addresses. On preview, Studio sends email only to addresses on the deployment's allowlist. Every recipient in these pages is written as
ops@yourcompany.com; replace it with an address your deployment allows. If the agent uses any other address, Studio refuses it (recipient_not_allowed) and nothing is sent. - Name test objects with a prefix. Give every app, function and workflow you build while learning a title prefix such as
Test(for exampleTest KPI app). Then they are easy to find, disable or unpublish later. - Never change an existing app. The agent always creates a new app (or a new version of an app it created for you). It never edits, shares or captures somebody else's app.
- Some steps are yours. Confirming the first publish of a function or agent, publishing a workflow that sends something, approving an email, sharing an app with the workspace, and switching a function on for agents or chat are done by you, in Studio. The agent gives you a link and waits. Never ask it to work around one of these; it cannot, and it should not try.
- Numbers you have not checked are not numbers. Before the agent builds on a query, it shows you a sample ("last week's failed orders come to 412") and asks whether that matches what you already know. All numbers in these pages are illustrative; check yours against your own dashboard or report.
Where things show up in Studio
Studio's navigation bar has Apps, Functions, Agents, Workflows, Approvals and Runs. Everything the agent builds appears under one of the first four; everything that runs, from any of them, appears under Runs with one set of status words: Waiting to start, Running, Done, Done (reused), Waiting for approval, Failed, Partly done, Cancelled. Emails and other sends that need your approval wait under Approvals.
Some things the agent could once only do through Studio's pages are being added to the agent's tools ("landing", in these pages). Where a page says "in Studio, open the workflow and choose Pause", that is the way to do it today; the agent will tell you when it can do it for you.
What to read alongside
- Data apps, Functions, Agents, Workflows, Detect and Explain for the ideas behind each example.
- Runs and traces to see what happened after you press a button.
- Limits and safety for the caps that bound every run (cost, time, recipients).
- Troubleshooting when a tool answers with a code you do not recognise.