The next generation of workplace AI will not wait inside a chat window.
Microsoft’s new Autopilot is presented as a persistent agent that can monitor channels, follow up on work, run recurring tasks, and resume a project days later. Microsoft says it has its own identity, memory, computer, and workspace inside the customer’s tenant, with permissions, audit, and governance around it.[7]
That is a meaningful shift.
A chatbot answers a request. A persistent agent carries responsibility between requests.
Once an agent can keep working after you close the conversation, the important question is no longer, “What personality should we give it?” The question is, “What job is it allowed to do?”
Before an agent gets ongoing access to your ERP, CRM, email, documents, or supplier workflows, give it a one-page job description.
Not a persona. Not a clever system prompt. A job description.
Treat the agent as operational capacity
A persistent agent can be useful because it does not need to be prompted for every step. That is also what makes vague instructions dangerous.
“Help the sales team” is not a job.
“Review new inbound opportunities every weekday, check whether required fields are complete, enrich only from approved sources, prepare a follow-up recommendation, and escalate any pricing or contractual decision to the account owner” is much closer to one.
The difference is operational clarity.
When a human employee joins a company, we do not define the role only by listing the applications they may open. We define what they own, what decisions they may make, how their work is checked, and when they must ask for help.
Digital coworkers need the same discipline.
The one-page digital-coworker job description
Keep the first version simple. It needs eight fields.
1. Owner
Name one human who is accountable for the agent’s work.
The owner does not need to inspect every routine action. But someone must decide whether the agent is performing the right job, whether its access remains appropriate, and whether it should continue after an exception.
If everyone owns the agent, nobody owns the outcome.
2. Business outcome
State the result the agent is expected to produce.
Do not describe activity. Describe completion.
Weak: “Monitor overdue invoices.”
Better: “Prepare a verified daily queue of overdue invoices, recommended next actions, and exceptions requiring finance review.”
The outcome should be observable and testable.
3. Allowed systems
List the systems and data the agent may access.
For example:
- read customer records in the CRM;
- read invoice status in the ERP;
- create an internal follow-up task;
- draft an email, but not send it;
- never export the full customer database.
This is the access boundary.
4. Decision rights
Permissions and decision rights are not the same thing.
Permission answers: What can the agent technically access or execute?
Decision rights answer: What may the agent decide without a human?
An agent may have permission to update a CRM record but only have the decision right to fill missing administrative fields. It may not change deal value, discount, forecast category, or customer status without approval.
That distinction prevents technical access from quietly becoming business authority.
5. Required evidence
Define what the agent must return with every completed case.
A useful evidence packet might include:
- the outcome;
- the records checked;
- the rule applied;
- the action taken;
- any uncertainty or exception;
- the next human decision, if one is needed.
Do not make managers read a full transcript to understand what happened. The agent should return a decision packet, not a conversation dump.
6. Stop conditions
Write down when the agent must not continue.
Examples include missing source data, conflicting customer records, an amount above a defined threshold, a request involving legal terms, a failed system write, or any action that cannot be reversed safely.
A stop condition is not a failure. It is part of the job design.
7. Escalation path
Specify who receives the exception, what context they receive, and what happens if they do not respond.
“Ask a human” is incomplete.
“Create a finance-review task with the invoice, customer history, discrepancy, attempted checks, and recommended next action; do not contact the customer until approved” is actionable.
8. Review cadence
Decide when the role will be reviewed.
Start with a short cycle. Review the agent’s first cases, exceptions, false positives, and missed conditions. Then adjust the job description before widening access or autonomy.
Persistent work needs persistent management.
An SME example: the overdue-invoice agent
Consider an SME using an ERP and CRM.
The agent’s job is to prepare the daily overdue-invoice queue. It may read invoice status from the ERP, check account ownership and recent conversations in the CRM, and create an internal task for the account manager.
It may classify a case as “routine reminder ready” when the invoice is overdue, the amount matches, no dispute is recorded, and the customer has no active service issue.
It may draft the reminder.
It must stop if the ERP and CRM disagree, if a dispute is open, if the customer is strategically sensitive, or if the proposed action changes payment terms. Those cases go to finance or the account owner with an evidence packet.
The agent can access the records. It cannot decide every commercial consequence.
That is the point of the job description: it separates useful execution from accountable judgment.
Product controls are not the operating model
Microsoft’s announcement puts identity, permissions, audit, and governance around Autopilot.[7] Those are necessary capabilities. They do not, by themselves, define the job.
VentureBeat’s coverage highlights the gap: the launch material does not fully spell out action-by-action approval policy or how every category of failed execution should be handled.[10]
That is not a reason to reject persistent agents. It is a reason for operators to do their part.
A platform can provide access controls and logs. The business still has to define authority, evidence, exceptions, and accountability.
Write the job before granting the access
The practical sequence is simple:
- Choose one recurring, bounded workflow.
- Write the one-page job description.
- Test it on historical or low-risk cases.
- Review the evidence and exceptions.
- Expand access only when the role is working as designed.
Do not start by naming the agent, designing its personality, or connecting every system.
Start with the work.
If you cannot explain the agent’s owner, outcome, decision rights, evidence, stop conditions, escalation path, and review cadence on one page, it is not ready for persistent access.
Write the job description first. Then test whether the digital coworker can earn the job.
Sources
[7] https://blogs.microsoft.com/blog/2026/09/25/introducing-the-new-copilot-with-home-code-and-autopilot — Introducing the new Copilot with Home, Code and Autopilot [10] https://venturebeat.com/technology/microsoft-revamps-its-copilot-ai-with-a-persistent-autopilot-agent-and-hosting-for-ai-generated-apps — Microsoft revamps Copilot with persistent Autopilot agent