IntroductionClaude Cowork moving onto web and mobile is not just a new place to click a button. It is a sign that AI agents are shifting from short desktop conversations into longer-running task systems that can continue work across devices.For product, engineering, and operations teams, the important question is no longer only whether an agent can finish a task. The harder question is whether the agent can keep the right boundaries while it works: which files it may read, which tools it may use, what actions require approval, what evidence it must return, and how humans can review the result.This article explains the practical meaning of that shift. It focuses on agent harness design: the layer around the model that manages context, tools, permissions, state, logs, validation, and human control.## Source and Image NotesOriginal source page: Claude Cowork 登上移动端与网页端：团队该重新设计 Agent HarnessThe parsed source page exposed a default blog card SVG and site/footer images, but no body-level screenshots, workflow diagrams, code screenshots, or result images that were clearly required for the article body. To avoid inserting decorative or unrelated images, no image has been added to the body. If a future version of the source includes product screenshots or diagrams, they can be inserted near the corresponding sections.## Key Takeaways- Claude Cowork expanding across desktop, web, and mobile changes how teams should think about agent work.
- A cross-device agent is not only a chat UI. It is a task thread that can continue in the background.
- Teams need a clear agent harness: context boundaries, tool permissions, state tracking, logs, validation, and approval rules.
- Mobile access is useful for progress checks and lightweight confirmation, but it should not become a shortcut around code review, production approval, or sensitive-data controls.
- The broader market is moving in the same direction: agent products are becoming system engineering problems, not just model-selection problems.## What ChangedClaude Cowork now points toward a workflow where the same task can start on one device and continue on another. A user may assign work from a desktop, check progress from a phone, respond to a prompt while away from the desk, and later return to review the final output.That sounds convenient, but it also changes the control model. In a traditional chat window, the user usually stays close to the interaction. With a background agent, the agent may continue using context and tools while the user is no longer actively watching every step.This is why cross-device agent access should be treated as more than a product feature. It is a workflow design issue. The task needs to carry its own boundaries, evidence requirements, and approval rules, regardless of whether the user is on desktop, web, or mobile.## Why This Is an Agent Harness ProblemAn agent harness is the operating layer around the model. The model decides what to do next, but the harness determines what the model can see, which tools it can call, how state is stored, how actions are logged, how failures are handled, and when a human must approve the next step.A strong model inside a weak harness can still create serious problems. It may read the wrong files, use a tool outside the intended scope, produce work that is hard to review, or take action before the team has validated the output.When an agent works across devices, the harness matters even more. The task may begin on desktop, continue in a remote session, request confirmation on mobile, and then generate a document, code change, or message. The permission model should move with the task, not with the device.A good harness answers practical questions before the task begins:- What is the exact task goal?
- Which context is allowed?
- Which tools are available?
- Which actions are forbidden?
- What output is expected?
- What validation must run?
- What evidence must be included?
- What requires human approval?
- When should the agent stop?## The Risk of Always-On AgentsBackground work is useful. A product manager can ask an agent to organize customer feedback. An engineer can have an agent inspect logs and suggest a fix. A founder can ask for a first draft of an investor update while traveling.The risk is that an agent can keep acting after the user stops watching closely. That is not automatically unsafe, but it does require better boundaries.Teams should separate agent permissions into clear categories:| Permission Category | Typical Use | Recommended Control |
|-|-|-|
| Read local files | Inspect a repo, folder, or document set | Limit by folder or workspace scope |
| Read connected apps | Pull context from email, docs, CRM, issue trackers, or logs | Grant narrow access and avoid sensitive data by default |
| Write local artifacts | Create files, edit docs, or prepare code changes | Require reviewable diffs or version history |
| Send external messages | Send email, publish content, open tickets, or notify users | Require explicit human confirmation |
| Perform production or destructive actions | Deploy, delete, modify billing, change permissions, or run irreversible commands | Keep human execution mandatory |Mobile confirmation can speed up the workflow, but it should not replace real approval design. A phone tap should confirm a well-scoped action, not grant broad access to an unclear task.## What Coding Teams Should Change###
- Define task boundaries before executionEvery agent task should start with a short task brief. The brief should include the goal, allowed context, allowed tools, forbidden actions, expected output, validation method, and stop condition.This is especially important for coding tasks. A vague request like “fix this issue” is too broad for an unattended agent. A safer version would name the issue, identify the relevant files or modules, specify the test command, and require a diff plus risk notes.###
- Ask for evidence, not only answersAgent outputs should include proof. For code tasks, that means diffs, test results, build logs, and a short explanation of risk. For research tasks, it means source links, confidence level, and open questions. For operational tasks, it means the action plan, affected systems, rollback notes, and approval points.The goal is not to make the agent write longer reports. The goal is to reduce review cost.###
- Route tasks by risk and costNot every task needs the strongest model or the longest reasoning budget. Low-risk formatting, summarization, and classification tasks can often run with cheaper or faster models. Architecture changes, migrations, production debugging, and security-sensitive tasks should use stronger models and stricter review.Model routing should be part of the harness, not an afterthought. A team that routes by risk can control cost without lowering safety.###
- Limit memory deliberatelyAgents may benefit from stable project memory: repository rules, common commands, naming conventions, architecture notes, and style preferences.They should not casually store secrets, credentials, customer data, temporary assumptions, or unverified conclusions. Memory is useful only when it is curated. Otherwise, it becomes another source of hidden context drift.## A Practical Harness TemplateTeams do not need a complex platform to start. They can begin with a simple task template and apply it consistently.```YAML
task_goal: "Describe the exact outcome the agent should produce."
allowed_context:
- "List the folders, files, tickets, logs, or documents the agent may read."
allowed_tools:
- "List tools such as terminal, browser, issue tracker, docs, or test runner."
forbidden_actions:
- "No production deploys."
- "No external messages."
- "No deletion of files or data."
validation:
- "Run the relevant tests or checks."
- "Include command output or explain why validation could not run."
expected_output:
- "Provide a diff, summary, risks, and next steps."
human_approval_required_for:
- "Sending messages"
- "Deploying"
- "Deleting data"
- "Changing permissions"
stop_condition: "Stop when the output is ready for human review or when required context is missing."
- Can it use tools safely and stay within the requested scope?
- Does it produce small, reviewable changes instead of large unclear rewrites?
- Does it provide test results, citations, logs, or other evidence?
- Does it know when to stop and ask for human input?
- How expensive is the run in tokens, time, and review effort?
- How hard is it to roll back a failed result?Run each task more than once. Agents are probabilistic systems. A single impressive run does not prove reliability, and one bad run does not prove the tool is unusable. Look for completion rate, failure types, review cost, cost per useful output, and recovery effort.## Market SignalsClaude Cowork is part of a larger movement. AI tools are becoming agent systems that combine models, tools, permissions, memory, logs, and evaluations.Amazon Bedrock AgentCore shows how cloud platforms are moving toward managed agent infrastructure. Research discussions around harness engineering point to the same idea: model capability matters, but the system around the model determines whether it can be used reliably. OpenAI’s Codex materials also frame the agent loop as an orchestration problem involving prompts, tools, execution, and context management.The practical takeaway is simple: the next stage of AI products will not be won only by choosing the strongest model. Teams will also need better context strategy, safer tool permissions, persistent logs, repeatable evaluation, and clear human control.## Recommended Action Plan### Week 1: Audit current agent usage
List every AI agent or coding assistant used by the team. Include desktop apps, web agents, IDE tools, browser agents, internal bots, and scripts connected to model APIs. For each tool, document what it can read, what it can write, and whether it can trigger external actions.### Week 2: Classify tasks by riskSeparate tasks into low, medium, and high-risk groups.Low-risk tasks may include formatting, summarization, and draft generation. Medium-risk tasks may include code edits, data transformation, or issue triage. High-risk tasks include production changes, customer data handling, security work, billing changes, and external communication.### Week 3: Build a small internal benchmarkPick 20 real tasks from the last month. Use them as a benchmark set. Include successful tasks, failed tasks, ambiguous tasks, and tasks that required human correction.Measure completion rate, review time, evidence quality, token cost, and rollback complexity. This gives the team a practical way to compare agents instead of relying on marketing claims.### Week 4: Standardize instructions and validationAdd repository instructions, task templates, validation commands, logging expectations, and stop conditions. Make the review process visible. If an agent cannot show what it changed and how it validated the result, the task should not be treated as complete.## FAQ### What is Claude Cowork?Claude Cowork is Anthropic’s agent-style workflow for handing tasks to Claude across supported surfaces such as desktop, web, and mobile. It is designed for outcome-based work where Claude can use files, tools, and connected workflows, while the user reviews and approves important results.### Why does Claude Cowork on mobile and web matter?Mobile and web access make agent tasks easier to monitor and continue outside the desktop environment. The bigger change is that agent work becomes more asynchronous, which means teams need stronger rules for permissions, review, logs, and validation.### What is an agent harness?An agent harness is the system around the model that manages context, tools, state, memory, logs, validation, and human approval. It turns a model from a text generator into a controlled workflow system.### Is mobile confirmation enough for agent safety?No. Mobile confirmation is useful, but it should only approve clearly scoped actions. Sensitive actions such as sending external messages, changing production systems, deleting data, or changing permissions should still require explicit review and well-defined approval rules.### How should a coding team use AI agents safely?Start with narrow tasks, clear context limits, reviewable diffs, test output, and stop conditions. Avoid broad access to repositories, credentials, customer data, or production systems unless there is a strong approval workflow.### What should an agent return after a coding task?A useful coding-agent output should include the changed files, a summary of the diff, test or build results, known risks, and any follow-up work. This makes review faster and reduces the chance of hidden mistakes.### How can teams compare Claude Cowork, Codex, Cursor, Copilot, and other agents?Use real tasks from your own workflow and run each tool against the same acceptance criteria. Compare completion rate, review cost, failure type, output evidence, token cost, and rollback effort rather than judging only by a single demo.## Related Tools- Claude Cowork: Anthropic’s agent workflow for assigning tasks to Claude across supported devices and work surfaces.
- Claude Code: Anthropic’s coding agent for terminal and IDE-based development workflows.
- OpenAI Codex: OpenAI’s coding agent for building, editing, reviewing, and shipping software with AI support.
- GitHub Copilot: GitHub’s AI coding assistant for code suggestions, chat, reviews, and developer workflows.
- Cursor: An AI coding environment focused on codebase-aware editing, chat, and agent-style software development.
- Amazon Bedrock AgentCore: AWS infrastructure for building, deploying, and operating AI agents at scale.## Related Links- Original NxCode Article: The source article that inspired this English publishing version.
- Claude Cowork Product Page: Official page for Claude Cowork capabilities, supported surfaces, and plan availability.
- Use Claude Cowork Safely: Anthropic’s safety guidance for permissions, remote sessions, prompt injection, and human oversight.
- Amazon Bedrock AgentCore Harness GA: AWS announcement for managed agent harness infrastructure.
- Harness Engineering for Self-Improvement: Lilian Weng’s discussion of harness engineering and AI system improvement.
- OpenAI Codex Developers: Official developer page for Codex as a coding agent.
- Unrolling the Codex Agent Loop: OpenAI’s technical explanation of how Codex orchestrates model calls, tools, prompts, and context.## SummaryClaude Cowork moving across desktop, web, and mobile is a useful product update, but its real meaning is deeper. AI agents are becoming persistent task systems that can keep working outside a single chat window.For teams, the right response is not to give agents unlimited freedom. The safer path is controlled delegation: narrow task scope, explicit permissions, reviewable outputs, persistent logs, validation commands, and human approval for sensitive actions.A strong agent harness makes the agent easier to trust because it makes the work visible and auditable. Start with small tasks, measure performance on real workflows, and expand permissions only when the review process is strong enough.The future of agent work is not just smarter models. It is better harness design around the models.
