Who this is for. Super Admins maintaining an Agent Co-worker. See the Roles and Access.
An existing Agent Co-worker is changed through the same wizard that created it. The heading reads Edit AI agent co-worker rather than New AI agent co-worker, and every field arrives filled in with the instance’s current configuration.
Open an instance for editing
- Open Agent Co-workers from the left rail.
- Select the agent the instance belongs to, for example SmartVendor.
- In the Actions column of the instance row, select the pencil.
Figure 1. Editing an existing instance.
The wizard opens at step 1 with the instance’s system of record and mailbox already set. The URL carries the instance identifier, so an edit session is specific to one instance.
Editing walks the same six steps, and the same two are skipped. Next on Define capabilities goes straight to Activate. The work-scope, function and capability form settings are written when you select Run on the final step. The Email Categories, Processing Rules, Internal Contacts and System Senders panels are the exception. They save through their own buttons as soon as you use them, so changes there take effect even if you leave the wizard without selecting Run.
The Agent Co-workers page groups agents by autonomous process. Selecting an agent opens the Running Instances popup, not the wizard, and Show Description above the table expands the agent description.
Edit is per instance. An agent with more than one running instance has one Edit action per row, so read the ERP and mailbox on the row to be sure which instance you are about to change.
Navigate to the setting you need
Use the step indicator at the top of the page to move between Work scope, Choose functions, Define capabilities, Exception treatment, Try out coworker, and Activate.
Within Define capabilities, select the function tab, then select the capability section in the left rail.
Change the setting, then select Next to continue.
Selecting a section directly in the rail is faster than stepping through, which matters when changing one thing.
There is no pause while you edit
There is no control that pauses processing while you edit. The pencil opens the wizard against the running instance, which keeps processing.
Mailbox stays editable unless the instance is locked, in which case the selector shows the current mailbox but is disabled. The SOR selector is the only one disabled outright in edit mode.
What can and cannot change after creation
Table 1. Editability after creation
Setting |
Changeable |
Risk of changing |
|---|---|---|
System of record |
No |
An agent pointed at the wrong environment must be recreated, not corrected. |
Connected mailbox |
Yes, unless the instance is locked |
A locked instance keeps the mailbox it was created with. Agent Name and Agent Description Yes The name must stay unique in the tenant. A name already used, or reserved for another system of record and mailbox pairing, is rejected. |
Functions |
Yes |
Adding one leaves an unconfigured capability tab. |
Autonomy level |
Yes |
Widens what the agent may do on its own; it does not improve how well values are read. |
Enrollment |
Yes |
Forward-only. Does not reprocess existing mail. |
Capability settings |
Yes |
Varies by setting. See the higher-risk edits below. |
Changes that carry more risk than they look
Before saving any of these edits, read what happens downstream. Each one alters classification or configuration beyond the field you touched.
Table 2. Edits that carry more risk than they look
Change |
Why it matters |
|---|---|
Autonomy level |
Changes which capability sections exist, and reply content does not transfer between the two models. |
Removing an Internal Contact or a Relaxed Matching domain |
Senders who lose Internal classification fall back to whatever else matches them, or to Unknown. Replies to them narrow accordingly. |
Removing a System Sender, or replacing the list by CSV upload |
An upload replaces the entire configuration. Platforms omitted from the file revert to Unknown. |
Disabling an email category with a high usage count |
Traffic that was precisely classified falls back to a broader category, and rules bound to the disabled category stop matching. |
Changing sender classification |
Alters the authorization boundary, what the agent may reveal to whom. |
Change the autonomy level
Governed Autonomy exposes Email Categories, Processing Rules and Task SLA. Collaborative Mode exposes Intents & Outcomes, Agent Replies and Task Suppression instead. Autonomy Level, Contact Management, Vendor Categories, Processing & Automation, Assignee Hold and Email Archiving appear under both.
The two configuration experiences are separate: reply content lives in Agent Replies under Collaborative Mode and has no equivalent field under Governed Autonomy. For the full section-by-section comparison, see Collaborative Mode Overview.
Deselect a function
Removing a function at Choose functions removes its tab from Define capabilities, and the deletion is not confined to configuration. Deselecting AP Invoices puts a red banner on the Activate step:
On RUN, AP Invoices will be disabled and all documents in active data and written to SoR data will be lost
Nothing is lost until you select Run. To keep the data, go Back and re-enable the function, or leave the wizard without running.
Figure 2. The data-loss banner on the Activate step after deselecting AP Invoices.
When a change takes effect
Run saves the configuration onto the instance. It starts no reprocessing of mail or documents that have already arrived, and the agent reads the stored configuration each time it picks up a message, so a change applies to what the agent handles next. Vendor enrollment behaves the same way: enrolling a vendor affects their subsequent mail rather than what has already been processed.
Two things fall outside that. An item still in flight when you save finishes its remaining steps under the new configuration. And thresholds that are applied when a screen is drawn rather than when a message is handled, such as the Task SLA At-Risk and Overdue values, take effect on existing records at once: changing them re-bands tasks that were created earlier.
A single setting is rarely isolated, so re-run the parts of the pre-activation review your change touches. A rule change in particular reads differently against the whole enabled ruleset. For more information, see Review and Activate.
Configuration drift checks
An Agent Co-worker does not stay correctly configured on its own. Nothing in the product prompts you about any of the items below. They are caught by looking.
What drifts silently
Treat the Trigger to check column as your review prompt. When that event occurs, go and look, because the product will not prompt you.
Table 3. What to review, and when
Item |
Why it drifts |
Trigger to check |
|---|---|---|
Vendor enrollment |
New vendors are not enrolled automatically. |
Vendor onboarding |
Rules referencing disabled fields |
A rule referencing only disabled fields does not run. |
Any field extraction change |
Pause or remove an Agent Co-worker
An Agent Co-worker can be taken out of service in two ways, and they are not degrees of the same thing. Pausing replies leaves the instance in place and reversible. Removing it does not. There is no separate Stop control: the Agent Co-workers page speaks of stopping, but the row offers only Pause, Delete and Edit, and the delete confirmation is the dialog that describes itself as stopping the Agent Co-worker. Stopping and removing are the same act.
Open the instance controls
On the Agent Co-workers page, select the agent.
The Running Instances popup lists each instance with its agent name, ERP, mailbox, status and replies state.
The Actions column holds up to three controls, depending on your role: Pause, Delete and Edit. Pause and Edit need update rights on Agent Co-worker management; Delete needs delete rights.
Figure 3. The Running Instances popup, with Pause, Delete and Edit on each row.
Delete asks for confirmation before acting. The dialog reads:
You are about to stop the Agent Co-worker. All your prior configuration of this Agent Co-worker will be removed, all history of communication and actions done by the agents will be removed, and the automation will stop.
Continue deletes the instance; Cancel leaves it untouched. This is the only confirmation in the instance controls, and it is the one that matters: there is no undo.
Figure 4. The Delete confirmation. Continue removes the instance, its configuration and its history.
Table 4. Controls on an instance row
| Control | What it does | Reversible |
|---|---|---|
| Pause | Pauses the agent’s replies. The Replies column flips to Paused while Status stays Running, and there is no confirmation step: the pause takes effect as soon as you select it. | Yes |
| Delete | Removes the instance, its configuration, and its history of communication and actions. Shown in red. | No |
| Edit | Opens the Edit AI agent co-worker wizard against the running instance, which keeps processing while you work. | Not applicable |
While replies are enabled, Pause and Delete are both red circles, so read the tooltip before selecting either. Once replies are paused the first control turns green, because it now resumes them. Delete does not park an agent for later: it removes the instance and everything recorded against it. To take an agent out of service and keep the option of bringing it back, pause it.
What the list shows after each
A removed instance leaves the list entirely, so every row reads Running. A paused instance stays on the list, so the count of instances beneath the agent name still includes it.
Before you remove an instance
The mailbox is released. A mailbox bound to a running instance is not offered when a new instance is created, so removing an instance is what frees it.
The configuration goes with it. Nothing carries into a replacement instance, which has to be built through the wizard again.
Prefer pausing while you decide. Pausing is the reversible half of this pair.