What the agent will ask you

A coding agent that builds on Studio follows a short protocol: it asks before it builds, checks numbers with you before it trusts them, leaves the person-only steps to you, never invents data, and walks you through the result. This page is the protocol from your side of the conversation, so nothing it asks surprises you.

The protocol

This is the text Studio gives every coding agent (it is the first thing studio_guide returns, and the raw copy is at working-with-the-person):

The person you are building for is usually not an engineer. Hold their hand: they decide, you do the work, and nothing reaches other people until they have seen it.

1. Before building, ask. What decision will this help them make? Who will use it? How do they define the numbers involved (for example, what counts as a "failed order")? Which time windows matter (last 7 days, this month, week over week)? Do not start until you have answers; write them down in your plan.
2. Before trusting data, check it with them. Run the queries first, show a few sample numbers, and ask the person to compare them with something they already know: "Last week's failed orders come to 412. Does that match your dashboard?" Do not build on numbers they have not confirmed. If they do not match, find out why together.
3. Some steps only a person may take. Publishing, approving a send, sharing, and exposing a function or workflow to agents or chat are done by the person in Studio. Before each one, say what it does and who it affects, give them the link, and wait for them to do it. Never try to work around a step that needs a person.
4. Never invent data, causes or ids. If you do not know a number, a reason or an id, say so and find it with a tool, or ask. Do not guess a model id, a metric name, a function ref or an email address.
5. After building, walk them through it. Tell them what to open, what to click and what they should see. Then list everything you created (apps, functions, workflows, schedules) and how to switch each one off.
6. Plain words. No jargon. The first time you use a term (a "function", a "workflow", a "publish"), explain it in one short sentence.

What it looks like from your side

Before it builds, expect questions like:

• "What will you decide, or stop worrying about, with this?"
• "Who else will look at it, and how often?"
• "When you say failed orders, do you mean payment declines only, or cancellations too?"
• "Which window matters: yesterday, the last 7 days, this month against last month?"
• "Which tool should the alert go to, and who should approve it before it goes out?"

Short answers are fine. If you do not know, say so; the agent can show you what the data offers and let you choose.

While it builds, expect it to show numbers and wait:

• "The model's data runs from 1 February to 20 September. Your question is about this week, which is past the end of the data. Do you want the last complete week instead?"
• "Failed orders by reason for last week: card declined 231, out of stock 118, other 63. Does the total of 412 look right?"

Compare with something you trust. A number you have not recognised is not a number to build on.

At the person-only steps, expect a link and a pause:

• "The function order_kpis is ready. Its first publish needs your confirmation because it is the first version that can run in your workspace. Open this link, check the summary, and press Publish; then tell me and I will continue."
• "This email needs your approval. It is in Studio under Approvals; it shows exactly the subject, body and table that will go out."

After it builds, expect a walkthrough and an inventory:

• "Open the app link. You should see two tiles with today's orders and the failed-order percentage, and an 'as of 09:14' note with a Refresh button. Press Refresh and the numbers should update within a few seconds."
• "I created: the app 'Order health' (draft version 2, published version 1), the function order_kpis (published v1), nothing else. To switch the function off, open it in Studio and choose Disable; pinned apps keep working with the version they use."

The steps only you can take

Step	Why a person	Where
Publish an app version, especially one that adds a function or workflow import	It becomes live for everyone who can see the app	The app's page in Studio, or say "publish" and approve the tool call
Confirm a function's first publish, or any publish that widens what it may do (a new capability, model, query, audience, exposure, a bigger size or timeout)	It changes what can run in your workspace	The link the agent gives you, .../functions/<name>?publish=v<n>
Publish a workflow with gated changes (a new or changed send, its approval, a new query or model)	Sends reach people	The workflow's page in Studio
Approve or reject a send	Nothing leaves without a person	Studio → Approvals
Share an app beyond yourself	Access for others	The app's Share control
Expose a function or workflow to agents, chat or MCP	Other automations could call it	The function's or workflow's settings
Turn on "send on success" for a workflow	Removes the approval step	The workflow's settings
Allow a connected tool's action to run without approval	Slack, Jira, PagerDuty actions	Workspace admin only

An agent that tries to get around any of these is misbehaving; stop it and tell Bicycle.

If the agent does not behave like this

Paste the block from The start-here guide into it, or ask it to call studio_guide (landing). If it invents a number or a cause, ask "which tool gave you that?" A well-behaved agent can always point at the query or the run.