Skip to main content
This site is an independent third-party technical service provider. Claude™ and Anthropic® are trademarks of Anthropic, PBC. This site has no affiliation, endorsement, or partnership with Anthropic.

How to Build a Production Claude Agent Stack

A practical guide to combining Claude Computer Use, Browser Use, Skills API, and Files API into an agent that can research, act, create files, and stop for human approval.

Dev GuidesClaude AgentComputer UseBrowser UseSkills APIFiles APIEst. read14 minutes
2026.08.21 published
How to Build a Production Claude Agent Stack

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:

  1. A Skill turns tacit operating knowledge into a versioned asset.
  2. Computer Use or Browser Use turns the plan into external actions.
  3. Files API keeps large inputs out of repeated prompts and carries generated artifacts.
  4. 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:

  1. Upload the source.
  2. Store its file_id, purpose, version, owner, and expiration in your job database.
  3. Reference the ID in subsequent model calls.
  4. Retrieve generated output files after the job completes.
  5. 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:

  1. Use a documented API when one exists.
  2. Use Browser Use for a structured web workflow without a suitable API.
  3. Use Computer Use for visual-only or desktop workflows.
  4. 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

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.

Related Articles