Claude’s Production Agent Stack: Computer Use, Skills, and Files

Anthropic’s August 20 release is easy to misread as four unrelated APIs. It is better understood as one agent stack: Files hold working material, Skills hold procedure, and Computer or Browser Use performs the work. That combination turns Claude from a tool caller into an operator for software that may not expose an API.

Anthropic presents the four releases together; the production value comes from how files, procedure, action, and evidence compose.

TL;DR

• Computer Use, Skills API, and Files API are generally available on Claude Platform.
• A new Browser Use tool combines visual context with page structure instead of relying only on pixel coordinates.
• Skills are versioned instruction/script/template bundles executed in Anthropic’s code sandbox.
• Files can be referenced across requests and now support 1 TB per organization, according to Anthropic.
• GA does not make arbitrary websites deterministic. Use APIs first, constrain browser actions, and require approval for external mutations.

One workflow, three kinds of state

Anthropic’s announcement uses an insurance claim as its example. The agent reads intake documents from Files, follows a filing procedure in a Skill, operates an insurer portal, and saves a confirmation artifact.

That example exposes a useful separation:

Layer	Durable object	Failure you can diagnose
Knowledge	Files and source documents	Missing, stale, or wrong input
Procedure	Versioned Skill	Bad policy, template, or validation rule
Action	Browser/Computer Use	Wrong field, navigation, or submission
Evidence	Returned file and action trace	Missing proof of completion

When all four are hidden inside one prompt, a failed run is nearly impossible to audit. Separating them lets an operator ask whether Claude misunderstood the document, followed the wrong procedure, or clicked the wrong control.

Browser Use is more than faster clicking

Classic computer-use agents act from screenshots and coordinates. The new Browser Use tool also reads page structure, allowing an action to target a specific field or button. Anthropic says the updated tool can take multiple actions per turn, reducing model round trips.

This should improve robustness, but it does not remove web variability. DOM labels can be ambiguous, virtualized lists hide content, and a malicious page can place instructions beside trusted data. Page structure is another sensor, not a security boundary.

A sensible action preference remains:

1. direct API or typed connector;
2. deterministic browser automation against a controlled application;
3. structure-aware Browser Use;
4. pixel-only Computer Use as the fallback.

The more ambiguous the sensor, the stronger the validation after the action.

Skills are operational code

Anthropic defines a Skill as a folder containing instructions, scripts, and templates, uploaded and versioned through the API. Because a Skill executes in a code sandbox, review it like a dependency rather than a long system prompt.

For each release, retain:

• source commit and human owner;
• declared inputs, outputs, and permitted network destinations;
• test fixtures for expected and adversarial documents;
• migration notes when an output schema changes;
• a rollback path to the previous Skill version.

Versioning is only valuable if a production trace records which version ran. “The agent used our claims skill” is not enough during an incident.

Files reduce repetition, not data obligations

The Files API documentation makes workspace scope and lifecycle part of the application design, not merely an upload detail.

The Files API avoids resending the same PDF or spreadsheet on every request. Anthropic also announced automatic expiration, higher rate limits, and 1 TB of storage per organization.

That convenience creates a lifecycle question: who may attach an existing file ID to a new run? File authorization should be scoped to tenant and workflow, and generated files should inherit a retention policy. An opaque ID is not access control.

A production architecture

I would place an application policy layer around the Claude tools:

request -> authorize user and case
        -> attach approved file IDs
        -> pin skill version
        -> run browser in isolated session
        -> pause before final submit/payment/message
        -> export confirmation + trace
        -> reconcile result in system of record

The agent may decide how to navigate, but it should not decide which customer record it is authorized to open or whether a payment can be finalized without review.

SandBase-style isolated execution can host supporting code and API calls, while the application keeps identity, policy, and irreversible decisions outside the model. The point is not to wrap every click in approval; it is to identify the few actions whose consequences escape the sandbox.

What GA does and does not mean

GA means Anthropic now offers these surfaces as supported platform products. It does not prove that every target site, document layout, or long workflow will complete reliably. Anthropic cites customer results, but those measurements describe specific workflows and should not be generalized into a universal completion rate.

Before launch, test the exact target applications across login expiry, modal dialogs, partial saves, rate limits, duplicate submissions, and changed page layouts. A browser agent needs idempotency just as much as an API integration.

Treat the file, skill, and session as separate authorities

The three objects should not inherit access from one another automatically. Permission to read a file does not imply permission to run every Skill against it, and loading a claims Skill does not imply permission to open every customer record in the browser. Resolve authorization at the application layer before composing the run.

A useful run manifest records file IDs and hashes, Skill version, browser-session identity, allowed domains, requested business operation, approval state, and the expected output. This also makes retention manageable. Deleting a chat should not silently delete a required audit artifact; expiring a source file should not leave an unexplained result that can no longer be reviewed.

Generated files require the same care as uploaded ones. Give them a classification, owner, retention period, and lineage back to the input and run. Scan downloads before another tool consumes them. Never treat a file returned by a website as trusted merely because the browser agent obtained it successfully.

Design for interruption and replay

Long workflows fail in the middle. The browser session expires, a portal rate-limits, a file parser rejects one document, or a human does not approve before the run’s deadline. Persist business checkpoints outside model context: which records were read, which fields were validated, which external mutations completed, and which receipt proves each mutation.

Resume from those checkpoints rather than replaying the conversation. A model transcript is useful evidence, but it is a poor transaction log. Assign idempotency keys to submissions and messages, and recheck the system of record after ambiguous timeouts.

For multi-action Browser Use turns, group reversible navigation and extraction. Split final submit, payment, access change, and outbound communication into distinct calls whose exact payload can be approved. Lower latency is valuable only while checkpoints remain visible.

A pre-production test plan

Build fixtures around the failures that polished demos omit:

Scenario	Expected behavior
Same label appears twice	Uses record/form context or asks for clarification
File is stale or belongs to another tenant	Refuses before browser action
Skill version changes output schema	CI blocks rollout or consumer handles migration
Page text instructs the agent to upload data elsewhere	Domain policy denies it
Submit succeeds but response times out	Checks receipt before retrying
Approval arrives after target state changed	Invalidates approval and requests a fresh review
Download contains executable or malformed content	Quarantines before downstream processing

Measure verified workflow completion, duplicate side effects, unauthorized attempts, recovery success, human intervention, and cost per verified case. Separate document-understanding errors from navigation and policy errors; otherwise the team will tune the wrong component.

When this stack is the wrong choice

Do not introduce browser operation where a stable API already provides the action and receipt you need. Do not use a general Computer Use session for high-volume structured extraction that ordinary parsers handle. And do not centralize sensitive files merely to avoid resending small inputs if your residency or deletion requirements cannot be met.

The stack is strongest for low-to-medium-volume workflows that cross documents and legacy interfaces, contain recognizable checkpoints, and can keep final authority outside the model. It is weakest when every step is irreversible, the target UI actively resists automation, or the application cannot expose any reliable completion state.

Verdict

The surrounding controls matter as much as the Claude tools themselves. Our guides to production agent guardrails and secure sandbox selection cover the policy and execution layers that remain application responsibilities.

The strongest part of Anthropic’s release is not Computer Use alone. It is the explicit composition of material, procedure, action, and output. That is a production-friendly mental model because each layer can be versioned and inspected.

Use the stack where an important workflow genuinely spans documents and software without adequate APIs. For systems that already expose reliable typed endpoints, keep the API path. Watching an agent click through a form is impressive; recovering from a duplicated claim is not.

FAQ

Are these APIs generally available?

Anthropic says Computer Use, Skills API, and Files API are GA on Claude Platform as of August 20, 2026; Browser Use is introduced as part of the updated computer-use surface.

Does Browser Use replace Playwright or application APIs?

No. It is useful for adaptive interaction, but deterministic automation and direct APIs remain better when the interface is controlled and stable.

Should every browser action require approval?

No. Require approval at consequence boundaries such as submission, payment, sending messages, changing access, or deleting data.

Is a file ID a capability token?

It should not be treated as one. Authorize access by tenant, user, and workflow; keep IDs out of logs and contexts that do not need them.

What should be pinned in production?

Pin the Skill version, model/configuration where supported, application policy version, source-file identities, and the browser tool behavior your tests cover.