Do not deploy a digital coworker if you cannot review its work.
That sounds obvious. Yet many businesses are moving quickly from chat to execution without building the management layer in between.
A chatbot drafts an answer. An agent can read a customer record, call a tool, update a system, trigger a workflow or recommend an action. The more useful it becomes, the more its work needs to be visible, bounded and reviewable.
IBM’s latest watsonx Orchestrate update is a useful signal. IBM says its platform can discover and import agents built on Amazon Bedrock, manage them from a shared control plane, apply gateway-level policies, inspect the full path of a run, evaluate performance against business-defined criteria and use an AgentOps agent to improve performance from that evidence.[1]
This is not important because every SME needs IBM software. It is important because the product direction reveals the operating problem.
The hard part is no longer creating another agent. The hard part is managing a workforce of agents that may sit across different vendors, systems and departments.
An inventory helps, but it is not governance. Knowing that an agent exists does not tell you whether it completed the right job, used the right data, called the right tool or stopped when it should have.
For an SME, the practical response does not need to be a large governance programme. Start with a control card for every digital coworker.
The card has five parts: owner, job, permissions, evidence and escalation.
1. Owner: who is accountable for the outcome?
Every digital coworker needs a named human owner.
Not the software vendor. Not “IT”. Not a committee. One person who is accountable for the workflow outcome and responsible for reviewing exceptions and approving material changes.
The owner does not need to operate every step. That would defeat the point. The owner sets the standard and checks whether the system continues to meet it.
Record four things:
- Name and role of the accountable owner
- Business result they are responsible for
- Review frequency
- Who can approve changes to the agent’s instructions, tools and access
If nobody owns the outcome, the agent will become an orphaned automation. It may keep running long after the workflow, policy or data has changed.
2. Job: what exactly has this coworker been hired to do?
“Help the sales team” is not a job description.
A useful job definition names the trigger, the work, the expected output and the measure of success.
For example:
When a sales opportunity reaches the proposal stage, gather the approved customer, product and pricing context from CRM and ERP, flag missing information, and prepare a quotation draft for human review.
That is bounded. It does not ask the agent to “grow revenue”. It gives the agent a clear starting condition and a clear stopping point.
Write down:
- What starts the workflow?
- Which steps should the agent complete?
- What output should it produce?
- What business measure should improve?
- What is explicitly outside the job?
The last question matters. A good job description defines non-work as clearly as work.
3. Permissions: what may it see and do?
Digital coworkers need least-privilege access, just like human employees.
Separate permissions into three levels:
- Read: data the agent may retrieve
- Draft: records or transactions it may prepare but not commit
- Act: changes it may execute without additional approval
In the quotation example, the agent may read the customer’s CRM record and approved ERP price list. It may draft a quotation. It should not change the master price, apply an unapproved discount, create credit terms or send the quotation to the customer without a person approving it.
Consequential actions need an explicit human gate. That includes payments, contracts, customer messages, production changes, sensitive-data access and decisions that affect someone’s rights or eligibility.
Do not grant broad access because it is easier during setup. Convenience at deployment becomes exposure during failure.
4. Evidence: how will you review what happened?
An agent saying “done” is not evidence.
Reviewable work needs a record of the important steps. Depending on the workflow, that may include:
- The request or event that started the run
- Data sources consulted
- Tools called and parameters used
- Decisions or evaluations made
- The generated output
- Approvals received
- Exceptions, retries and failures
- The final system state
IBM’s emphasis on execution traces and business-defined evaluation is useful here.[1] A trace helps reconstruct what the agent did. An evaluation helps judge that work against the standard your business cares about.
But an automated score is not objective truth. The business still has to define “good”. A customer-service team may care about correct policy use and clean escalation. Finance may care about reconciliation accuracy and approval evidence. Sales may care about current pricing and CRM completeness.
The evidence should answer one question: Can the owner prove why this result happened?
If not, the workflow is not ready for more autonomy.
5. Escalation: when must the coworker stop and ask?
A reliable digital coworker needs a safe way to fail.
Define escalation before launch, not after an incident.
Specify:
- Conditions that force escalation
- The person or role receiving it
- The context that must be included
- How quickly someone should respond
- What the system does while waiting
In the quotation workflow, escalation could be triggered by missing tax data, expired pricing, an unsupported product combination, a requested discount above policy or conflicting customer records.
The safe fallback may be to save a draft, mark the exception and stop. It should not guess its way into a customer commitment.
Low confidence is not the only trigger. A tool failure, policy conflict, unexpected data or irreversible action can all require a human decision.
Orchestrate the work instead of operating every step
The purpose of this control card is not to slow automation down. It is to make delegation possible.
Without a clear owner, job and boundary, leaders end up checking everything manually. They are still operating the workflow, only now through an unpredictable interface.
With the right controls, the agent can complete the repetitive work while people retain the parts that require judgment, relationships, approval and accountability.
That is the shift: orchestrate, do not merely operate.
You decide what outcome matters. The digital coworker executes within a defined role. Evidence shows what happened. A person handles the exceptions and approves consequential actions. The workflow improves from real results rather than confident-looking output.
Start with one workflow
Do not begin with an enterprise-wide agent strategy deck. Pick one bounded workflow.
Before expanding its autonomy, complete this checklist:
- [ ] One accountable human owner is named
- [ ] The trigger, steps, output and success measure are clear
- [ ] Read, draft and act permissions are separated
- [ ] Consequential actions require human approval
- [ ] Each run produces reviewable evidence
- [ ] Escalation conditions and a safe fallback are defined
- [ ] The owner has reviewed real run evidence, not only a demo
Then run it with limited scope. Review the evidence. Correct the instructions, data and permissions. Expand only when the results justify it.
Building a digital workforce should not mean giving software vague goals and hoping for the best.
Hire each digital coworker for a specific job. Give it the minimum access required. Make its work reviewable. Keep a human accountable.
If you cannot do that, it is not ready to work for your business.
Sources
[1] https://www.ibm.com/new/announcements/new-in-ibm-watsonx-orchestrate-cross-platform-agent-discovery-custom-evaluation-and-agentops-agent-goes-ga — New in IBM watsonx Orchestrate: Cross-platform agent discovery, custom evaluation and AgentOps Agent goes GA