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.
