Anthropic offers two agentic tools whose names invite confusion. Claude Code is a coding agent, used from the terminal and developer tools, that works inside a software repository. Claude Cowork is an agent for general knowledge work that runs from the Claude desktop app and works with the files and folders you give it. Both can plan a multi-step job and act on files without you doing each step. They are built for different people and different outputs. This page is for business and operations teams deciding which tool a given task belongs to, how much access to grant, and how to review what comes back. Check the vendor's current documentation for availability, plans and supported connectors, since those change.
Start from the output, not the tool
The quickest way to sort a task is to picture the finished result. If it is a document, a spreadsheet, a slide deck, a tidied folder or a summary of a pile of files, it is knowledge work. If it is a change to software, such as a script, an integration or a fix to an internal tool, it is coding work, even when the person asking is not a developer.
| Task | Finished output | Better fit |
|---|---|---|
| Reconcile two expense exports and flag mismatches | One spreadsheet with a list of exceptions | Knowledge-work agent |
| Turn a folder of meeting notes into a weekly status report | A short document | Knowledge-work agent |
| Rename and sort a batch of scanned invoices by supplier and month | An organized folder | Knowledge-work agent |
| Make that reconciliation run automatically every month | A script that someone maintains | Coding agent, owned by a developer |
| Fix a bug in the internal tool that produces the exports | A reviewed code change | Coding agent |
A useful rule: a one-off result suits a knowledge-work agent; a mechanism that will run again suits a coding agent and needs an owner who can maintain it. The middle ground, a task you repeat by hand every week, deserves an honest conversation about whether it should become software.
Match the tool to the person who reviews the work
A coding agent assumes its operator is comfortable with a terminal, version control, reading a diff and running tests. A knowledge-work agent assumes someone who knows the content: which supplier codes matter, what the report is for, which numbers look wrong.
The deciding question is who can judge the output. An operations lead can check a reconciled spreadsheet line by line. The same person usually cannot tell whether a script handles edge cases correctly just by reading it. If an operations team wants an automation, the safer pattern is to prototype the logic with a knowledge-work agent on real files, agree on the result, then hand the repeatable version to someone who reviews code. Developers choosing between coding tools will find the trade-offs in terminal agent or editor agent.
Access scope: decide what each agent may touch
The two tools reach different parts of your environment. A knowledge-work agent typically works in folders on a computer and may connect to services such as email, calendars, shared drives or a browser. A coding agent works in a repository, runs shell commands and may see credentials stored in the project. In both cases, access is the main risk you control.
- Give a working folder, not your documents. Copy the inputs into a dedicated folder and point the agent there. Originals stay untouched.
- Connect services read-only first. Reading an inbox to draft replies is a different grant from sending them.
- Keep sensitive areas out of scope unless the task needs them: payroll, HR files, contracts, finance exports.
- For coding agents, use a branch and a written permission policy that says which commands run without asking.
- Check whether the tool asks before deleting or overwriting files, before sending anything and before running commands, and what its settings let you change.
Writing the scope down takes a minute and makes review easier later:
Folder: Ops/expense-check (copies only)
Read: two CSV exports from the expense system
Write: one new spreadsheet in Ops/expense-check/output
Not allowed: deleting files, sending email, any other folderThe note on starting agents read-only explains why starting narrow and widening later works better than the reverse.
Review needs different evidence for each output
For knowledge work, review means tracing claims back to inputs. Ask the agent to say which file and which row each number came from, to list its assumptions, and to list the items it could not match rather than quietly dropping them. Spot-check a handful of rows yourself. An item marked “could not find” is a useful result, not a failure.
For coding work, review means a diff, tests and a run on sample data, read by someone who understands the code. In both cases, decide before the agent starts what done looks like. Writing acceptance criteria first gives a simple format: what must be true of the output, what must not change, and what is out of scope.
Moments that should always pause for a person
Whatever the tool, a few kinds of action deserve a human decision before they happen: sending anything to people outside the team, deleting or overwriting files, moving data out of the company, setting up work that repeats on a schedule, acting inside a logged-in browser session, and changing the agent's own standing instructions. Write this list down for your team and check how each tool lets you enforce it. The seven action classes that pause for a person describe one way to draw these lines, and who may approve agent work covers who should make the call.
Where GoCux fits
Desktop and coding agents are personal tools: the work lives on one person's machine and the review happens in that person's head. When work belongs to a team, GoCux offers a shared company workspace where agents research, use tools, keep memory and produce deliverables, all within rules that someone on the team sets and can interrupt at any time.
Each piece of work is a work order with a goal, a scope and acceptance criteria. It moves from queued to running to awaiting decision to done, and nothing further down the line starts while a decision is pending. The kinds of action listed above wait for someone on the team to decide, everything stays inside the company boundary, work runs against visible credits under a daily cap, and a single stop control halts new work across the installation. The governance page describes these rules, and moving from an open question to a finished artifact shows what the result looks like.
How to decide, task by task
- Describe the finished output in one sentence. Document, sheet or folder: knowledge-work agent. Code or automation: coding agent.
- Name the reviewer and confirm they can judge that output.
- Copy inputs into a dedicated folder or branch and keep originals out of reach.
- Connect services read-only unless the task genuinely needs to write.
- Write the acceptance criteria and the scope before the agent starts.
- List the actions that must pause for a person, and confirm the tool can enforce them.
- Ask for sources, assumptions and unmatched items with every knowledge-work result.
- If the task will repeat, plan its handover to someone who maintains code.
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.