Worker Detail Page
Review worker configuration, instructions, context, tools, and runs.
The worker detail page shows how a worker is configured and what happened during recent runs.
Use it as the first stop before changing a worker. The detail page usually shows whether a problem is caused by status, instructions, context, tools, or the run input.
What You Can Review
The detail page shows:
- Worker status.
- Output mode.
- Template key when the worker came from a template.
- Context sources.
- Callable tool categories.
- Instructions.
- Run history.
Use this page before editing a worker. It shows whether the problem is likely in the instructions, the selected context sources, the enabled tools, or the record that triggered a run.
Review Configuration
Check the worker configuration in this order:
- Confirm the worker is active when it should run automatically.
- Review the output mode so the worker writes results in the expected place.
- Read the instructions as if you were the worker and remove ambiguous goals.
- Confirm context sources include the records the worker needs.
- Confirm allowed tools match the actions the worker is expected to take.
If a worker came from a template, compare the template goal with your current workflow. Templates are starting points, not a guarantee that every workspace has the same fields, permissions, or integrations.
Actions
From the detail page you can:
- Go back to the AI Workers list.
- Edit the worker.
- Archive the worker.
You can also use run history to open recent results and compare successful runs against failed ones. This is often faster than changing instructions blindly.
Read Recent Runs First
Before editing, open the latest successful and failed runs. Confirm the worker received the expected context, used the expected tools, and wrote output in the expected location. This shows whether the fix belongs in instructions, context, tools, or the trigger record.
Archive a Worker
Archive a worker when it should no longer be used. Archiving returns you to the AI Workers list.
Archive instead of editing when a worker's job is no longer valid, such as a completed migration helper, an obsolete follow-up process, or a template test worker. Edit when the worker is still useful but needs better instructions, context, or tool access.
If a worker is risky but still needed, make it inactive while you revise and test it.
Review Before Reactivating
Before turning a paused or edited worker back on:
- Read the current instructions.
- Review context sources and tool categories.
- Open the latest failed and successful runs.
- Run one safe test.
- Confirm output is useful and scoped.
- Confirm no duplicate records were created.
Troubleshoot From Detail
When a worker gives the wrong result:
- Check whether the latest run used the records you expected.
- Confirm the needed context source was enabled before the run started.
- Confirm the worker had permission to use the required tool category.
- Tighten instructions with explicit success criteria and boundaries.
- Run a smaller test before turning the worker back on for broad automation.
Ownership And Pause Rules
Every active worker should have a human owner who knows when it should run, what records it may affect, and how to review failed runs. If that owner changes, pause the worker until the new owner reviews instructions, context, and tool access.
Pause or archive a worker when its output could affect customers, finance, tasks, or CRM records and you are not sure the current configuration is still valid.