Enterprise Monitoring and Team Deployment

Why Co-Work Monitoring Is Different

When you deploy a SaaS tool to your team, monitoring typically means looking at the vendor's admin dashboard: who logged in, what they exported, how many requests they made. Co-Work does not work this way.

Co-Work runs on each user's local machine inside a VM. There is no central server receiving your organization's Co-Work activity. If you want visibility into what your team's Co-Work instances are doing — what tasks are being delegated, which skills are running, where tokens are being consumed — you have to set up that visibility yourself using OpenTelemetry.

OpenTelemetry: What It Is

OpenTelemetry (OTel) is an open-source observability framework that standardizes how applications export telemetry data — traces, metrics, and logs — to monitoring platforms. Co-Work supports the OTLP (OpenTelemetry Protocol) for exporting event data from each user's Co-Work instance to a central observability platform.

This feature is available on Team and Enterprise plans only. It is not available on Pro or Max plans.

What it enables: complete visibility into every Co-Work action across all members of your organization. When a team member's scheduled task runs at 3am, you see it. When a connector call fails, you see it. When one user is consuming 10x more tokens than everyone else, you see it. Without OTel, this visibility simply does not exist.

The Five Event Types

Co-Work exports five specific event types via OTel. Understanding each one before building dashboards prevents you from designing queries around the wrong data:

Event Type	What It Captures	Primary Use
user_prompt	Every message sent to Co-Work, including task instructions and skill triggers. Contains token count per request.	Cost tracking, task volume analysis, identifying high-frequency delegation patterns
tool_result	Output from every tool call — connector reads, file operations, sub-agent results.	Workflow success/failure analysis, output quality monitoring
api_request	Every outbound API call Co-Work makes through connectors to external services.	Connector usage auditing, external service dependency mapping
api_error	Failed API calls — connector failures, timeout errors, authentication failures.	Debugging connector failures, identifying fragile integrations, alerting on error spikes
tool_decision	When Co-Work decides which tool to use for a given task — the model's tool selection reasoning.	Understanding how skills and connectors are being selected, diagnosing skill conflicts

Together, these five events give complete visibility into Co-Work's reasoning and actions. The combination of user_prompt (what was asked), tool_decision (what Co-Work decided to do), api_request (what it called), tool_result (what came back), and api_error (what failed) is a complete trace of every Co-Work session.

OTLP Configuration Setup

The setup requires four components: an observability platform, an OTLP endpoint, Co-Work admin settings configuration, and verification.

Step 1: Provision an OTLP Endpoint

Choose an observability platform that accepts OTLP data. Options that offer free tiers for initial setup:

• Grafana Cloud — free tier includes OTel ingestion; strong dashboard capabilities
• Honeycomb — free tier available; excellent for trace analysis
• Datadog — paid, but common in enterprise environments; native OTel support
• Self-hosted Jaeger or Prometheus — for organizations requiring on-premise monitoring

Each platform provides an OTLP endpoint URL after signup. It will look something like: https://otlp-gateway-prod-us-central-0.grafana.net/otlp

Step 2: Configure in Co-Work Admin Settings

From an admin account: Settings → Team → Monitoring → OpenTelemetry → enter the OTLP endpoint URL → Save.

Protocol options: Co-Work supports both HTTP and gRPC OTLP endpoints. If your observability platform offers both, prefer HTTP/JSON for simpler firewall configuration. Use gRPC if your platform recommends it for higher throughput.

Step 3: Verify Data Flow

After saving the endpoint, trigger test events: run one manual task, run one scheduled task, and deliberately trigger a connector error (attempting to access a disconnected connector). Within a short interval, all five event types should appear in your observability platform.

If events do not appear: check that the OTLP endpoint URL is correct, that the authentication token (if required by your platform) is included in the URL or as a header, and that your firewall allows outbound connections to the observability platform endpoint.

Building a Cost Dashboard

The most immediately useful dashboard for most teams is cost visibility. The user_prompt event contains token count data for each request. Aggregate this by user and by time period to identify your highest-cost delegation patterns.

A practical starting dashboard has three views:

1. Token consumption by user per day — identifies individuals with unusually high usage; may indicate a runaway scheduled task or an inefficient skill
2. Error rate by connector — api_error events grouped by connector; identifies unreliable integrations that need attention
3. Task volume by hour — user_prompt events over time; shows when scheduled tasks are running and helps identify unexpected off-hours activity

Jack Roberts uses a reframe for this data that is worth keeping: view token consumption as employee cost, not software cost. A dashboard showing token spend per team member is functionally showing you the cost of AI labor per person. The question to ask is not "is this too expensive?" but "is the value delivered proportional to the cost?"

Organization-Wide Plugin Distribution

Team and Enterprise administrators can distribute plugins to all workspace members from a single admin action. This is documented in official Co-Work plugin documentation and has zero community video coverage — it is an exclusively enterprise-admin capability.

The admin workflow:

1. From an admin account: Settings → Team → Plugins → Upload Plugin
2. Select the plugin file or package
3. Assign scope: all workspace members, or specific groups if your plan supports group management
4. Members receive the plugin in their Skills library automatically — no individual installation required

The organizational use case: your team has built a set of standard company workflows as plugins — client briefing automation, weekly report generation, support ticket triage. Rather than asking 50 employees to each install the same plugin, an admin distributes them centrally. Quality is consistent. Updates propagate automatically when the admin uploads a new version.

Network Egress Controls and Allowlisting

IT administrators can control which external endpoints Co-Work instances in the organization can reach. This is documented in official Anthropic monitoring and security documentation — no community video has covered it.

Three control levels:

Allow All (default) — Co-Work can reach any external service. Appropriate for most small teams and individual use. No configuration required.

Allowlist mode — Only pre-approved domains or IP ranges can be reached by Co-Work. Any connection attempt to a non-allowlisted endpoint is blocked. Appropriate for regulated industries, security-sensitive organizations, and any deployment where Co-Work should only interact with a defined set of services.

Connector-specific controls — Individual connectors can be enabled or disabled at the organization level. An admin can prevent all team members from connecting Co-Work to external email services, for example, while allowing file system and internal API connectors. Appropriate when some connector categories are in scope but others are not.

When to use allowlist mode: if your organization has strict data egress requirements, if you are in a regulated industry, or if you are deploying Co-Work in an environment where external internet access must be logged and controlled. Contact Anthropic enterprise support for guidance on configuring allowlist mode for your specific environment.