You have built a thunk, tried it out and tested it, and now it should do real work. This article covers what to check before you promote it to Production, how to promote it, and what to watch in its first days. It ends with a checklist you can work through, with a link to the article that explains each line.
For the buttons that move a thunk between phases, see Lifecycle of a Thunk. For a map of the whole lifecycle, see From prototype to production: the thunk lifecycle.
This article has three parts. Concepts explains what changes when a thunk goes live. Details walks through each check in the order to do it. Checklist puts them all on one list.
Concepts
Production means real systems, real people and real data
In Prototype and Testing, a thunk usually works with sample files, mock services and test accounts, and a mistake costs a re-run. In Production, the thunk sends real email, updates real records and acts for real requesters, and a mistake can reach a customer before anyone sees it. Most of the checks below make sure that every tool, connection and setting the thunk uses is the one you meant for live work, and that a person stands in front of every action that cannot be undone.
Decide go or no-go from evidence
Do not promote a thunk because it worked the last few times you tried it. Promote it when its automated tests cover the cases it will see, pass at a rate you can accept, and the known gaps are written down and agreed with the people who own the process. See Production readiness and quality control.
Know how to stop it before you need to
Before the thunk takes real work, know who will watch it, where they will look, and what they will do when something goes wrong: pause the thunk, put a step back to an earlier version, or move the thunk back to Testing. Finding out how to stop a thunk while it is sending the wrong email is too late.
Details
1. Tests and design review
Run the full test suite on the thunk as it will go live. Re-run every test work item after your last change and read the failures. A failure is either a problem in the thunk (fix it), a wrong test (correct it), or a known gap (write it down). Do not weaken a test to make it pass. See Automated tests for workflow steps.
Test the custom tools on their own. Each custom tool that reads from or writes to another system should have tool tests of its own. See Automated tests for custom tools.
Run a design review and act on it. Open Deploy → Review, run the review on the current version, and fix or knowingly accept each finding. Promoting asks you to confirm the review, and warns you when it is out of date or has open issues. See Workflow Review.
Record the evidence. Note the pass rate, which cases the tests cover, and the known gaps, and agree the go-live with the process owner.
2. Production environment and AI model
Each phase runs against an environment that your administrator sets up. The environment decides which AI models and which tools the thunk can use. A Production environment usually points at live services, where a Testing environment points at sandboxes.
Confirm a Production environment is available for the thunk. When you promote, the Deploy to dialog lists only the environments your administrator has made available for Production. If the list is empty, or does not offer the model or tools the thunk needs, ask your administrator. See Configuring Environment Settings.
Check the model the thunk will run on. The thunk-wide model is in Settings → AI Settings, and a step can override it with its own Preferred model. If Production offers different models from the ones you tested on, run your tests on the Production model first. See Move a thunk to a new AI model.
3. Connections and tools
The AI agents in a thunk run as the thunk's Owner and use the connections in the Owner's account. See Users and access controls.
Decide whose account each connection uses. A connection that signs in as a person stops working when that person leaves or their access changes. For a thunk the business depends on, prefer connections that sign in with a shared or service account your team controls.
Make sure the Owner has every connection. The connections must exist in the Owner's account. If ownership moves to someone else, the new Owner needs them too: any that are missing are marked Not available, and the workflow runs without their tools. See Users and access controls.
Know who renews each credential. For every connection, name the person who replaces its password, key or token when it expires.
Point every tool at the real system. Remove any stand-in or mock tool you used for testing, and connect the live tool, or bind a plug-in connection to the real system. See Improve a live thunk safely.
Give each step only the tools it needs. A step that can call every tool can send, write or delete far more than its instructions intend. Check which steps can call tools that change things outside the thunk, and turn off the rest. See AI Tool Libraries.
Keep secrets out of the design. A password, key or token typed into a custom tool's address, headers or code belongs in a connection instead. See Connections to Business Applications.
4. Test settings off, approvals on
Turn off test mode. If you turned on Treat all rows as test rows in Tests → Test Settings while testing by hand, turn it off. While it is on, real work items run under test policy: email can be suppressed or redirected, and steps marked to skip for test work items do not run. See Manual testing.
Remove test-only text from step instructions, and any setting you changed only to test.
Put a person in front of actions you cannot undo. For a step that sends an outbound message, makes a payment or changes a record in another system, turn on Require Human to review and finish step, or add an approval gate for the whole thunk in Settings → Human-in-the-loop Manager. See Set human approval gates for your workflow.
Guard steps that read outside content. An incoming email, uploaded file or chat message can contain text written to steer the agent. A step that reads such content and can also send, write or delete should run only after a check: a property that classifies the request and a condition on the step, or a human approval. See Secure AI Agents.
Decide who hears about errors. Escalate errors to owner, in the same Human-in-the-loop Manager section, alerts the thunk owner when the AI hits an error.
5. People and access
Check who holds each role. Owners and Admins can change the thunk and see all its data; Human Agents work on the steps assigned to them; End Users only use the chat interface. Remove the people who only needed access while you built and tested. See Users and access controls.
Have at least two admins. Someone besides the Owner should be able to pause the thunk, read its errors and fix it.
Make sure every step that waits on a person has someone to act. If a step is assigned to a person or pauses for approval, the people who will act must have a role in the thunk and know where to find their work. See Find work that is waiting on you.
6. How work arrives
Check each way real work will reach the thunk — its Email Inbox, a webhook or form link, the REST API, the hosted Chat UI, or tools the thunk publishes to other AI agents. See Inbound Requests.
Connect the real sources. Point the production systems, forms and mailboxes at the thunk, and remove test senders and test webhooks you no longer need.
Know what each source sends. Confirm which fields are always present. A step that relies on a field that is sometimes missing will fail on those work items.
Decide who may send work. Anyone who has a webhook's form link can send the thunk a request without a Thunk.AI account. Email is accepted only from the thunk's owner, its admins and the Allowed Email Senders you add. Check each list, each channel's instructions, and what the agent is allowed to do with what arrives. See Receive requests through a webhook or a shared form and Send requests to your thunk by email.
If the thunk is published to other thunks or AI agents, check which tools it exposes and who may call them. See Publish your thunk as an MCP server for AI agents.
7. Data retention
By default nothing is auto-finished or auto-deleted, and deleted work items stay recoverable for 7 days. A production thunk should have these settings chosen on purpose. They are in Settings → AI Governance → Compliance Guardian, in the Data retention block. See Data Retention.
Auto-finish inactive work items after (hours) ends work that has stalled, so it does not pile up. Leave it off, or use a large number, when work items normally wait on people for a long time.
Auto-delete finished work items after (days) removes finished work on a schedule. Agree the period with whoever is responsible for the data the thunk holds, especially personal details.
Data retention period for deleted items (days) decides how long deleted work items can still be recovered.
Before you go live, also delete the work items you created while trying the thunk by hand, so they do not mix with real work in reports and counts. Keep the test work items that make up your test suite: you will re-run them after every change.
8. Monitoring
Decide who will watch the thunk, and how often. Monitor is available to the thunk's Owner and Admins. See The Monitor pane: what each tab is for.
Errors shows failed runs and the daily error rate. See Troubleshooting Errors.
Cost and Time show what the thunk spends on AI and how long its work takes. Note today's figures from your test runs, so you can tell later whether production differs. See Token Costs and Time Analysis.
Reports save a view of your work items you will check often, such as the work items that ended needing a person. See How to save a report from your work items and Send reports on a schedule with the report automation.
Tracking sends an event to your own monitoring or analytics system when a work item finishes. See Observability and Monitoring.
Not every failure is an error: a work item that finished but handed off to a person, or found nothing, does not appear on Errors. Decide which properties record how a work item ended, and watch their counts. See Checking a thunk's health: where to start.
9. Plan how to stop and roll back
Pause. Deploy → Pause / Restart stops all AI work on the thunk at once, and Unpause starts it again. Only the Owner and Admins can do this. See Pause and restart a thunk.
Put a step back. Every change to the thunk's definition is recorded, and you can restore a step to an earlier version. Other parts of a thunk, such as properties and settings, are restored by hand from the change log, and deletions are not recorded. See Versioning Support for your Thunk.
Move back to Testing. Deploy → Phase → Go back to Testing returns the thunk to a testing environment so you can keep working on it. See Lifecycle of a Thunk.
10. Promote, then watch the first work items
Open Deploy → Phase and select Move to Production.
Pick the Production environment, confirm the design-review reminder, and select Select and Deploy.
Let a few real work items through while someone watches. One way is to turn on Create new workflow requests in Draft mode for the first days, so a person looks at each new request before the AI starts on it, and turn it off again once you trust the results. See Set human approval gates for your workflow.
Open the first work items and read what each step did: the tools it called, the values it wrote, and how it finished. See Analysis of AI behavior.
Check Monitor → Errors daily for the first week, then on the schedule you agreed.
Turn each problem you find into a test work item, fix it, and re-run the tests before the fix goes live.
Once the thunk is running well, keep it that way with regular health checks. To change a thunk that is already live without touching the real systems while you test, see Improve a live thunk safely.
Checklist
Tests and review
Every test work item has been re-run after the last change, and each failure is fixed, corrected or written down as a known gap.
Custom tools that reach other systems have tool tests that pass.
A design review has been run on the current version, and each finding is fixed or accepted.
The pass rate, coverage and known gaps are written down, and the process owner has agreed to go live.
Environment and model
A Production environment is available for the thunk, with the models and tools it needs.
The tests have been run on the model the thunk will use in Production.
Connections and tools
Each connection signs in with an account suited to live work, and every connection exists in the Owner's account.
Someone is named to renew each connection's credentials.
Every stand-in or mock tool has been replaced by the live tool.
Each step can call only the tools it needs.
No password, key or token is typed into a custom tool.
Settings
Treat all rows as test rows is off.
Test-only text and settings have been removed.
Every action that cannot be undone has a human approval, or a check before it runs.
Steps that read outside content cannot act without a check.
Someone is set to hear about errors.
People
Only the people who need access have it, in the right role.
At least two people can pause and fix the thunk.
Every step that waits on a person has someone who will act on it.
How work arrives
Each production source is connected, and test sources are removed.
You know which fields each source always sends.
You know who can send work to the thunk, and what the agent may do with it.
Data
Auto-finish, auto-delete and the retention period are set on purpose.
Work items from trying the thunk by hand are deleted, and the test suite is kept.
Monitoring and recovery
Someone is named to watch Monitor, with a schedule.
Cost and time figures from testing are noted for comparison.
A report or tracking is set up for the outcomes that matter.
Everyone who watches the thunk knows how to pause it and move it back to Testing.
Go-live
The thunk is promoted to Production in the right environment.
The first real work items are watched and read.
Each problem found becomes a test work item before it is fixed.