Most of a 6-week Claude Cowork rollout has nothing to do with Cowork.
Rolling Claude Cowork out to a department is access work, not product training. Anthropic scopes it by plan: Enterprise can target groups with custom roles, Team is organisation-wide with no narrower setting. Pexon runs the entitlement, folder and connector decisions that follow. We have delivered no Cowork rollout.
The starting point
The department is ready before the access model is.
It usually starts the same way. A department that has never filed a ticket in its life — legal, finance, HR, bid management — sees Cowork work through a folder of documents end to end and asks for it by name. IT says yes, because there is nothing to install and the licence is already paid for. Then the first real question arrives: who does the entitlement actually reach? On Enterprise that is a group with a custom role; on Team, where Anthropic documents the Cowork toggle as organization-wide, it is everybody in the organisation and there is no narrower answer available. And what you find either way is that access in that department lives in a spreadsheet, the shared drive has fourteen years of history in it, and nobody has ever had to say out loud which systems an automated agent may write to. None of that is a Cowork problem. All of it has to be solved before Cowork is switched on, because afterwards the department is already working in the tool and every boundary you draw is a takeaway.
What we build
Six weeks, in this order
01
The entitlement, and whether your plan lets you scope it
The first thing to establish is which plan you are on, because the entitlement model is not the same one. Anthropic documents that the Cowork toggle is organization-wide — either all members have access or none do — and that groups and custom roles, the only way to enable Cowork for specific teams, exist on Enterprise plans only. On Team plans there is therefore no group to scope it to: Cowork is all-or-nothing, and the real week-1 question is which people are in the organisation at all. On Enterprise we build the group that will carry it, manually or synced by SCIM from your identity provider, name the person in IT who owns its membership, and make that group mean something before anything is assigned to it. 'Run Cowork in the cloud' follows the same split — org-wide and on by default on Team, off by default on Enterprise where an owner enables it and then grants the capability to a group with a custom role. Departments that manage access as a list of names discover here that the first Cowork decision is an identity project.
Week 1
02
The folder list, written as paths
Anthropic documents that local file access is limited to the folders a member has connected on the desktop, and that each local tool call is checked against that member's permissions before it runs. That control is exactly as tight as the folder list and no tighter, so we produce one: named paths, per role, with an owner against each. A connected drive is not a connected folder. This is the week where a department discovers what is actually in its shared drive, which is uncomfortable and is the point.
Week 2
03
The write decision, per connector
Admins can restrict which actions each MCP connector exposes across the organisation — read allowed, write disabled — and a separate organisation setting decides whether members may skip per-task approval for write-capable connector tools at all. We take both decisions system by system with the owner of that system in the room, default to read, and record who signed each write permission off. Anthropic documents that disabling the always-allow setting also stops prior always-allow preferences being honoured, which makes it a real rollback rather than a forward-only switch.
Week 3
04
Telemetry, and its own data boundary
Cowork exports OpenTelemetry events only once an admin has configured an OTLP endpoint; no data flows by default. So we configure one — and then handle the part that catches HR and finance rollouts late: Anthropic documents that user prompt content is included in those events by default, along with tool parameters and user email addresses. In a department handling personal data that turns your collector into a personal-data store. We set retention and field-level handling to what your data protection officer and employee representatives actually agreed to, because monitoring nobody agreed to gets switched off in month two.
Week 4
05
The cohort, and the patterns they keep
One department, one cohort, tasks that already exist on somebody's Friday afternoon. We sit with them through the first real runs, because the failure mode in a non-developer department is not misuse — it is a person who hits an approval prompt they do not understand, clicks no, and never opens it again. The output is a written pattern library in their own vocabulary, a named internal owner who is not us, and a review of what the telemetry says they actually did versus what the business case assumed.
Weeks 5 and 6
What changes
What you have at the end of week six
- On Enterprise, the Cowork entitlement sits on an identity-provider group with a named owner rather than a list of people maintained by hand. On Team, where the Cowork toggle is organization-wide, you have instead a written decision about who belongs in the organisation at all — because that is the only lever the plan gives you.
- The folders Cowork can reach exist as written paths per role, so the boundary can be reviewed by someone who was not in the room when it was drawn.
- Every connector has an explicit read-or-write decision with the system owner's name against it, and write is the exception rather than the state you inherited.
- Tool-level activity lands in a collector your security team already reads, with prompt-content handling agreed rather than discovered.
- One department head owns a per-team budget in the admin console, which makes cost per team per month the number under discussion instead of cost per seat.
- The access model is reusable, so the second department inherits the entitlement pattern and the connector decisions instead of starting the argument again.
Before you buy this
Start with the first two weeks, and read this before you do.
Pexon has delivered no Cowork rollout. No engagement, no customer reference, no price list for one — and the 6 weeks above is our engagement design, not a benchmark measured on somebody's deployment. What we do run today is the identity, permission, connector and telemetry work underneath it, which is unchanged by Cowork and is where a rollout actually fails. So the entry point is the first two weeks as a standalone blueprint: the entitlement decision — a group with a custom role if you are on Enterprise, the organisation membership itself if you are on Team — the folder list and the connector inventory, delivered as documents you keep whether or not we run the remaining four.
Trade-off
If your identity groups are already clean, say so and we will tell you to skip us and read Anthropic's Cowork architecture overview and its Team and Enterprise admin article instead.
What buyers ask before a Cowork rollout
How long does a Claude Cowork rollout take in a department with no engineers?
Pexon plans 6 weeks, and the first two are identity and connector work that has nothing to do with Cowork: who the entitlement reaches — a group with a custom role on Enterprise, or the whole organisation on Team, where Anthropic documents the Cowork toggle as organization-wide — which exact folders get connected, and which connectors are allowed to write. Departments that skip straight to training spend those two weeks later anyway, with users already in the tool.
Do cloud sessions have to be enabled for Claude Cowork?
Not automatically, and the default differs by plan. Anthropic documents that the 'Run Cowork in the cloud' toggle is on by default on Team plans and off by default on Enterprise plans, where admins grant the capability through groups and custom roles. On Enterprise this is a decision somebody has to make deliberately, not a switch to remember to turn off.
How do we stop Claude Cowork writing into a business system before we are ready?
Two separate controls. Admins can restrict which actions each MCP connector exposes across the organisation, so read is allowed and write is disabled per connector. Separately, the organisation setting 'Allow Always allow for connector tools' decides whether members may skip per-task approval for write-capable connector tools; Anthropic documents that when it is disabled, prior always-allow preferences are not honoured.
Will we be able to see what Claude Cowork actually did?
Only if somebody configures it first. Anthropic documents that Cowork exports OpenTelemetry events only once an admin has configured an OTLP endpoint, and that no data flows by default. Session and active-user counts appear in the admin dashboard and Analytics API, but the tool-level record — which files were touched, which approvals were automatic — exists only where a collector is receiving it.
Is Claude Cowork monitoring itself a data protection question in HR or finance?
Yes, and it is the one rollouts discover late. Anthropic documents that user prompt content is included in exported events by default, alongside tool parameters and user email addresses. In a department handling personal data, switching on monitoring turns the observability collector into a personal-data store, which is an employee-representation conversation before it is a technical one.
Which folders should a department connect to Claude Cowork?
Named folders, never a whole drive. Anthropic documents that local file access is limited to the folders a member has connected on the desktop, and that each local tool call is checked against that member's permissions before it runs. The control is therefore only as tight as the folder list, and a department that connects a shared drive has drawn no boundary at all.
Who owns the Claude Cowork budget once the rollout ends?
One named department head. On Enterprise plans that head can hold a group spend limit in the admin console; on Team plans no per-group budget exists, so the ownership has to be a written agreement rather than a setting. Anthropic states that agentic tasks consume more capacity than regular chat, so headcount does not predict consumption and a seat-based business case is measuring the wrong variable. Cost per team per month is the unit a department head can actually own and defend.
Has Pexon delivered a Claude Cowork rollout?
No. We have no Cowork engagement, no customer reference and no price list for one, and we would rather write that here than imply otherwise in a proposal. What we do run today is the identity, permission, connector and telemetry work a Cowork rollout depends on, which is the same engineering as any other Claude deployment past the pilot team.
Next step
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.
