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 that says, for each line, whether the design review checks it or you confirm it.
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. Besides the design of the steps, properties and tools, the review checks several of the settings in the sections that follow, such as test mode, error escalation and data retention; the Checklist at the end says which. 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 mode, approvals and security settings
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. The design review reports it as a critical finding, Test mode on. 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.
Check the security and compliance settings. Open Settings → AI Governance and review the Security Guardian and Compliance Guardian sections. Security Guardian holds Detect and block dangerous content in workflow inputs, which stops a step from starting when its input values carry instructions aimed at the AI, such as text typed into a form or an email reply; Detect and block dangerous content in tool outputs, which stops the agent from acting on instructions hidden in what its tools bring in; and Chat messages may contain sensitive information for thunks whose chats hold personal or confidential details. Compliance Guardian shows the protections your deployment provides, such as data isolation and AI Fingerprint, which you can confirm but not change. These sections are available on plans that include them. If the thunk's inputs come from people or systems outside your team, also consider Check workflow inputs against column descriptions in Reliability Guardian, which stops a step whose inputs are a placeholder or the wrong kind of value; it works best when every input property has a clear description. See AI Governance and Hiding sensitive data in the UI.
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 (minutes) 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
Each line says who checks it. Design review lines are checked every time you run the review in Deploy → Review: the name in brackets is the finding you see when the line is not met. You confirm lines need a person's judgement, so the review cannot answer them; work through them yourself. You can also ask Claude or Codex with the Thunk.AI plugins "is this thunk ready for production?": the agent runs the review, goes through every line with you, and makes the fixes you pick before you promote the thunk (see Checking deployment readiness with the FDA MCP and Build thunks from Claude Code or Codex).
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. You confirm.
Custom tools that reach other systems have tool tests that pass. Design review (Missing tests, Tests not run, Stale test run, Tests failing).
A design review has been run on the current version, and each finding is fixed or accepted. Deploy → Review shows when the review is out of date, and promoting asks you to confirm it.
The pass rate, coverage and known gaps are written down, and the process owner has agreed to go live. You confirm.
Environment and model
A Production environment is available for the thunk, with the models and tools it needs. You confirm.
The tests have been run on the model the thunk will use in Production. You confirm.
Connections and tools
Each connection signs in with an account suited to live work, and every connection exists in the Owner's account. Design review (Environment config, and Tool not available for a tool a step's instructions name); you confirm whose account each connection uses.
Someone is named to renew each connection's credentials. You confirm.
Every stand-in or mock tool has been replaced by the live tool. You confirm.
Each step can call only the tools it needs. You confirm.
No password, key or token is typed into a custom tool. You confirm.
Settings
Treat all rows as test rows is off. Design review (Test mode on). This finding is critical: the review fails until it is off.
Test-only text and settings have been removed. You confirm.
Every action that cannot be undone has a human approval, or a check before it runs. Design review (No approval before outside action, Retry risk) for steps that send messages or write files; you confirm the rest.
The Security Guardian and Compliance Guardian settings have been reviewed. Design review (Public inputs not checked) when the thunk takes work through a form link; you confirm the rest.
Someone is set to hear about errors. Design review (Errors not escalated).
People
Only the people who need access have it, in the right role. You confirm.
At least two people can pause and fix the thunk. Design review (Admin coverage).
Every step that waits on a person has someone who will act on it. The design review lists these steps (Human-in-the-loop); you confirm who acts on each.
How work arrives
Each production source is connected, and test sources are removed. You confirm.
You know which fields each source always sends. You confirm.
You know who can send work to the thunk, and what the agent may do with it. Design review (Routing config, Routing instructions) for each channel's instructions; you confirm who may send.
Data
Auto-finish, auto-delete and the retention period are set on purpose. Design review (Data retention not chosen).
Work items from trying the thunk by hand are deleted, and the test suite is kept. You confirm.
Monitoring and recovery
Someone is named to watch Monitor, with a schedule. You confirm.
Cost and time figures from testing are noted for comparison. You confirm.
A report or tracking is set up for the outcomes that matter. You confirm.
Everyone who watches the thunk knows how to pause it and move it back to Testing. You confirm.
Go-live
The thunk is promoted to Production in the right environment. You confirm.
The first real work items are watched and read. You confirm.
Each problem found becomes a test work item before it is fixed. You confirm.