We started with a single sentence — when this happens, do that — and climbed all the way to agents that set their own steps. This last instalment is the most important, because it’s the one that decides whether all the rest helps you or quietly hollows out your work. The question isn’t what can Zapier do? By now the answer is “a startling amount.” The question is what should you let it?

Two piles

Sort the work into two piles. The first is dull, rules-based, repeated and reversible: gathering, filing, formatting, copying, reminding, first-pass sorting. This is the pile to automate without guilt. Every hour you reclaim here is an hour returned to the work that actually carries your name. The Signal pipeline lives entirely in this pile, and it should.

The second pile is judgement, taste, context and accountability: deciding what a finding really means, whether a claim is fair, how to phrase something a worried patient will read, what to leave out, when the data doesn’t support the headline everyone wants. This is the pile you do not hand over — not because the tools can’t produce something plausible, but because plausible is precisely the danger. A confident, well-formatted, subtly wrong paragraph is worse than a blank page, because it invites you to stop looking.

The test

When you’re unsure which pile a task belongs in, ask three questions. Is it reversible — if the machine gets it wrong, can you catch and undo it cheaply? Is it low-stakes — does a mistake cost minutes, or credibility? And is there a human at the gate before anything becomes fact, becomes public, or reaches a regulator? Three yeses and you can automate it. A single no and you keep your hands on it.

Why this is the whole point

This series has been practical — feeds, filters, AI steps, agents — but the thread underneath it is the reason this newsletter exists. The value of a health communications professional was never the typing, the filing or the formatting. It was the judgement: knowing what’s true, what’s allowed, what’s clear, and what’s safe to put in front of someone who will act on it. Automation is very good news for that person, because it strips away the part of the job that was never really the job.

The people who struggle in the next few years won’t be the ones who refused to automate. They’ll be the ones who automated the wrong pile — who handed over the judgement and kept the typing. Do it the other way round. Let the machine carry the queue. Keep the part only you can do.

That’s where we’ll leave it. Build the boring half. Guard the irreplaceable one.

Zapier for health communications is a practical series. This is the final part.

— Ned

We’ve climbed a ladder. Plumbing that moves things. Logic that branches. AI steps that interpret. Copilot that builds from a description. The top rung is the one everyone’s talking about and few are using well: agents. This is where automation stops following a fixed recipe and starts deciding its own steps — and where, for anyone in a regulated field, the questions get serious.

What an agent actually is

A normal Zap is a fixed track: trigger, then these steps, in this order, every time. A Zapier Agent is different. You give it a goal in plain English — “triage each new Signal item: judge relevance, summarise it, score it, and flag the strong ones for me” — and the agent works out how to get there. It reasons, picks which of its available tools to use, takes several actions, and can loop back if the first attempt falls short. The same agent can read a feed, write to a table, post to Slack and pause for a human, all from one instruction, across Zapier’s 9,000-plus connected apps.

The shift is from automation you choreograph to a teammate you delegate to. That’s genuinely powerful. It’s also exactly why you need to slow down before handing it anything that matters.

The capabilities worth knowing

Three features make agents more than a gimmick. Memory lets an agent carry context across runs, so it isn’t starting cold every time. Bring Your Own Model lets you choose which underlying AI powers it. And it can keep a human in the loop by design — pausing to wait for a named person’s approval before it does anything consequential. That last one isn’t a nicety in our world. It’s the whole basis on which an agent can be trusted at all.

The guardrails — and why they matter here

To Zapier’s credit, the platform has built a safety layer, and it maps almost exactly onto health communications anxieties. The guardrails scan for personally identifiable information across more than thirty types, detect prompt-injection attempts, and flag toxic or harmful language and negative sentiment. In plain terms: it tries to stop an agent leaking patient or personal data, being hijacked by malicious text hidden in its inputs, or producing something it shouldn’t.

Take the prompt-injection point seriously. An agent that reads external content — emails, web pages, documents — can be fed instructions buried in that content, designed to make it act against you. In a field where the inputs are clinical documents, KOL correspondence and regulated copy, that is not a theoretical risk. Guardrails reduce it; they do not abolish it.

Where the line sits

So here’s the honest position. An agent triaging your Signal queue, drafting first-pass summaries, flagging what looks strong for your review — that’s a fine use. The work is reversible, low-stakes, and a human sees everything before it goes anywhere. Let the agent move work to the gate.

An agent that drafts a claim and sends it, adjusts approved copy without review, or touches anything destined for a regulator without a person signing it off — that’s the wrong side of the line, guardrails or not. The technology is ready to propose. It is not ready, and may never be ready in our field, to decide unattended. Keep a named human accountable at every consequential step, by design and not as a courtesy.

Next: 16. Zapier: what you don’t hand to the robot — the closer, on where automation stops and your judgement begins.

Zapier for health communications is a practical series. New post every week.

— Ned

Until now we’ve built everything by hand — picking triggers, choosing actions, wiring steps together. That skill still matters, but the way you start a build has changed. Zapier now lets you describe what you want in plain English and have it assemble the thing for you. It’s the difference between knowing how to lay bricks and being handed the walls. You still need to know what a good wall looks like.

Copilot: say it, and it builds it

Zapier Copilot takes a plain-English description — “when a new item lands in my Inoreader folder, summarise it and add it to my Signal table” — and builds the Zap, choosing the trigger, the steps and the connections. Zapier reports success rates around 92% for simple Zaps, which is to say: for the everyday stuff, it mostly just works.

What this changes is the starting line. Instead of staring at an empty canvas wondering which trigger you need, you describe the outcome and let Copilot produce a first draft of the automation. You then check it, correct it, and switch it on. It also builds the other pieces — a Table, an Interface, an agent — from the same kind of instruction.

The catch is the obvious one: Copilot builds what you said, not what you meant. It will happily wire up something subtly wrong with total confidence. So the old understanding isn’t obsolete — it’s what lets you look at the draft and spot that the filter is in the wrong place or the date format will break the next step. Describing is faster. Reviewing is still on you.

Canvas: drawing the system before you build it

Canvas is the companion piece, and it works the other way round. It’s a visual space for mapping a workflow or a whole system — boxes and arrows for how information should move — which you can then turn into actual Zaps. Sketch the flow first, agree it’s right, then generate the build from the diagram.

For anything with more than a couple of branches, this is genuinely useful. It forces you to think the process through before committing to it, and it gives you a picture you can show a colleague or a client without making them read a list of steps. Map, agree, build — in that order — and you make your mistakes on a diagram instead of in a live automation.

What this shift really means

Step back and the pattern is clear: the centre of gravity is moving from operating the tool to specifying the outcome. The valuable skill is no longer remembering where a setting lives; it’s being able to describe precisely what you want, and to recognise when what you got back isn’t it.

That’s a comfortable shift for people who work in health communications, because precise specification is already the job. A good brief, a clear set of requirements, an exact description of the output you need — that is the same muscle. The people who get the most from Copilot and Canvas won’t be the most technical. They’ll be the clearest.

Next: 15. Zapier: when the automation makes decisions — agents that set their own steps, and the guardrails that decide whether you can trust them.

Zapier for health communications is a practical series. New post every week.

— Ned

Everything so far has been plumbing — reliable, literal, and a bit dim. It moves things and checks conditions, but it doesn’t understand anything. This week the automation gets a brain. Zapier now lets you drop AI into the middle of a workflow, keep smarter data, and put a chatbot over your own material. Used well, it closes the gap between moving information and making sense of it. Used carelessly, it’s how a confident mistake ends up in your queue.

AI steps: judgement, inserted mid-Zap

The headline change is the AI step. Between a trigger and an action, you can now ask a model to do something with the data passing through: summarise this article in one line, classify whether it’s relevant to my themes, pull out the key claim, draft a neutral one-sentence gist, tag it by topic.

Go back to the Signal filter from a fortnight ago. That filter matches keywords — it sees words, not meaning. An AI step can read the item the way a person skim-reads it and judge relevance on substance, not vocabulary. The blunt instrument becomes a sharp one. The same trick writes you a tidy summary column, or sorts items into themes, before anything reaches your eyes.

Tables: a database that thinks

Zapier Tables is a database built for automation, living inside Zapier itself rather than bolted on via Sheets. For a Signal-style queue it’s a natural home: structured columns, and crucially an “AI Enrich” feature that auto-fills a field by running a prompt against the rest of the row. A “one-line summary” column or a “relevance score” column that populates itself as each item lands — no extra Zap required.

If you’ve outgrown a Google Sheet that’s creaking under formulas and helper Zaps, this is the upgrade.

Chatbots: answers from your own material

The third piece is chatbots you can point at your own content — a set of files, webpages, or a table. Feed it your style guide, your past issues, your house rules, and you have something you (or a colleague) can ask in plain English: “have we covered this topic before?”, “what’s our line on AI-written patient materials?” It’s a way to make institutional knowledge queryable instead of buried.

The caveat that never goes away

Here is the part that matters more in our field than almost any other. The moment you let a model interpret, you inherit its failure mode: it will be confidently wrong some of the time. It will summarise a study and quietly overstate the finding. It will tag something safe that isn’t. It will, asked to “extract” a statistic, invent a plausible one.

So the rule holds, and hardens: an AI step is a drafting aid, never an authority. Use it to triage, summarise and sort — work where a wrong call is cheap and caught at the next human glance. Keep it well away from anything that ships as fact without a person checking it against the source. In regulated health communications, the verification isn’t overhead. It’s the job.

Next: 14. Zapier: just describe it — using Copilot and Canvas to build automations by describing what you want, instead of wiring every step by hand.

Zapier for health communications is a practical series. New post every week.

— Ned

The Signal pipeline from last week was deliberately simple: watch, filter, tidy, file. Real work is rarely that linear. Sooner or later you want a Zap that makes choices — do this for press releases, that for preprints — and copes with the mess that real data arrives in. That is what this instalment is about: the four building blocks that turn a toy automation into something you’d actually trust.

Filters: the bouncer on the door

A Filter does one job: it lets a Zap continue only if conditions are met, and quietly stops it otherwise. “Only continue if the source is on my approved list.” “Only continue if the headline contains one of these terms.” It is the single most useful step you will add, because most automation problems are really too much happening problems. A good filter is the difference between a queue you read and a queue you avoid.

The craft is in being neither too tight nor too loose. Too tight and you silently drop things that mattered; too loose and you’re back to noise. When in doubt for editorial work, lean loose — a few extra items to skim beats a missed story you never knew about.

Paths: when the answer is “it depends”

Filters are pass/fail. Paths let a single Zap branch: if the item is a regulatory announcement, do one thing; if it’s a journal article, do another; otherwise, do a third. Each path has its own conditions and its own actions, all inside one Zap you can see end to end.

This is where automation starts to mirror how you actually think. You don’t treat an FDA warning letter the same as a conference abstract, and now your Zap doesn’t have to either. Resist the urge to build a maze, though — two or three clear branches you understand beat ten you don’t.

Formatter: making messy data behave

Data arrives ugly. Dates in five formats, names in inconsistent case, links wrapped in tracking junk, text with line breaks where you don’t want them. Formatter is Zapier’s quiet workhorse for cleaning all of that: reformat a date, trim whitespace, change case, extract a number or an email from a block of text, split a field, find-and-replace.

It is unglamorous and it is essential. Most automations that “don’t work” aren’t broken — they’re choking on data that arrived in a shape the next step didn’t expect. A Formatter step in the right place fixes more problems than any amount of clever logic.

Schedules, delays and lookups

Three more tools worth knowing, briefly. Schedule lets a Zap run on a clock — every weekday at 7am, say — rather than only when something happens, which is how you’d build a daily digest. Delay holds an action for a set time or until a specified moment, useful when you want a pause before a follow-up. Lookup checks whether a record already exists before creating it, which is how you stop a Zap filing the same item twice.

The principle underneath

Every one of these is a small, legible piece of logic. The skill is not memorising features; it’s decomposing your own process into steps clear enough to hand over. If you can write down, plainly, “when X arrives, check Y, and if so do Z — otherwise do W,” you can build it. The tools are easy. The thinking is the work, and the thinking is yours.

Next: 13. Zapier: giving your Zaps a brain — adding AI steps, Tables and chatbots, so your automation can start to interpret, not just move.

Zapier for health communications is a practical series. New post every week.

— Ned

Last time I made the case that Zapier is just “when this happens, do that.” This week, the proof: the actual pipeline that feeds Signal, the news section of this newsletter. It is not clever. That is the point. It runs every day, it never forgets, and it turns a chaotic firehose of industry news into a single, reviewable list I can sit down with.

Here is the whole thing, step by step.

The problem it solves

Keeping across AI in health communications means watching dozens of sources — trade press, company announcements, regulators, preprint servers, a few sharp individuals. Done by hand, that is an hour of tab-juggling every morning, and the day you skip it is the day the story breaks. I wanted the watching to happen on its own, so my time goes on the judgement: what matters, and why.

The pipeline

Trigger — a new item appears in my reading feeds. I keep my sources organised in an RSS reader (Inoreader), grouped into a single folder of things worth monitoring. Zapier watches that folder. The moment a new article lands, the Zap fires. No app to open, no button to press.

Filter — is this actually relevant? Most of what comes through is noise. A Filter step checks each item against a set of conditions — does the headline or summary mention the themes I track? — and quietly stops anything that doesn’t qualify. Nothing downstream happens unless the item clears the bar. This one step is the difference between a useful queue and an unreadable one.

Format — make it consistent. A Formatter step tidies the raw feed data into the shape I want: a clean title, the source, the link, the date in a sensible format. Feeds are messy; this makes every entry land the same way.

Action — add it to the queue. Finally, Zapier writes a new row into a Google Sheet — the Signal Queue. Title, summary, source, URL, date, each in its column, ready for scoring. That sheet is the thing I actually open.

That’s four steps: watch, filter, tidy, file. One trigger, three actions, running unattended.

What I’m left with

By the time I sit down, the morning’s reading has already sorted itself into a single list of candidates — filtered, formatted, and waiting. My job starts where the automation stops: reading each one properly, deciding what earns a place, and writing the line that makes it worth your time. The machine does the gathering. I do the choosing.

That division is deliberate, and it is the whole philosophy of this series. Automation is brilliant at collecting and hopeless at judging. Let it collect.

The honest limitations

The filter is blunt. It works on keywords, not understanding, so it lets through things that match the words but miss the point, and it occasionally drops something it shouldn’t. I’d rather it err towards letting too much through — a few extra items to skim beats a missed story. Making that filter smarter, so it judges relevance more like I would, is exactly where the AI steps come in — and that is the next stage of this series.

For now, the lesson is the one that matters most: you do not need anything sophisticated to claw back real time. A trigger, a filter, a tidy-up and a destination will do it.

Next: 12. Zapier: when one step isn’t enough — filters, paths and tidy data, and how to build a Zap that handles the messy real world.

Zapier for health communications is a practical series. New post every week.

— Ned

If you work in health communications, you already run on small, repetitive tasks that don’t need your brain but still eat your day. Saving an email attachment to the right folder. Copying a line from a form into a tracker. Pasting a link into a spreadsheet so it doesn’t get lost. Pinging a colleague when something lands. None of it is hard. All of it is friction.

Zapier is the tool that does that moving-around for you, automatically, while you get on with the work that actually needs judgement.

That’s the whole pitch. Everything else is detail.

The one idea

Strip away the marketing and Zapier rests on a single sentence: when this happens, do that.

When a new email arrives, save the attachment. When a form is submitted, add a row to a sheet. When an item appears in a feed, drop it into a tracker. The first half is the trigger — the thing that kicks it off. The second half is the action — what you want done in response. String the two together and you have a “Zap”: a small, automatic rule that runs without you.

You are not programming. You are describing a piece of your own routine to a tool that can then repeat it forever, in seconds, without getting bored, distracted, or forgetting step three on a Friday.

The four words worth knowing

You can ignore almost all of Zapier’s vocabulary, but four words make everything else make sense:

• App — any service Zapier can talk to: Gmail, Google Sheets, Outlook, Slack, Dropbox, your RSS reader, thousands more.

• Trigger — the event that starts a Zap (”new email in this label”, “new row in this sheet”).

• Action — what Zapier does in response (”create a document”, “send a message”, “add a row”).

• Zap — one trigger plus one or more actions, switched on and running.

That’s the entire mental model. If you understand “when this app does X, make that app do Y,” you understand Zapier.

Why this matters for a small operation

Big teams buy automation to save headcount. For a one-person publication or a lean health communications team, the value is different and, frankly, better: it gives you your attention back. The hour you’d otherwise spend filing, copying and chasing is the hour you don’t have for the thing only you can do — the editorial call, the nuance, the sentence that has to be exactly right because a regulator might read it.

Automation is at its best on work that is dull, rules-based and repeated. It is at its worst — and we will come back to this hard, later in the series — on work that needs taste, context or accountability. Knowing which is which is the whole skill.

What Zapier is not (yet)

A point worth planting early, because it gets muddled: in its simplest form, Zapier is not making decisions. It is not reading your content and judging it. It is plumbing — reliable, literal, slightly dim plumbing that does exactly what you told it and nothing more. That is a feature, not a flaw: predictable is precisely what you want from something running unattended.

The clever, decision-making, “agentic” end of Zapier is real, and it is where this series is heading. But you earn the right to it by understanding the plumbing first.

Build one in five minutes

The fastest way to get it is to make one trivial Zap and watch it work. Try this:

• Sign up for the free plan and click Create.

• For the trigger, choose an app you already use — say Gmail — and the event “New Attachment”.

• Connect your account and pick the label or search term to watch.

• For the action, choose Google Drive and “Upload File”, pointing it at a folder.

• Run the test. Zapier grabs a recent attachment and files it for you.

• Switch it on.

That’s it. A small, dull job now does itself. Nothing here will change your life — but it is the same shape as everything that follows, including the workflow I actually rely on every week.

Next: 11. Zapier: how I actually build Signal — the real pipeline that fills the queue behind this newsletter, start to finish.

Zapier for health communications is a practical series. New post every week.

— Ned

Below are six patterns for wiring several agents together, each with the shape it makes on the page. None of them is new — they are borrowed from distributed computing and have been quietly running your search engine and your bank for years. What has changed is that you can now assemble them yourself, in an afternoon, without writing the plumbing underneath. Here is what each one does, and where it earns its keep in health communications.

1. Classify-and-act. A router. One agent reads the incoming task and sends it down the right path — triage an inbound medical-information query to the correct specialist, or sort a piece of content by whether it needs MLR review at all. Cheap, and it stops you running an expensive workflow on something that needed a one-line answer.

2. Fan-out-and-synthesise. Several agents work the same problem in parallel, and a final agent merges their output. Useful when a task has genuinely separate facets — summarise a data readout for efficacy, safety and access at the same time, then stitch the threads into one briefing.

3. Adversarial verification. A worker produces; independent verifiers check. This is the pattern that matters most in regulated work, and the one teams skip first. A drafting agent writes, a separate agent checks every claim against source, and a third checks against the MLR rulebook. Never let the model that wrote the copy be the one that signs it off.

4. Generate-and-filter. Many cheap generators throw out ideas; a filter scores them against a rubric and removes the duplicates; the best survive. Headline options, discussion questions, plain-language summaries — generate forty, keep four.

5. Tournament. When “best” is a matter of judgement rather than a checklist, judge the candidates pairwise and let a winner emerge. Slower than a filter, better when quality is subjective — choosing the sharpest framing of an executive summary.

6. Loop until done. An agent works, asks “is there anything new here?”, and spawns another pass if the answer is yes. A literature scan that keeps searching until it stops finding anything, then stops. The discipline is entirely in the exit condition; without a good one, it runs forever.

Where Cowork comes in

A year ago, wiring these together meant code — queues, retries, state you had to hold somewhere. Cowork collapses most of that. You describe the flow in plain language and it does the assembly: spawns the subagents, fans the work out, runs the verifier, loops until the exit condition trips, and reaches into your actual tools — the document store, the spreadsheet, the publishing platform — through connectors. The single advisory board agent from the last piece stops being the whole system and becomes one node in a larger graph. You compose the graph by describing it, not by building it.

That is the real shift, and it is easy to undersell. The patterns were always available to anyone with an engineering team. What is new is that the person who actually understands the regulatory and editorial constraints — you — can now assemble them directly, without translating every requirement through a developer first.

A worked example: the advisory board pack

Stitch four of the six together and you have a workflow that does real work.

Classify the incoming materials by therapy area and route them (1). Fan out across the pre-reads, advisor profiles and prior transcripts, and synthesise a board briefing (2). Generate candidate discussion questions and filter them against a rubric — non-leading, on-objective, compliant — discarding the rest (4). Then, and this part is non-negotiable, run the whole pack past a verification agent that checks every factual claim and flags anything MLR would catch (3). After the meeting, a loop-until-done pass mines the transcript for themes, spawning follow-ups until no new insight appears (6).

What used to be a fortnight of associate time becomes a reviewed first draft by the morning after the meeting. Not a finished pack — a first draft, with the checking already done and the gaps already marked.

The patterns are old. The ability to assemble them without an engineering team is the actual change. And, as ever, adversarial verification is the step you cannot afford to leave out — in this field, the workflow that generates is only as trustworthy as the one that checks it.

— Ned

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

Here is something that will save you a great deal of time on any complex project, not just this one.

Before you open MindStudio. Before you touch a spreadsheet. Before you ask any AI to do anything — ask it to think the whole thing through with you first.

Most people start by asking AI to do tasks. Write this. Summarise that. The results are mixed, because the task was underspecified. The better approach is to start with a plan. Tell the AI what you are trying to achieve, what you know so far, and ask it to map out every step between where you are and where you want to be. Then work through that plan together, step by step, with the AI doing the heavy lifting at each stage.

This changes how the whole project goes. Instead of improvising your way through a complex build and hitting walls you did not anticipate, you have a clear sequence. You know what comes first. You know what the blockers are likely to be. You know what a finished version looks like before you start.

This matters especially if you are not technical. Technical people have mental models of how builds work — they can roughly anticipate the shape of a project before they start. If you have not built agents before, you do not have that mental model yet. The planning prompt below gives you one, immediately, for this specific project.

Use this prompt. Copy it, paste it into Claude or any capable AI, fill in the brackets, and read the plan it gives you before doing anything else.

The planning prompt

Copy and paste this into Claude, ChatGPT, or any capable AI. Fill in the bracketed sections with your own details before sending.

I want to build an AI-powered agent to help manage the preparation and delivery of medical advisory boards. I work in health communications and I am not a developer — I am comfortable with technology but I have not built an agent before.

Here is what the agent needs to do: help identify and select appropriate advisors; check for potential conflicts of interest before invitations go out; pull relevant recent publications by each confirmed advisor; draft personalised briefing packs using a standard template; track submissions to Medical, Legal, and Regulatory review and manage the comment process; synthesise the meeting transcript into a structured draft report; log transfers of value for compliance purposes; draft personalised thank-you letters after the meeting.

My team size is [YOUR TEAM SIZE]. We currently manage this process [MANUALLY / WITH SOME TEMPLATES / IN A SPREADSHEET — describe your current state]. Our biggest bottleneck is [DESCRIBE YOUR MAIN PAIN POINT].

I want to use [MINDSTUDIO / N8N / I AM NOT SURE YET] as my platform.

Please give me a complete, step-by-step plan to build this. Structure it so that: I know exactly what to do first, second, third — in the right order; each step is broken down into plain-language tasks I can actually complete; you flag anything where I will need technical help or might get stuck; you include what I need to test at each stage before moving to the next; you tell me what a working version of each stage looks like, so I know when I have succeeded. Assume I am starting from scratch today. Do not skip steps because they seem obvious — this is the first time I have done this.

What the plan looks like

Below is what a well-structured AI response to that prompt produces — the actual plan for this build, worked through in full. If you create a plan and the language is unclear, ask for clarity/simplification/whatever it takes. NOTE: You will likely find yourself asking for more details and help on the agent platform. Cowork and any AI tool often gets the menus wrong. You can take screengrabs of what you asee and choices you are being asked to make and you can get direction.

Week 1: foundations

Day 1 — Audit your current process. Before touching any tool, write down every step your team currently takes to prepare an advisory board, from first brief to post-meeting filing. Include who does each step, how long it takes, and where things most often stall or go wrong. This document becomes your specification. You cannot build an agent for a process you have not clearly described.

Day 2 — Set up your advisor tracker. Create a Google Sheet (or Airtable) with the columns described in Part Three of this guide. Populate it with five to ten real advisors you work with regularly. This is the test data you will use throughout the build. Do not skip this step — every agent stage reads from or writes to this tracker, and if it does not exist, nothing else can be tested.

Day 3 — Create a MindStudio account and complete the onboarding. Connect your Google Sheet. Upload one example briefing pack template and one example pre-read document as reference files. Confirm these connections are working before proceeding.

Day 4 — Build and test Step 1 only (KOL landscape mapping). Use the prompt from Part Four. Run it with a real therapeutic area. Read the output critically: is it useful? Does it give you a starting frame you would actually use? If not, adjust the prompt and run it again. Do not move to Step 2 until Step 1 produces output you would use.

Day 5 — Build and test Step 2 (COI pre-check). Connect the agent to your advisor tracker. Test with one advisor whose declaration of interests you already know. Verify that the agent flags what it should flag. Set up the human checkpoint so the workflow pauses here and sends a notification for review.

Week 2: the core workflow

Day 6 — Set up PubMed API access (free, takes approximately thirty minutes following the NCBI instructions). Build and test Step 3 (publication pull) with two or three advisors whose publication records you know. Verify that the agent is finding the right papers.

Day 7 — Build Step 4 (briefing packs). This step depends on Steps 2 and 3 working correctly, so only start here once those are solid. Test with one complete advisor profile through to finished briefing pack. Read the output as if you were going to send it. Adjust the prompt until the output needs only light editing, not rewriting.

Day 8 — Build and test Steps 5 and 6 (MLR tracking and comment management) as a separate workflow. Test Step 5 with a real pre-read claim list. Test Step 6 with a real set of MLR comments from a previous project.

Day 9 — Run the entire pre-board workflow end-to-end with a real upcoming advisory board as a dry run. Do not use this output for the actual board. Compare the agent output to what your team would have produced manually. Note every difference. Adjust prompts as needed.

Day 10 — Brief everyone who will use the workflow. Show them where the human checkpoints are and what they are expected to do at each one. The agent fails if the human steps are skipped.

Week 3: the post-board workflow

Days 11–12 — Build and test Steps 7, 8, and 9 (transcript analysis, TOV logging, thank-you letters). Step 7 requires real rapporteur notes to test properly — use notes from a completed board. Steps 8 and 9 are more straightforward; test with real data from a recently completed engagement.

Day 13 — Run the complete post-board workflow with data from a recently completed board. Compare the agent output to the documents your team produced at the time. This is your quality benchmark.

Day 14 — Review the whole system. What is working well? What is producing output you do not trust? What human checkpoints are being used correctly, and which are being skipped? Most fixes at this stage are prompt-level — small changes to the instructions that produce materially better output.

Ongoing: After your first live use on a real board, you will have concrete feedback on what to improve. Treat the prompts as living documents. The most important thing to track is not whether the agent is fast, but whether the human reviewers trust its output. If they are reading carefully and catching occasional errors, the system is working correctly. If they are rubber-stamping without reading, that is the problem to fix.

Why this approach works

The plan above was produced by asking an AI to think through the problem systematically, then refining it against the real requirements of the build.

This is the principle that matters: for any project more complex than a single task, start by asking your AI to plan it. Not to do it — to plan it. Give the AI the full context of what you are trying to achieve, what you already know, and what your constraints are. Ask it to produce a step-by-step sequence with dependencies, blockers, and success criteria at each stage. Read the plan before you act.

Then work through the plan with the AI as your partner. At each stage, paste in the relevant context, ask the AI to complete that specific step, review what it produces, and move on. You are not delegating the project — you are directing it. The AI handles the execution of each step; you maintain the judgement about whether each output is good enough to proceed.

This is slower than just diving in. It is also significantly faster than building something wrong and having to unpick it. The planning conversation typically takes thirty to sixty minutes. The time it saves — in avoided dead ends, in decisions made clearly rather than by accident, in builds that actually work the first time you use them — is measured in days.

The people who get the most out of AI are not the ones who give it the most tasks. They are the ones who think most carefully about what they are trying to achieve before they start.

The workflow is mapped. The spec is written. Here is how to actually build it — platform, configuration, and every prompt.

This guide assumes you have read the annotated workflow and understand which stages the agent handles. This guide picks up where that one ends: you know what the agent needs to do; now here is how to make it do it.

The build has three parts: choosing a platform, wiring up the tools, and writing the prompts that tell the agent what to do at each step. The prompts are the hardest part, and they are the part most guides skip. This one does not.

Part one: platform

MindStudio is the recommendation for this build. It is purpose-built for agents that run multi-step workflows, it handles document input and output well, and it does not require you to write code. The free tier will get you through the build; you will hit limits when you run it in production and will need a paid plan.

n8n is more flexible and more powerful, but it requires more technical comfort. If you have someone on the team who can configure it, n8n gives you better control over data handling and better integration with external systems.

Claude directly via the API is the right eventual destination if you are running this at scale or want to integrate it into existing systems. It requires a developer. Come back to this option once you have validated the workflow with a simpler tool.

Part two: tools the agent needs

Before you write a single prompt, connect the following: PubMed via its public API (free, no key required for basic access) for literature and publication searching; document handling so the platform can read and write Word files or PDFs; email — the agent should draft emails, not send them; a spreadsheet (Google Sheets or Airtable) for TOV logging and advisor tracking; and a CRM or contact manager for advisor profiles.

Part three: the tracker

Before you write any prompts, create your advisor tracker. This is the document the agent reads from and writes to throughout the process. It needs: advisor name, title and affiliation, therapeutic area, PubMed author ID or ORCID, declared interests, COI status, invitation status, contract status, TOV category, honorarium amount, honorarium paid date, expenses claimed, and expenses paid date.

This tracker is the agent’s source of truth. Every automated step reads from it or writes to it. Keep it clean.

Part four: the prompts

What follows is the complete set of prompts for each agent step. Each prompt is written to be pasted directly into Claude or into your platform’s prompt field for that step. Variables in [brackets] are filled by the platform from previous steps or from your tracker.

Step 1: KOL landscape mapping

Triggered when a new advisory board project is initiated and the therapeutic area is defined. Produces a longlist of potential advisor profiles.

Prompt: “You are supporting the faculty selection process for a medical advisory board. The advisory board topic is: [THERAPEUTIC_AREA]. The specific clinical questions the board will address are: [KEY_QUESTIONS]. Generate a structured longlist of potential advisor profiles. For each profile, include: the type of expertise needed (not a named individual — do not hallucinate names); the specific qualifications, practice setting, and career stage that would make this profile valuable; why this profile addresses the board’s key questions; and any potential conflict of interest categories to check for this profile type. Structure the output as a table. After the table, write a brief paragraph summarising the balance of perspectives the longlist represents and any gaps. Do not suggest named individuals.”

→ HUMAN CHECKPOINT: Review the profile list. Add named advisors. Confirm the shortlist before proceeding.

Step 2: COI pre-check

Run for each advisor on the shortlist. Produces a structured COI assessment.

Prompt: “You are supporting the conflict of interest review for a medical advisory board. Advisor name: [NAME]. Affiliation: [AFFILIATION]. Declared interests: [DECLARED_INTERESTS]. Sponsor company: [SPONSOR]. Board topic: [TOPIC]. Review the declared interests against the sponsor’s products and the board topic. Assess: direct financial relationships, indirect relationships with competitors, research conflicts, and topic conflicts. For each category, state: Conflict identified / No conflict identified / Insufficient information. Close with an overall COI status: Clean / Flagged / Insufficient information. Do not make a final determination on whether the advisor can participate. That decision belongs to the compliance team.”

→ HUMAN CHECKPOINT: Compliance team reviews all Flagged advisors before invitations go out.

Step 3: Publication pull

Triggered when an advisor is confirmed and their PubMed ID is in the tracker.

Prompt: “You have been provided with a list of publications by [ADVISOR_NAME], retrieved from PubMed. [PUBMED_OUTPUT]. The advisory board topic is: [THERAPEUTIC_AREA]. From this list, identify the publications most relevant to the board’s topic and questions. Select up to 8 publications. For each: full citation, one-sentence summary of the main finding, relevance to the board topic. After the selected publications, write a 3–4 sentence paragraph summarising this advisor’s published perspective on [THERAPEUTIC_AREA]. Flag any publications that suggest a strongly held position on a question the board will be debating.”

Step 4: Briefing pack generation

Triggered when advisor is confirmed, COI is clear, and publications are pulled.

Prompt: “You are drafting a pre-board briefing pack for [ADVISOR_NAME_TITLE]. Board date: [DATE]. Board objectives: [OBJECTIVES]. Key questions: [KEY_QUESTIONS]. This advisor’s specific role: [ADVISOR_ROLE]. Draft a briefing pack with: welcome and context (2–3 sentences); board objectives (bullet list); your role (1 paragraph, second person, specific); key questions for the day (numbered list); preparation (1 paragraph — what they should think about, not a reading list); and practical information [LOGISTICS PLACEHOLDER]. Write in plain, professional language. The advisor is a senior clinician — do not over-explain the science. Collegial and clear.”

→ HUMAN CHECKPOINT: Project lead reviews each briefing pack for accuracy and tone before distribution.

Step 5: Claims tagging for MLR

Prompt: “You are supporting preparation of pre-read materials for MLR submission. The pre-read document contains the following claims that require references: [CLAIMS LIST]. For each claim: identify what type of evidence is needed; suggest the most appropriate source type and specific publication where you can; flag any claim where the evidence base is uncertain. Format as a table: Claim number | Claim text | Evidence type needed | Suggested source | Confidence in claim | Notes. After the table, list any claims where you have identified a potential mismatch between the claim and the evidence.”

Step 6: Post-board transcript analysis

Prompt: “You are supporting the drafting of the meeting report for a medical advisory board. The board addressed the following key questions: [KEY_QUESTIONS]. The rapporteur notes are: [RAPPORTEUR_NOTES]. For each key question: summarise the range of advisor positions (2–4 sentences); identify the areas of agreement; identify the areas of productive disagreement; pull out any specific advisor formulations that should be preserved verbatim (flag these VERBATIM); summarise any specific recommendations. After the per-question synthesis, write an executive summary of 200–300 words. Important: do not smooth over disagreements. Flag anything that is unclear in the rapporteur notes.”

Step 7: Thank-you communications

Prompt: “Draft a thank-you letter to [ADVISOR_NAME_TITLE] following their participation in a medical advisory board on [DATE] on the topic of [TOPIC]. This advisor’s specific contribution: [CONTRIBUTION]. The sponsor’s next steps: [NEXT_STEPS]. Draft a letter of approximately 150–200 words. Thank the advisor specifically for their contribution — not generically. Reference one or two things they said that were particularly useful. Confirm what happens next with the outputs. Indicate when the advisor will hear from the team again. Tone: warm, direct, professional. Not a marketing communication.”

Part five: the build order

Build in this sequence: Step 1 first, test it with a real therapeutic area. Add Step 2, test with a real advisor profile. Add Step 3, which requires the PubMed API connection to be working. Add Step 4 once you’ve validated the first three. Build Steps 5 and 6 as separate workflows triggered by document events, not by the advisor onboarding sequence. Build Steps 7 and 8 as the post-board workflow.

The whole build, with testing, should take a competent non-developer two to three days. If it is taking longer, the most likely cause is the tool connections — API keys, sheet permissions, email integration. Resolve the connections first before debugging the prompts.

The test of a well-built agent is not whether it produces perfect output. It is whether the output it produces makes the human reviewer’s job faster and better. That is the standard to hold it to.

— Ned

There is a particular kind of confidence that AI agents display when they are wrong.

They don’t hesitate. They don’t add a caveat. They produce a beautifully formatted output with the same serene certainty whether they’ve done the job perfectly or made something up. This is not a bug they will grow out of. It is structural. And it is the main reason “human in the loop” is not a comfort phrase — it is an engineering requirement.

Here is what goes wrong, and what to build to catch it.

Hallucination at the wrong moment

AI models can generate plausible-sounding information that is simply not true. In a low-stakes context, this is annoying. In health communications, where claims need to be traceable to a source, it is a problem.

The most common failure mode in the advisory board agent from last week is Step 4 — the briefing pack generation. The model has been given the faculty bio, the publication abstracts, and the template. In most cases it does a good job. Occasionally, it will add a detail that wasn’t in the source material: a paper that doesn’t exist, a quote that was never said, an expertise that was inferred rather than stated.

The fix is in the prompt design, not the technology. Instructions like “only include information explicitly present in the source documents” and “if a section cannot be completed from the provided material, write ‘insufficient source data’ rather than inferring” reduce but do not eliminate the risk.

The remaining risk is why you still review the packs before they go out. Not because you don’t trust the agent. Because you can’t trust any process — human or automated — without a final check in a regulated environment.

The specification gap

The second most common failure is not a technology failure at all. It’s a specification failure. The agent does exactly what you told it to do, and what you told it to do was subtly wrong.

A prompt that says “pull recent publications” will pull recent publications. But what counts as recent? Relevant to what? In what journals? The agent will make choices on these questions based on what seems most reasonable given the available context. Those choices will sometimes be wrong in ways that matter.

The fix is specificity. “Pull publications from the last three years in journals with an impact factor above 3, filtered for relevance to [specific topic], ranked by citation count” is a better instruction than “pull recent publications.” More work to write. Significantly better output.

What an audit trail actually looks like

In regulated environments, you need to be able to show what happened and why. This is not a new requirement — it’s the same requirement you have for any process that contributes to a regulated output. What changes with agents is that you need to capture it deliberately, because the agent won’t do it automatically.

Most no-code platforms log agent runs. Make sure logging is turned on, that logs are retained for an appropriate period, and that you can export them if needed. For anything touching regulatory submissions, consider whether your audit trail needs to be stored in a validated system.

The question to ask of any agent you build: if something went wrong and you had to show exactly what happened, could you?

Building for graceful failure

The best agent designs assume things will go wrong and plan for it. This means: explicit checkpoints where a human reviews before the agent proceeds. Clear handling for situations the agent wasn’t designed for — not “do your best” but “stop and flag for human review.” Output that makes it easy for a human to spot problems rather than hiding them in well-formatted prose.

The goal is not an agent that never fails. That doesn’t exist. The goal is an agent that fails in a way you can catch.

The thing worth remembering

Agents make certain kinds of mistakes that humans don’t, and humans make certain kinds of mistakes that agents don’t. A well-designed human-agent workflow is not about replacing human oversight. It’s about applying human oversight where it adds the most value, and removing it from the places where it doesn’t.

Agents are good at consistency. They will do the same thing the same way every time, at any hour, without getting tired or distracted. What they cannot do is tell you whether the thing they are doing consistently is the right thing. That call belongs to someone who understands the work — and it always will.

That’s the series. Six posts, from first principles to a working build and the honest accounting of what can go wrong. If you’ve followed along and built something — or tried to and got stuck — I’d like to hear about it.

This is the final post in Building with agents. The next series picks up from here: more complex builds, real-world examples, and what the commercial landscape looks like for those thinking about this seriously.

— Ned

This is the payoff post. We build the thing.

Last week we mapped the advisory board preparation workflow in full — four phases, eight steps, and a set of review gates that no agent can bypass. The key point was this: the agent moves work to the gate. A human opens it.

Today we build the agent that does the moving.

If you’ve been following along, you know the hard part is not the technology. It is the specification. You need to know your workflow well enough to write it down. If you’ve done that work, this post is the translation layer. If you haven’t, work through the workflow in last week’s post first — then come back.

What we’re building

An agent that takes a meeting brief and drives preparation through all four phases: from objectives to faculty, through the content documents, to a complete board pack ready for LMR.

Human involvement sits at the gates: agency review at the end of each phase, client concept review after Phase 2, and LMR at the end. Everything between the gates runs automatically.

The tool: n8n. MindStudio handles most of this too. The choice of tool matters less than the quality of your specification at each step.

What these prompts are — and where they go

Before we go step by step, this needs to be clear.

An agent built in n8n is a sequence of nodes — individual steps that run in order. Some nodes handle logic (route this if the flag is X, pause and wait for approval, send an email). Others handle content — they take an input, pass it to an AI model, and return an output.

The nodes that involve AI have a prompt field. That is where you tell the AI what to do: what it is receiving, what it must produce, and what rules it must follow. You write that prompt once, when you are setting up the workflow. After that, it runs automatically, every time the workflow runs, without you touching it.

The prompts in this article go into those prompt fields. You are not typing them into Cowork. You paste them into the relevant AI node in n8n or Zapier, replace the placeholders with your specifics, and the workflow handles the rest.

Each prompt has three parts: INPUT (what the agent is receiving at this step), OUTPUT (exactly what it must produce, in what format), and RULES (the constraints — including what to do when something is missing or wrong). The RULES section is the most important part. Without explicit rules, the agent will produce output that looks correct but isn’t.

The build, phase by phase

Phase 1: Strategic foundation

Step 1 — Objectives draft.

The agent receives the meeting brief and produces a structured objectives statement — the document that everything else in the preparation is built on. If the objectives are wrong, the agenda is wrong, the slides are wrong, and the discussion guide is wrong.

This prompt goes into the AI node that processes the meeting brief. The node receives the brief as its input and returns the objectives statement as its output, which then feeds automatically to the next step

What to adapt: the output structure. The template gives you four sections — adjust the number of secondary objectives and key questions to match the scope of your meeting.

Step 2 — Faculty search.

With objectives confirmed, the agent queries your faculty database or runs a structured search for candidates matching the defined criteria. It returns a ranked shortlist with a confidence rating per candidate — not just names.

This prompt goes into the AI node that receives the confirmed objectives and returns the shortlist. What to adapt: the criteria section. Replace the [INSERT] placeholders with your therapeutic area, geography, and seniority requirements before the workflow runs.

[INSERT PROMPT 2 PNG HERE]

Gate: agency review and sign-off on objectives and faculty list before Phase 2 begins.

Phase 2: Content development

This is the phase that requires your most careful prompt writing. The agent is producing the documents your client is paying for. The quality of the output depends entirely on the quality of the instructions you give it.

Step 3 — Agenda draft.

The agent takes the confirmed objectives and builds the agenda: each item mapped to an objective, with time allocations and the type of contribution required from faculty. The prompt enforces a hard rule — no agenda item without a mapped objective. The agent does not get to include items because they seem relevant.

This prompt goes into the AI node that takes the objectives as its input and returns a structured agenda.

What to adapt: Rule 2 sets the discussion-to-presentation ratio at 60:40. Adjust this to match your client’s expectations — but do not remove the rule entirely. Without it, the agent defaults to presentation-heavy agendas.

Step 4 — Slide content draft.

The agent takes the agenda and your data package and drafts the scientific presentation. This is the highest-stakes step in the workflow. A vague instruction here produces output that looks plausible but makes claims the data does not support.

This prompt goes into the AI node that takes the agenda and attached data package as its input and returns a structured slide outline. Every factual claim is flagged [CHECK] for medical review — this is not optional.

What to adapt: Rule 5 uses [CHECK] as the flag for every factual claim. Some teams use a different tag. Whatever you choose, the per-claim flagging stays — a single disclaimer at the end of the deck is not the same thing.

Step 5 — Discussion guide draft.

The agent works through each agenda item and drafts the questions, probes, and expected outputs for each session. A discussion guide without a defined output produces a meeting without usable results. Rule 4 in this prompt forces the agent to flag undefined outputs rather than invent them.

This prompt goes into the AI node that takes the approved agenda as its input and returns the discussion guide.

What to adapt: the facilitator context section. This is internal — it can carry strategic information not shared with faculty. Make sure your n8n workflow keeps the discussion guide in the internal-only distribution, not the faculty pack.

Gate: agency review of all three documents internally, then client concept review. Phase 3 does not start until concept approval is in.

Phase 3: Faculty preparation

Step 6 — Conflict of interest checks.

The agent compares each confirmed faculty member’s affiliations against your conflicts register. It flags — it does not clear. The final rule in this prompt is absolute: the agent produces a report for a human reviewer, not a decision. The workflow pauses here until a named reviewer confirms clearance.

This prompt goes into the AI node that receives the faculty list and COI register and returns a structured flags report.

What to adapt: the threshold criteria in the RULES section. The template uses a standard three-year lookback for speaker fees. Adjust this to match your organisation’s policy — and get sign-off from your compliance team on whatever you set.

Step 7 — Briefing pack generation.

With COI checks cleared and concept documents approved, the agent compiles individual briefing packs — one per faculty member, tailored to that person’s role in the meeting. Rules 1 and 2 are non-negotiable: approved text is reproduced exactly. The agent does not get to improve the objectives or tighten the agenda.

This prompt goes into the AI node that loops through each confirmed faculty member and produces a briefing pack for each one, using the approved content as its source material.

What to adapt: Section 1, the welcome. The template is deliberately generic — replace it with your organisation’s preferred tone and salutation.

Gate: agency review of COI clearances and briefing packs.

Phase 4: Assembly and approval

Step 8 — Board pack assembly.

The agent pulls all approved components together into the final board pack in the correct order. This is the most straightforward step technically, but the prompt still matters: you need to tell the agent what goes in, in what order, and — critically — what happens if something is missing. Rule 4 makes the agent a hard stop if any component has not been approved. It does not assemble a partial pack and flag it later. It stops and waits.

This prompt goes into the AI node that receives all the approved documents and returns the assembled pack structure with a component checklist.

What to adapt: the component order in the OUTPUT section. Adjust the sequence to match your standard pack format.

Gate: agency final check, then client LMR review, then distribution.

What the finished workflow looks like

You drop a meeting brief into the system on Monday. By Tuesday the agent has drafted objectives, searched for faculty candidates, and is waiting at the first gate. You review, confirm, and release. By Wednesday the agenda, slides, and discussion guide are drafted and waiting for your review. You work through them, send them to the client, and wait for concept approval. Once that’s in, the agent runs the COI checks, builds the briefing packs, and assembles the final pack. It lands in your shared drive, ready for LMR.

Your time in this process: reviewing at each gate, editing the content documents, and approving before it moves on. The agent handles everything between the gates.

The one thing that will break this

Vague prompts. Every step where the agent is drafting — objectives, agenda, slides, discussion guide, briefing packs, assembly — lives or dies on the clarity of your instructions. Tell the agent what the output looks like. Tell it what to do when information is missing. Tell it what variation is not acceptable. The more specific you are, the less time you spend fixing the output at each gate.

This is why the specification work in last week’s post comes first. You cannot write a good prompt for a step you have not thought through.

Next: what goes wrong — and how to build an agent that fails gracefully rather than confidently incorrectly.

Building with agents is a practical series on agentic AI in health communications. New post every week.

— Ned

Last week’s agent did one thing. It searched, filtered, summarised, and sent. Most real work doesn’t look like that. It looks like a series of steps where the output of each one feeds the next — and where nothing moves forward until a human has reviewed what the previous step produced.

This week we build a multi-step workflow agent. The example is advisory board preparation.

What advisory board preparation actually involves

Advisory board preparation runs in four phases. The figure below shows them. Read it before continuing — the rest of this post is built around it.

Phase one: strategic foundation. The work starts with meeting objectives — what decisions need to be made, what clinical or scientific input is required, what the board is actually for. The objectives drive everything that follows: the faculty you need, the agenda structure, the questions you ask. An agent can draft the objectives from a brief and search databases for faculty candidates. Neither output moves forward until the agency has reviewed and confirmed both.

Phase two: content development. Three documents, each dependent on the previous: the agenda, structured to deliver the objectives; the slide content, developed against the agenda; and the discussion guide, which sets out the questions, probes, and expected outputs for each session. An agent can produce first drafts of all three. They go to agency review first, then to a structured client concept review. Nothing in Phase 3 starts until that approval is in.

Phase three: faculty preparation. With approved content, faculty preparation can begin. Conflict of interest checks are run — the agent flags potential conflicts, a human reviews and clears them. Briefing packs are compiled for each faculty member: their role in the meeting, the agenda, pre-read material, background on the data they will be discussing. These go through agency review before going to the client.

Phase four: assembly and approval. The agent assembles the full board pack — agenda, slides, discussion guide, faculty bios, pre-read. It goes through a final agency check, then to LMR. Distribution happens only once LMR approval is in.

What the agent is actually doing

The agent never decides that something is ready — it produces output and presents it at a gate. A human opens the gate or sends it back.

The agent handles assembly, searching, drafting, formatting, sequencing. The humans handle judgement — is this right, does this reflect what the client actually needs, is this ready to go further.

The agent’s value is not that it replaces any of those human reviews. It is that it eliminates the time between them. Instead of a document sitting in someone’s drafts folder waiting to be started, it arrives at the review gate ready to be assessed. The bottleneck shifts from creation to decision — which is where it should be.

Before you build this: the specification question

The technology for this build is the same as last week. The hard work is not the setup. It is the specification.

Before you open the tool, you need clear answers for each phase. What does a well-formed objectives statement look like? What is the agenda template? What structure does the discussion guide follow, and who has authority to approve the questions? What counts as a conflict of interest, and who clears it? What goes into a briefing pack, and in what order?

You also need to define the gates: who reviews at each stage, what approval looks like, and what happens when something comes back with changes. An agent that does not know what a rejection looks like cannot handle one gracefully.

Get the specification right and the build is mostly plumbing. Get it wrong and you will spend more time fixing the agent than you would have spent preparing the board manually.

Next week: the full build. Step by step, tool by tool, prompt by prompt.

Building with agents is a practical series on agentic AI in health communications. New post every week.

— Ned

Legend: dark boxes = human judgment required; green boxes = agent-ready steps that follow explicit rules.

Time to stop theorising and open something.

The question I get most often at this point in the conversation is: “Do I need a developer?”

For some things, yes. For your first agent, probably not. The no-code tools have got genuinely good over the past 18 months, and the gap between “I want to build something” and “I have built something” is smaller than most people think.

Here is an honest map of the landscape.

Three tools worth knowing

Zapier AI Agents is the easiest starting point if you already use Zapier for anything. You describe what you want the agent to do, connect it to your existing apps, and the platform handles the wiring. It’s not the most powerful option but the learning curve is shallow enough that you can have something running in an afternoon. Good for: simple trigger-and-action workflows, anything involving email or calendar.

n8n is more powerful and, crucially, self-hostable — which matters in health communications where data governance is not a nice-to-have. It uses a visual workflow builder where you connect nodes together, each node being a step in your process. It has a steeper learning curve than Zapier but gives you significantly more control. Good for: multi-step workflows, anything requiring custom logic, any situation where your data cannot touch a third-party server.

MindStudio sits somewhere between the two. It’s designed specifically for building AI-powered workflows and apps, with a clean interface and enough flexibility for moderately complex builds. Good for: teams that want to build agents without a developer but need more than Zapier can offer.

All three have free tiers that are sufficient for building and testing. None of them require you to write code, though knowing a little doesn’t hurt.

Let’s build something

Rather than describe an agent in the abstract, let’s make one. We’re going to build a literature surveillance agent — something that searches PubMed on a schedule, filters for relevant papers, and sends you a weekly summary.

This is a good first build because it’s immediately useful, the logic is simple, and it proves the concept without requiring you to hand any sensitive data to a system you don’t yet trust.

The agent runs every Monday morning. It searches PubMed using a set of terms you define — therapy area, drug name, relevant MeSH headings. It filters the results: anything published in the last 7 days, in journals on your watch list, matching your keywords. It takes the abstracts from the filtered results and asks an AI model to write a short summary of each one — what it found, why it might matter. It sends those summaries to you in a single email.

That’s it. No developer. Setup time: a few hours the first time, less once you know the tools.

To set it up, you need: a Zapier or n8n account, a PubMed API key (free, takes five minutes to get from the NCBI website), an email address to send the output to, and a clear list of your search terms — this is actually the hard bit, not the technical part.

The thing that surprises people

The hardest part of building an agent is not the technology. It is the specification.

To build this literature alert, you need to know exactly what you’re looking for. Which journals matter? Which terms are signal versus noise? What makes a paper worth reading versus worth skipping? How do you want the summary formatted?

These are not technical questions. They are subject-matter questions. And the quality of your answers determines the quality of the agent.

This pattern repeats across every agent you will ever build. The technology executes. The professional decides what good looks like.

Next week we go deeper: a multi-step workflow agent for advisory board preparation, and how to connect the pieces when the logic gets more complex.

Building with agents is a practical series on agentic AI in health communications. New post every week.

— Ned

Last week I asked you to write down a workflow. If you did it, well done — you are in a small minority. If you didn’t, no judgement. We’ll assume you did it in your head.

Either way, you should now have a sequence of steps in mind. Something that starts with a trigger — a brief, a request, a deadline — and ends with an output. Between those two points: a series of actions, most of which follow rules, performed mostly by humans, some of whom are doing work that is considerably below their pay grade.

Now. What if some of those steps just... happened?

The thing everyone gets wrong about AI agents

Most people, when they hear “AI agent,” picture something from a film. A glowing interface. A voice saying “Processing.” Something that feels vaguely like it might become sentient if you leave it running too long.

The reality is considerably less cinematic.

An AI agent is just a system that receives a goal and works through the steps to achieve it — using tools, checking its own outputs, and stopping when it’s done (or when it genuinely needs a human to make a call it can’t). That’s it. No glowing interface required.

The key word is goal, not task. This is what separates an agent from the AI you’ve been using in generation one.

When you open ChatGPT or Claude and type a prompt, you are giving it a task: “write this,” “summarise that,” “help me with this sentence.” The AI does the task and stops. It waits for you to give it the next one. You are the system. You are doing the sequencing, the decision-making, the “what comes next.”

An agent receives a goal — “prepare the faculty briefing packs for the November advisory board” — and figures out the steps itself. It searches for the relevant publications. It pulls the speaker bios. It checks for conflicts of interest against a list you’ve provided. It drafts the packs in your template. It flags anything it couldn’t resolve. Then it stops and waits for you to review.

You stepped out of the loop for the middle bit.

Back to your workflow

Remember the diagram from last week? The dark boxes — brief, research, first draft, internal review — still have humans in them. They require judgement. They require context. They require someone who knows the client, knows the therapy area, knows what the room needs to hear.

The green boxes are different. Claims checking is structured and verifiable — a claim is either accurate or it isn’t. Reference verification is binary correctness against a known source. MLR submission is document preparation with defined inputs and outputs.

These are the steps an agent can run. Not because they’re unimportant — they’re critical — but because their rules are explicit enough to be handed over.

The agent doesn’t replace the humans at the dark steps. It clears the path so those humans can spend their time on the work that actually needs them.

One thing to hold onto

An agent is not magic. It is not going to understand nuance you haven’t given it. It is not going to catch something it wasn’t told to look for. It will do exactly what you’ve designed it to do — which means the quality of the design is everything.

This is good news for people who understand the work. Building a good agent requires knowing the workflow intimately — the rules, the edge cases, the moments that require a human call. That knowledge doesn’t become less valuable when agents arrive. It becomes the thing you build with.

Next week: the actual tools. What they are, what they cost, and how to set up your first one without needing a developer.

Building with agents is a practical series on agentic AI in health communications. We start from first principles and build toward a working advisory board agent. No hype. Just the stuff that works.

— Ned

This is the first in a series on building with agents in health communications. Before we can give an agent anything to do, we need to be clear about what we're actually handing over. That means mapping the workflow first. Everything else follows from this.

You already know what a workflow is. You just don’t call it that.

You call it “the process.” Or “how we do things here.” Or, ask Trevor”. Whatever name you’ve given it, you have one. Everyone in health communications has one. Usually several, none of which are fully documented, at least one of which runs through a single person who is the only one who understands a particular system and who is probably thinking about leaving.

A workflow, stripped of any jargon, is just this: a sequence of steps that turns an input into an output. A brief becomes a slide deck. A data package becomes a manuscript. A request from medical becomes a piece of content that has to pass through legal, regulatory, and the strong opinions of three senior stakeholders before it sees daylight.

Each step has someone responsible for it. Each step is triggered by what came before and produces something that feeds what comes next. And — here is the part that matters — most of those steps follow rules. Defined, repeatable, could-in-theory-be-written-down rules.

This is good news. We will come back to this.

Let’s make it concrete.

Take a piece of content through its typical life in health communications. Roughly, it goes like this:

Someone writes a brief. Someone else receives it, does the background research, and writes a first draft. That draft goes to an internal reviewer — probably someone senior who has opinions about your word choices and, separately, the Oxford comma. It comes back with comments. It goes to claims checking. The claims are checked against the references. The references are verified. The whole thing goes to MLR. MLR sends it back with eighteen comments, six of which are about the Oxford comma. It goes back. Eventually it is approved. It exists in the world.

That is a workflow. A dozen or so distinct steps, each with a clear input and output, most of which follow rules that could — in principle — be written down and handed to someone who had never touched this piece of content before.

Why this matters.

Here is the insight that makes the rest of this series worth reading.

The more a step follows rules, the more it can be delegated.

This is not a new idea. It is why we have templates, and style guides, and standard operating procedures. It is why junior colleagues handle certain steps while senior people handle others. Delegation has always followed the logic of: this step is rule-governed enough that I don’t need to be the one doing it.

What’s new is who — or what — you can delegate to.

An AI agent is something that can execute rule-governed steps in a workflow without a human doing each one manually. Not all steps. Not the ones that require judgement, context, or the ability to read the room. But the ones with clear inputs, clear outputs, and clear rules? Those are exactly what agents are built for.

Before we get to any of that, though, we need to be clear about what your workflow actually looks like. Not the version in the slide deck that was last updated in 2021. The real one — with the bottlenecks, the workarounds, the step that always stalls because it depends on one person who is always in a different meeting.

Your homework. Yes, really.

Pick one workflow you touch regularly. It doesn’t have to be the big one. Something you do often enough that the steps feel almost automatic.

Write it down. Every step. Who does it, what triggers it, what comes out of it. Don’t tidy it up — write down the actual version, not the aspirational one. Especially the bits that feel embarrassing to write down.

We’ll use it next week.

Next: what an agent actually is — and how it fits into the workflow you just mapped.

— Ned