Do I need a developer, a Zapier subscription and a diagram of webhooks to actually build one of these things — or can the desktop tool do it on its own? It is a fair question, because the honest answer decides whether any of this is realistic for a team without engineers.
The short version: for most of what matters, yes. Cowork has the building blocks natively, and you assemble them by describing what you want rather than by wiring infrastructure.
Here is what it gives you without a single other platform.
Scheduled tasks. You can set a task to run on a cadence — every weekday morning, the first of the month, whatever the work demands — and it executes on its own. This is the heartbeat of any agent that does recurring work: the Monday briefing, the weekly competitor sweep, the overnight literature scan.
Subagents. Claude can break a job into parallel workstreams and run them at once, each in its own context, reporting back to a coordinator. That is the fan-out-and-synthesise pattern, the verification pattern and the tournament from the last piece — all native. You do not build the parallelism; you ask for it.
Connectors and plugins. It reaches your actual tools — the document store, the spreadsheet, the systems your work already lives in — under governed access. A plugin bundles the skills, connectors and subagents for a particular job into one reusable package, so the agent you build once becomes something the whole team can run.
Local files and a code sandbox. It reads and writes real documents, runs code when a task genuinely needs it, and produces finished outputs — a populated spreadsheet, a drafted pack — rather than just describing them.
Put those together and a real workflow falls out of the description. The advisory board pack from the last piece can run as one scheduled Cowork task: pull the pre-reads from the connector, fan out subagents to summarise the data and the prior transcripts, run a verification subagent over every claim, loop until the transcript yields nothing new, and drop a reviewed draft in your folder by morning. No n8n. No Zapier. No code you have to maintain.
Now the honest catch, because there is one, and it is the same reason serious pipelines still keep one foot in another platform.
Cowork’s tasks are time-based, not event-based. It will run at seven; it will not run “the instant a new item appears.” If your agent needs to react to something the moment it happens — an inbound enquiry, a new filing, a tagged article — you still need a trigger living elsewhere, a webhook or a service like Zapier, to poke it awake. And it runs only while your computer is on and the app is open, so anything that must fire at three in the morning on a sleeping laptop wants a server, which means coding against the Agent SDK or a hosted setup rather than the desktop. The production niceties — retries, monitoring, version control — are likewise thinner than a purpose-built platform offers.
The sensible division of labour, then, is this. Build the judgement in Cowork — the reading, the reasoning, the drafting, the checking, the parts that actually require understanding your field — and reserve the external machinery for the narrow jobs of “tell it the moment something happened” and “keep it running when the lights are off.” For a great many health communications workflows, the advisory board one included, you will not need the external machinery at all.
Which leaves the part worth sitting with. A year ago, building any of this meant briefing a developer and waiting. Now the person who understands the MLR line, the therapeutic nuance and the client’s actual question can assemble the agent directly, by describing it. That is the shift, and it is a larger one than it looks. The standing caveat travels with it unchanged: the agent is only ever as trustworthy as the verification you build into it, so keep a human between the model and anything a regulator will read.
— Ned