On August 20, 2026, Anthropic made Computer Use, Skills API, and Files API generally available on Claude Platform and introduced Browser Use. Together, these tools close much of the gap between an AI that can answer a question and an agent that can complete and deliver a real task.
Read the release as a list of features and it sounds incremental: Claude can operate an interface, load reusable instructions, and manage files. Put those capabilities in one workflow, however, and you get something more important—a system that can understand a goal, apply a documented method, act in an external environment, and return a usable deliverable.
This guide uses a competitive-research agent to show how the pieces fit together, what to implement first, where human approval belongs, and where a third-party model access service such as Apito fits without being confused with Anthropic’s own platform features.

Four capabilities, four different jobs
| Capability | Role in the workflow | Best used for | Should not replace |
|---|---|---|---|
| Computer Use | The agent’s visual hands and eyes | Screenshots, clicks, typing, scrolling, and desktop interfaces | Authorization, durable business state, or audit controls |
| Browser Use | A web-application action layer | Locating fields and buttons, navigating structured pages, and completing browser workflows | Site access rules, authentication policy, or anti-abuse controls |
| Skills API | Reusable operating procedures | Instructions, scripts, templates, brand rules, and validation checklists | A business file store or operational database |
| Files API | Input reuse and deliverable management | Uploading source material, referencing it by file_id, and retrieving generated files |
A complete enterprise data-governance system |
The simplest mental model is:
- Computer Use and Browser Use perform actions.
- Skills API defines how the work should be done.
- Files API supplies reusable inputs and carries the output.
- The Claude model interprets the goal, selects the next step, and assembles the result.
Anthropic says the updated Computer Use tool and the new Browser Use tool can plan multiple actions in one model turn. That should reduce round trips for sequences such as opening a page, choosing a filter, and moving to the next screen. It does not guarantee that every automation will cost less: page complexity, screenshots, retries, and output length still matter.
Why this looks more like a production agent
Many early agent projects fail in the same place. The model writes an excellent plan, but execution depends on an undocumented company process. It opens a page but cannot reliably preserve evidence. It produces a wall of chat text rather than the document the business actually needs. A person then spends another hour turning the answer into a deliverable.
The new stack addresses those missing layers:
- A Skill turns tacit operating knowledge into a versioned asset.
- Computer Use or Browser Use turns the plan into external actions.
- Files API keeps large inputs out of repeated prompts and carries generated artifacts.
- Approval policy prevents useful automation from becoming uncontrolled automation.

Apito appears in this architecture only as a third-party model access layer for credentials, endpoint configuration, model selection, request records, and cost visibility. It is not an Anthropic service, and it does not automatically provide Skills API, Files API, Computer Use, or Browser Use. Tool availability must be tested against the selected model, route, and current gateway implementation.
Build a competitive-research agent that delivers a report
Set a concrete requirement before writing code:
A user provides a product brief and a competitor list. The agent follows a documented research method, visits public sources, captures evidence, creates a structured report, and pauses before any login, submission, message, deletion, or purchase.
The workflow has six stages.

Step 1: Write a Skill before writing a giant prompt
A maintainable Skill should define its scope, execution sequence, evidence standard, output format, and failure policy. One useful directory layout is:
market-research-skill/
├── SKILL.md
├── references/
│ ├── source-quality.md
│ └── competitor-fields.md
├── templates/
│ └── report-template.md
└── scripts/
└── normalize_links.py
market-research-skill/
├── SKILL.md
├── references/
│ ├── source-quality.md
│ └── competitor-fields.md
├── templates/
│ └── report-template.md
└── scripts/
└── normalize_links.py
The SKILL.md file should contain operational instructions rather than slogans:
---
name: market-research
description: Research public product information and produce a cited comparison report.
---
# Market research workflow
1. Read the product brief and competitor list.
2. Prefer official product pages, documentation, pricing pages, and release notes.
3. Record the URL and access date for every material claim.
4. Separate verified facts from inference.
5. Never log in, submit, send, delete, or purchase without approval.
6. Produce the final report with templates/report-template.md.
---
name: market-research
description: Research public product information and produce a cited comparison report.
---
# Market research workflow
1. Read the product brief and competitor list.
2. Prefer official product pages, documentation, pricing pages, and release notes.
3. Record the URL and access date for every material claim.
4. Separate verified facts from inference.
5. Never log in, submit, send, delete, or purchase without approval.
6. Produce the final report with templates/report-template.md.
The point of Skills API is not to make prompts longer. It is to move task-specific methods, scripts, and templates into a reusable and independently versioned package. If the reporting format changes, the team updates the Skill instead of copying a new multi-page system prompt into every workflow.
Anthropic’s documentation describes a custom Skill as a folder containing SKILL.md and supporting files. In production, pin a specific Skill version. Referencing latest everywhere makes every job vulnerable to an accidental template or policy change.
Step 2: Upload once and reuse file IDs
Product decks, historical reports, CSV files, and templates can be large. Uploading them on every request wastes time and makes lineage harder to follow.
A practical Files API lifecycle is:
- Upload the source.
- Store its
file_id, purpose, version, owner, and expiration in your job database. - Reference the ID in subsequent model calls.
- Retrieve generated output files after the job completes.
- Delete them or let them expire according to the data-retention policy.
The following Python is intentionally an architecture sketch, not a promise of exact SDK names in every release:
from dataclasses import dataclass
@dataclass
class ResearchJob:
source_file_ids: list[str]
skill_id: str
skill_version: str
allowed_domains: list[str]
approval_actions: set[str]
job = ResearchJob(
source_file_ids=["file_product_brief", "file_competitor_list"],
skill_id="skill_market_research",
skill_version="3",
allowed_domains=["example.com", "docs.example.com"],
approval_actions={"login", "submit", "send", "delete", "purchase"},
)
result = run_agent(
model="your-supported-claude-model",
files=job.source_file_ids,
skills=[{"id": job.skill_id, "version": job.skill_version}],
tools=["browser_use", "computer_use"],
policy={
"allowed_domains": job.allowed_domains,
"approval_required": sorted(job.approval_actions),
"max_steps": 40,
},
)
save_audit_log(result.events)
download_generated_files(result.output_file_ids)
from dataclasses import dataclass
@dataclass
class ResearchJob:
source_file_ids: list[str]
skill_id: str
skill_version: str
allowed_domains: list[str]
approval_actions: set[str]
job = ResearchJob(
source_file_ids=["file_product_brief", "file_competitor_list"],
skill_id="skill_market_research",
skill_version="3",
allowed_domains=["example.com", "docs.example.com"],
approval_actions={"login", "submit", "send", "delete", "purchase"},
)
result = run_agent(
model="your-supported-claude-model",
files=job.source_file_ids,
skills=[{"id": job.skill_id, "version": job.skill_version}],
tools=["browser_use", "computer_use"],
policy={
"allowed_domains": job.allowed_domains,
"approval_required": sorted(job.approval_actions),
"max_steps": 40,
},
)
save_audit_log(result.events)
download_generated_files(result.output_file_ids)
Use the current Anthropic documentation and SDK when implementing the real call. The August 20 announcement says Files API is generally available, adds automatic expiration, raises organization storage to 1 TB, and increases rate limits. Some older documentation or SDK examples may still show beta namespaces, beta headers, or earlier quotas during the transition.
Step 3: Prefer Browser Use for web apps, with Computer Use as a fallback
For a web application, Browser Use should usually come before visual desktop automation because it can target page structure, fields, and buttons. Use Computer Use when the target is a desktop application, a remote visual environment, or a page that does not expose reliable structure.
A sensible tool-selection order is:
- Use a documented API when one exists.
- Use Browser Use for a structured web workflow without a suitable API.
- Use Computer Use for visual-only or desktop workflows.
- Stop for human approval before an irreversible action.
The distinction matters. A model that can click a button does not make mouse automation the best integration. Interfaces change, pop-ups appear, sessions expire, and coordinates shift. Direct APIs remain easier to validate and retry when they are available.
Step 4: Store evidence separately from conclusions
Research agents often fail by mixing observed facts, model inference, and recommendations into one paragraph. Preserve an evidence record for every important claim:
| Field | Example |
|---|---|
claim |
The product offers monthly billing |
evidence_url |
The official pricing page |
captured_at |
2026-08-21T10:30:00+08:00 |
evidence_text |
A short summary directly supporting the claim |
source_type |
Official, media, or community |
confidence |
High, medium, or low |
inference |
Whether the claim is inferred |
Only validated evidence should enter the main report. Put unresolved items in a “needs verification” section. This makes the report auditable even after a source page changes.
Step 5: Deliver a file, not another chat transcript
Use Markdown or JSON as an intermediate representation, then apply a template from the Skill to create a DOCX, PDF, spreadsheet, or presentation. The final artifact can be retrieved through Files API.
Two design choices make this more reliable:
- Separate the fact model from the presentation template, so a visual change does not trigger another research run.
- Validate the artifact automatically: required sections, source count, empty tables, stale dates, and whether the generated file can be opened.
Step 6: Stop before irreversible actions
Capability is not permission. Reading public sources and drafting a report are not equivalent to submitting a form, sending a message, deleting a file, or making a payment.

| Risk tier | Typical actions | Default policy |
|---|---|---|
| Low | Read, search, and draft | Run automatically with full logging |
| Medium | Open external links, fill forms, and edit files | Restrict domains and directories; preview the plan |
| High | Send, publish, delete, pay, or change permissions | Require explicit approval and show an exact diff |
An approval screen needs more than an “Allow” button. Show the action, target, exact payload, reversibility, and recovery plan. Approval should move earlier as an action becomes harder to undo.
Eight guardrails to add before production
1. Least privilege
A research task does not need payment access. A report generator does not need permission to delete an entire drive. Use task-scoped credentials and short-lived access.
2. Domain allowlists
Limit Browser Use to approved domains. Treat redirects, short links, and download hosts as separate destinations that need validation.
3. Step and time budgets
Set maximum steps, runtime, screenshots, and retries. This prevents an agent from looping on a broken page or permission dialog.
4. Idempotency
Attach a unique job ID to write, create, submit, and send operations. A retry must not create a second order or send a duplicate message.
5. Complete audit logs
Record model version, Skill version, file IDs, tool calls, key screenshots, approvals, and final status. The final answer alone is not an audit trail.
6. Sensitive-data controls
Classify and redact files before upload. API keys, cookies, identity numbers, and customer lists should not leak into prompts, screenshots, or general-purpose logs.
7. Recovery checkpoints
Persist checkpoints at safe stage boundaries. If a browser action fails, resume from the last verified state instead of rerunning the entire job.
8. Deliverable acceptance tests
Define machine-checkable requirements: mandatory sections, citations, valid file formats, numerical consistency, and a human sampling rule.
Will this stack reduce cost?
It creates several plausible savings:
- Multi-action turns reduce model round trips for interface work.
- Task-specific Skills avoid carrying every instruction in every context.
- File IDs reduce repeated upload and processing.
- Standard templates reduce manual formatting and rework.
Anthropic’s announcement cites a customer whose longest claims workflow fell from 32 minutes to 13 minutes, with roughly 30% lower cost per task and 100% completion without prompt changes. Those numbers belong to a specific customer workflow and should not be presented as a universal benchmark.
Measure the cost of a successful deliverable instead:
Cost per accepted task = model input + model output + tool execution
+ file processing + retries + human review
Cost per accepted task = model input + model output + tool execution
+ file processing + retries + human review
A cheap API call that produces an unusable report is more expensive than a slightly larger call that passes acceptance on the first attempt.
Where Apito fits
Apito can serve as a third-party model access and cost-management layer, centralizing Base URL configuration, API credentials, model selection, request records, and usage visibility for compatible clients.
Its boundary must remain explicit:
- Apito is not an Anthropic service.
- It does not replace Skills API, Files API, or an execution sandbox.
- Computer Use and Browser Use availability depends on the selected model, upstream route, and current interface support.
- Organizations must still evaluate data handling, retention, authorization, and compliance requirements.
Keep the model access layer replaceable. Workflow orchestration, Skills, file governance, and approval rules should not be hard-coded to one gateway.
Migration checklist for beta users
- Inventory beta headers, older endpoints, and SDK namespaces.
- Verify actual tool availability in the current console and selected route.
- Pin Skill versions and retain a rollback version.
- Confirm automatic file expiration, storage quotas, and deletion policy.
- Re-test multi-action turns on live pages rather than old recordings.
- Inspect screenshots, files, and tool logs for sensitive data.
- Require approval for sending, publishing, deleting, payment, and permission changes.
- Track success rate, average steps, retries, human takeovers, and cost per accepted task.
FAQ
Should I use Computer Use or Browser Use?
Prefer Browser Use for structured web applications. Use Computer Use for desktop or visual-only environments. If the target system offers a reliable API, the API is usually the better first choice.
How is a Skill different from a system prompt?
A system prompt is appropriate for global behavior. A Skill is better for task-specific instructions, scripts, templates, and references that should be loaded only when needed and versioned independently.
Can Skills API replace Files API?
No. A Skill packages a method and its supporting resources. Files API manages business inputs, generated outputs, and their lifecycle.
Are Files API uploads permanent?
Do not assume they are. Anthropic’s latest announcement mentions automatic expiration, while older documentation may still reflect the previous lifecycle. Check the current console and documentation, and store expiration metadata in your application.
Can an agent log in, submit, and publish automatically?
It may be technically capable of doing so, but those actions should not be authorized by default. Put login, submission, sending, deletion, payment, and permission changes behind explicit human review.
Does using Apito unlock every official Claude tool?
Not automatically. Apito is a third-party access layer. Tool support depends on the selected model, upstream route, and current API implementation, so validate each capability with a minimal test.
What workflow should a team automate first?
Start with a frequent, low-risk task that has a verifiable output: public-source research, document classification, daily summaries, or a report draft. Do not begin with payment, destructive data changes, or unsupervised customer communication.
References
- Anthropic: Computer Use, Skills API, and Files API are generally available
- Anthropic Files API documentation
- Anthropic Agent Skills documentation
- Anthropic guide to using Skills API
If you are moving a Claude application from answering questions to delivering work, you can first validate model access, request records, and cost through Apito, then add Skills, tools, file governance, and approval one layer at a time. Confirm current official-tool support on the selected route before production deployment.



