Blueprint: a meeting prep agent that briefs you before every call

A blueprint is the shape of a system: what the pieces are, how data moves between them, where it breaks, and what it costs to keep running. This one covers a meeting prep agent, an agent that wakes up before your day starts and hands you a one-page brief on every external call you’re about to take.

We built this one. It worked. Then it quietly died, for a reason that had nothing to do with the technology, and that part is at the bottom because it’s the most useful section here.

The problem it solves

Everyone knows they should prep. The brief that matters is fifteen minutes of digging: who is this person, what does their company do, when did we last talk, what did we promise, what changed since. Fifteen minutes times six calls a day is a habit nobody sustains, so people wing it and the call goes about as well as winging it goes.

The work is real, valuable, and boring. That’s the entire profile of a job worth handing to a machine.

Why this is the first chain worth building

The time it gives back is measurable before you build anything.

The average seller spends 40 % of the day actually selling and 19 % of it updating the CRM, roughly one hour in five.

Salesforce, State of Sales 2026. Pre-call research sits in the other 60 %, and unlike CRM entry it has no owner and no field to be late on, so it is the task that silently gets skipped when the week is full.

That is what makes meeting prep a good first chain rather than an obvious one: it is high-frequency, it has a clear “done” state, and nobody defends it as craft. It also needs no new software, which matters more than it sounds, 95 % of enterprise AI pilots produce no measurable result, and the MIT researchers behind that figure put the cause in the approach rather than in the models.

The system at a glance

Six components. Each does one thing and passes structured data to the next.

Component	Job	Typical tool
Scheduler	Fires once, early, on workdays	n8n cron trigger
Calendar reader	Pulls today’s events, filters to external	Google Calendar / Outlook
Attendee resolver	Turns email addresses into people and companies	Domain parsing + enrichment
Context gatherer	Pulls CRM history, past notes, recent signals	HubSpot, meeting notes, web
Brief writer	Turns messy context into one readable page	LLM with a fixed template
Delivery	Puts the brief where the human will actually see it	The hard part. See below.

The chain runs once per day, not per meeting. Batching is cheaper, simpler to debug, and matches how people actually plan: they look at the day, not at the next hour.

The chain, step by step

1. Trigger

Cron at 06:30 local, weekdays. Early enough that the brief is waiting before anyone opens a laptop, late enough that last-minute calendar changes from the night before are included.

One design note: fire per-person, not per-company. Each user gets their own run against their own calendar, because the brief is only useful if it’s about your day.

2. Read the calendar

Pull today’s events between 00:00 and 23:59. Then filter hard, because most of the calendar isn’t worth a brief.

Drop anything with no external attendee. Drop internal recurring meetings, focus blocks, and anything you organised with only colleagues. What survives is external calls with actual outside humans in them, which is usually three to six events out of a fifteen-event day.

This filter is the difference between a useful morning artifact and a wall of text about your own standup.

3. Resolve who you’re meeting

For each external attendee you have an email address and often a display name. From the address you get the domain, and from the domain you get the company. That’s the reliable path.

The unreliable path is guessing a person’s role from their name or their company’s size from its domain. Don’t. Mark unknowns as unknown and let the brief say “role unknown” rather than inventing a plausible title.

A brief that is confidently wrong about someone’s job is worse than no brief, because you open the call by addressing them as something they are not.

4. Gather context

Three sources, in descending order of trustworthiness.

Your CRM. Deal stage, owner, last activity date, open items. This is the highest-value input by a wide margin, because it’s the thing you actually forgot: that you promised them a pricing breakdown eleven days ago.

Your own past notes. Transcripts or summaries from previous calls with this company. What did they push back on, what did they ask twice about.

Public signals. Recent company news, funding, hiring, product launches. Useful, but it’s the sprinkles. If your enrichment vendor is down, the brief should still ship without this section rather than fail.

Design each source to degrade gracefully. Any one of them being unavailable trims a section, never kills the run.

5. Write the brief

Fixed template, filled by a model. Not a freeform “write a brief” prompt, which produces a different structure every day and trains people to stop reading it.

The structure that survived contact with reality:

• Who, name, role if known, company in one line
• Where we stand, deal stage, last contact, who owns it
• Open from last time: what was promised, by whom, and whether it happened
• What changed, anything new on their side since you last spoke
• Three things to ask, generated, and explicitly labelled as suggestions

Two rules on the prompt. The model gets only the gathered context and may not add facts. And every section that has no data says so out loud, in a single line, rather than being padded with filler. “No prior contact on record” is genuinely useful information. A paragraph of invented rapport is not.

Keep it to one screen. The brief competes with the fifteen minutes before a call, and it loses that competition at 600 words.

6. Deliver it

Covered below, because this is where the whole thing lives or dies.

The three decisions that actually matter

Batch daily, not per meeting. Per-meeting triggers sound better and produce a stream of interruptions across the day. Nobody preps at 14:52 for a 15:00 call.

Fail soft, everywhere. If enrichment times out, ship the brief without that section. A system that goes silent on the days an API is flaky teaches people not to depend on it, and once they stop depending on it you’re paying to run something nobody opens.

Never invent a person. Every field is either grounded in a source or explicitly empty. This one is not a style preference. It’s what keeps the brief trustworthy enough to read at all, and trust here is binary.

Failure modes

What breaks	What you see	Fix
Calendar full of internal noise	Briefs on your own standup	Filter on external attendees before anything else runs
Attendee not in CRM	Empty brief, looks broken	Say “first contact on record” explicitly and keep the public-signal section
Enrichment API down	Whole run fails	Per-source try/catch, ship partial
Model pads empty sections	Brief reads plausible, is fiction	Ban additions in the prompt, test with a deliberately empty context
Brief arrives after the call	Technically correct, useless	Move the cron earlier, alert if the run exceeds its window

The one that killed ours

We built this. Calendar reader, resolver, enrichment, CRM pull, brief writer. Three workflows and a data table, all of it working.

It has zero executions.

Not because the briefs were bad. Because we never solved delivery. The brief landed somewhere that wasn’t part of anyone’s morning, and a brief you have to remember to go and look at is a brief you don’t read. Twice. Then never.

The technical system was around seventy percent done and the adoption system was at zero, and it turns out the second number is the one that decides whether a thing runs. We had built an artifact and skipped the question of where a human already looks at 08:00.

The fix is not more engineering. It’s picking the surface the person is already staring at and putting the brief inside it. For most teams that’s email, because everyone opens email, or it’s the calendar event itself, updating the description so the brief is sitting there when they click into the call. Slack works if the team genuinely lives in Slack. A dashboard is almost always the wrong answer, because a dashboard is a place you have to decide to go.

So the honest sequencing is backwards from how everyone builds it. Decide where the brief lands, confirm a person actually looks there at that hour, and only then build the thing that fills it.

What it costs to run

For one person with five external calls a day: model spend of a few euros a month, enrichment credits depending on your vendor, and whatever your n8n instance already costs. Call it under fifty euros a month for a small team.

Build time is a day or two for the chain. The real cost is the ongoing one, which is keeping the CRM clean enough that the context step has something true to pull. An agent reading a stale CRM writes confident briefs about deals that closed in March.

When not to build this

If your calendar is mostly internal, skip it. If your CRM is empty or badly maintained, fix that first, because this system is a magnifying glass pointed at your data quality and it will make bad data more visible and more embarrassing.

And if you can’t name the exact place the brief will appear and the exact moment someone will read it, don’t start. That was our mistake and it cost more than the build did.

If you want this built into the surface your team already opens in the morning, book a strategy call.

Frequently asked questions about meeting prep agents