Something changed in workspace software this year without a great deal of announcement. Assistants stopped living in a sidebar and started being given things that previously belonged to people: a name in the member list, membership of a channel, an assignment queue, a seat in a meeting, the ability to be tagged and to reply. That is a smaller technical step than it sounds and a much larger organisational one.
An agent in your workspace is not a tool your team uses. It is a participant your team has to manage — and nobody has been given the job
Every difficulty described below follows from that unassigned responsibility.
What is actually shipping
Strip out the marketing and the pattern is consistent across vendors. An agent can be added to a channel and will read what is posted there. It can be assigned a ticket, a request or a task and will produce a response or a draft. It can attend a meeting, produce notes and create follow-up items. And it can be invoked by name mid-conversation, which is the feature that changes team behaviour fastest. None of that requires new capability from the underlying models. What is new is placement — the agent now sits inside the workflow rather than beside it.
Three gaps that open immediately
Identity and audit. If the agent acts, whose action is it? Some deployments run under a shared service account, which destroys attribution; others impersonate the invoking user, which attributes everything to whoever typed. Neither is satisfactory. What you want is a distinct identity with its own audit trail, linked to a named human owner. Accountability for output. When an agent-drafted answer goes to a customer and is wrong, the organisation needs a settled answer about who is responsible. In practice the person who pressed send is accountable, and that only works if pressing send is a real decision rather than a reflex. Work routing. Teams quickly start routing the unpleasant items to the agent, which is fine, and then stop looking at them, which is not. The queue nobody reads is where your quality problem will start.
Write it a job description
The most useful hour you can spend on a workspace agent is writing down, on one page, what it is for. What work it handles. What it must never handle. Which systems it may read and which it may write. Who owns it. Who reviews its output and how often. What happens when it is wrong. And what the trigger would be to switch it off. This sounds bureaucratic and is the opposite. Agents deployed without it expand by accident — someone adds a tool, someone else adds a channel, and six weeks later it is doing work nobody scoped and everyone assumes somebody approved.
Run a probation
Borrow the sequence you would use for a new hire, because it works for the same reason. First it observes and produces nothing that leaves the team. Then it drafts and a person edits, with the edit rate recorded. Then it acts on the low-consequence subset with review after the fact. Then, if the numbers support it, it acts unsupervised on that subset only. Each promotion is a decision made against evidence, and each one is reversible. Most failures skip straight to the third stage because the demonstration was impressive.
Observe
Keep output inside the team while the scope is tested.
Draft
A person edits the work and records the edit rate.
Act with review
Allow only the low-consequence subset and review after the action.
Bounded unsupervised work
Promote only the evidenced subset; keep each grant reversible.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The etiquette problem nobody warns you about
Colleagues cannot tell what the agent has seen. A person who joins a channel is understood to have read the recent history; an agent may have read everything ever posted, or nothing before yesterday, and no one knows which. That uncertainty makes people either over-share or stop using the channel properly. Say it explicitly: which channels the agent is in, what it retains, and whether anyone can retrieve what it saw. Teams adapt quickly to a stated rule and badly to an unstated one.
Measure the queue, not the usage
Usage statistics are the vendor's metric. Yours is whether work left the system: items resolved without a person touching them, time from request to resolution, the proportion of drafts sent with no material edit, and the rate at which agent-handled items come back. If those numbers do not move within a quarter, you have an interesting pilot and not a change to the operating model.
Practical Guidance for Workspace AI Design Session
- Give each agent its own identity with an audit trail and a human owner.
- Write a one-page scope before granting the first integration.
- Run a probation from observe, to draft, to act with review.
- Record the edit rate on drafts as your promotion evidence.
- State which channels it reads and what it retains.
- Measure resolved work and rework, not usage.
- Review the queue nobody looks at on a schedule.
- Define the decommissioning trigger when you deploy it.
The Regional Angle
Be honest early about where the savings appear, because regional headcount does not behave the way agent business cases assume. Roles here are frequently tied to residency sponsorship, to manning schedules committed in client contracts, to project mobilisation plans and to entity-level licensing requirements, none of which respond to a productivity improvement in the current quarter. An agent that removes thirty per cent of a coordinator's workload does not remove thirty per cent of a coordinator, and a business case built on exits will fail its first review. Build it on avoided hiring instead: the requisition not raised as volume grows, the temporary cover not needed during leave, the additional entity supported without a new administrator. That case is defensible, it survives contact with human resources, and it does not require anybody to promise something the sponsorship framework will not deliver. The second is language, and it is decided by default unless someone decides it deliberately. Regional teams are routinely mixed — management correspondence in English, operational instruction in Arabic, site and warehouse communication in several other languages — and an agent placed in a shared channel will standardise on whatever it handles best, which is English. The effect is subtle and corrosive: the summary of record becomes English, the staff who work in another language stop correcting it, and the written history of the operation quietly stops representing what the operational team actually said. Decide what the language of record is for each channel, require the agent to produce its summary in that language, and check a sample of its output with the people who wrote the original messages. Translation quality is a governance question here, not a convenience feature. The third is about a role that regional organisations take more seriously than most. The executive assistant, the office manager, the coordinator who knows which approval is actually stuck and whose relationship will unblock it — that function is relational, informal and carries real institutional standing. Agents are being sold precisely into that space, and the parts they can genuinely take are the mechanical ones: scheduling, chasing documents, assembling packs, tracking renewals. The parts they cannot take are the judgement about who to approach and how. Scope the agent to the mechanical work explicitly, say so to the person whose role it touches, and let them keep the relational half rather than leaving them to guess whether they are being replaced. Getting that conversation wrong costs more institutional knowledge than the tool will ever save.
The objection worth taking seriously
The strongest objection is that the teammate framing is anthropomorphic nonsense sold by vendors who benefit from the confusion. These systems are software. Giving software a name and a profile picture encourages people to extend it trust it has not earned, to assume continuity of understanding it does not possess, and to describe its failures as mistakes rather than defects. Sensible organisations manage software with change control, access review and a support contract, and every hour spent writing a job description for a chat assistant is an hour not spent on the actual integration. That is right about the anthropomorphism and right that the language is being used to sell things. The framing nonetheless earns its place, for an unglamorous reason: the management questions are the ones being skipped, and the software questions are not. Every organisation deploying these systems has someone thinking about the integration, the model and the cost. Almost none has a named owner, a scope document, a review cadence or a switch-off condition, and those are exactly the artefacts the personnel framing produces naturally. Use whichever vocabulary your organisation will actually act on. If treating the agent as a system gets you an owner, an audit trail and a decommissioning plan, use that. The failure mode to avoid is the one in the middle — something that behaves like a colleague, is governed like a feature, and belongs to nobody.
Common Questions
Should agents have their own accounts?
Yes, where the platform supports it. Shared service accounts destroy attribution and impersonating users makes the audit trail actively misleading.
Do we need to tell customers when an agent handled their request?
Disclose when a customer could reasonably believe they are speaking to a person. Where an agent drafts and a named person sends, the person is answering and disclosure is unnecessary.
How do we stop scope expanding quietly?
Make adding a tool or a channel a decision with a named approver, and review the actual configuration monthly against the scope document. Expansion is always incremental and always defensible one step at a time.
What should we expect over the next twelve months?
Expect platforms to ship proper agent identity, per-agent permissions and audit trails, because enterprise buyers are about to insist. Expect the first significant embarrassment from an agent posting something in a channel it should never have been in. Expect job descriptions to start naming agent supervision as a duty. And expect the organisations that ran a probation to be the ones granting real autonomy next year, while everyone else is still arguing about whether the pilot worked.
Workspace AI Design Session — we scope what your agents may do, who owns them, and how you will know when to promote or switch one off.