Meeting Prep With an AI Agent: Context Before Every Call
You have a call in nine minutes. You half-remember the person's name, you definitely do not remember what you promised them last time, and the context you need is split across four tools: the email thread from three weeks ago, the CRM record someone else updated, the task you filed and forgot, and the notes doc from the previous call. So you spend eight of those nine minutes tab-hopping, and you walk in with a partial picture anyway.
Meeting prep is one of the best first use cases for an autonomous AI agent because the work is pure information gathering. It is read-heavy, it repeats every day, the inputs live in systems that already have APIs, and the output is a document. Nothing gets sent, nothing gets modified, nobody is at risk if the agent has a bad morning. It either saves you fifteen minutes of tab-hopping or it does not, and you can check its work against your own inbox.
This article walks through what a meeting prep agent actually does, step by step, how to build one on Skopx by describing it in chat, and where the honest limits are.
What a meeting prep agent actually does
Strip away the framing and the job is a pipeline with five stages:
- Read the calendar. Pull today's (or tomorrow's) events from Google Calendar or Outlook. Filter out the noise: focus blocks, all-day reminders, internal standups you do not need a dossier for.
- Identify the people. For each remaining event, extract attendee email addresses and resolve them: which company, which CRM contact or deal, have we met before.
- Gather recent context. Search Gmail or Outlook for recent threads with those attendees. Pull the CRM record from HubSpot or Salesforce: deal stage, last activity, notes. Check the project tracker (Linear, Jira, Asana, Trello) for open items tagged to that account or person.
- Find open loops. The most valuable part: unanswered emails, commitments made in the last thread ("I'll send the revised proposal by Friday"), tasks that were due before the meeting, anything the other side asked for that nobody delivered.
- Write the brief. One page per meeting: who, why, what happened recently, what is open, and two or three suggested talking points. Delivered as a document you can skim in ninety seconds.
None of these stages is exotic. Any assistant with tool access can do each one on demand. What makes it an agent, in the sense covered in what is an autonomous AI agent, is that the whole pipeline runs on a trigger without you asking, adapts when a stage returns something unexpected (an attendee with no CRM record, an empty inbox history), and produces a report you can audit afterward.
Why a schedule beats asking on demand
You could open a chat every morning and type "prep me for today's meetings." That works, and it is a fine way to prototype the instructions. But it fails exactly when you need it most: the mornings you are too rushed to remember to ask are the mornings you most need the brief.
A scheduled trigger removes you from the loop. On Skopx, an agent's trigger can be manual ("runs when you ask"), a schedule like "Every weekday at 6:30 UTC", or a webhook. For meeting prep, the schedule is the natural fit: run early enough that the brief is waiting before your first call, late enough that overnight calendar changes are captured. If your calendar shifts a lot during the day, you can also keep a manual trigger alongside your own habit: run the same agent by asking, right before an unexpected call. The mechanics of choosing between these are covered in scheduled AI agents and the broader AI agent triggers guide.
There is a subtler reason the scheduled version wins: memory. A meeting prep agent that runs daily builds up state between runs. On Skopx, agent memory persists cursors and baselines between runs, so the second run does not re-derive everything from scratch. Concretely: the agent can remember which threads it already summarized, what it reported yesterday, and which meetings recur weekly, so today's brief can say "no change since last Tuesday's call except one new email" instead of re-narrating the whole account history. Delta reports are shorter, easier to skim, and typically cheaper to produce. How that mechanism works generally is the subject of AI agent memory explained.
Building it on Skopx: the chat-assembled agent
On Skopx you build the agent by describing it in the Create Agent chat. No code, no drag-and-drop canvas. You say what you want, the chat assembles the agent, and the workspace shows it beside every other agent you own. A realistic first description, as an example:
"Every weekday at 6:30 UTC, look at my Google Calendar for the day. For each external meeting, search Gmail for recent threads with the attendees, pull the matching HubSpot contact and deal, and check Linear for open issues tagged with that account. Write me one brief per meeting: who they are, deal status, what we discussed last, anything we owe them, and 2-3 talking points. Skip internal meetings and focus blocks."
From that description the agent gets its anatomy:
- Instructions in plain language, which you can edit and which stay versioned as you refine them. The difference between a mediocre brief and a genuinely useful one is almost entirely in the instructions: what counts as "external", what counts as an "open loop", how long each brief should be. See AI agent instructions guide for patterns.
- A trigger: the weekday 6:30 UTC schedule.
- Grants per integration toolkit: Google Calendar, Gmail, HubSpot, Linear. Each grant has a tier: runs automatically, asks first every time, or the agent decides when to ask. A prep agent is read-only, so "runs automatically" for reads is the sensible default, and reads flow without approval even under the approval-required tier.
- Budgets: tokens per run, tokens per day, a max step count, and a minute cap. A prep agent touching four tools across six meetings can rack up steps, so a sane step ceiling keeps a confused run from wandering. Three budget failures auto-pause the agent, which is the behavior you want: a prep agent that keeps blowing its budget has a problem worth looking at, not worth repeating.
- Success criteria the run report is evaluated against: for example, "every external meeting on today's calendar has a brief, and every brief lists open items or explicitly says there are none."
Every run then produces a step timeline with humanized labels and expandable raw results, a duration, a token count, and a markdown report rendered as a document. That report is your brief. If a brief ever looks wrong, you can open the run and see exactly which searches ran and what they returned, which is the transparency angle covered in AI agent run transparency.
What goes in a good one-page brief
The failure mode of automated prep is a wall of summarized everything. A brief you will not read is worth nothing. Aim the instructions at a strict structure, something like:
Per meeting:
- Header: meeting title, time, attendee names, company, and their roles if the CRM knows them.
- Relationship state: one or two lines. New prospect, active deal at stage X, existing customer, or first-ever conversation with no history found. Honesty matters here: "no prior contact found in Gmail or HubSpot" is a useful sentence, and the instructions should require the agent to say it rather than pad.
- Recent activity: the last 2-3 meaningful exchanges, dated. Not a summary of every thread ever.
- Open loops: the section that pays for the whole agent. Things you owe them, things they owe you, questions asked and never answered, tasks past due. Instruct the agent to quote or link the source so you can verify in one click.
- Suggested talking points: two or three, grounded in the open loops, not generic ("build rapport" is banned).
Cap each brief at roughly a page. Tell the agent that explicitly, because models pad by default and a length constraint in the instructions is the cheapest fix.
Where the context comes from: the integration map
The agent is only as good as the systems it can read. Skopx agents draw on nearly 1,000 Composio-backed integrations, plus web search, web fetch, browser tools, and read-only SQL against connected databases like Postgres and MongoDB. For meeting prep, the useful clusters:
| Source | What it contributes to the brief | Typical tools |
|---|---|---|
| Calendar | The meeting list, attendees, timing, agenda text | Google Calendar, Outlook |
| Recent threads, unanswered messages, commitments in writing | Gmail, Outlook | |
| CRM | Company, deal stage, contact history, account owner notes | HubSpot, Salesforce |
| Project tracker | Open tasks and issues tied to the account | Linear, Jira, Asana, Trello, ClickUp |
| Docs and notes | Prior call notes, proposals, shared plans | Notion, Google Drive |
| Chat | Internal discussion about the account | Slack, Discord |
| Payments and orders | Billing state, subscription, recent invoices | Stripe, Shopify |
| Public web | News about the company, the person's recent posts | Web search, web fetch |
| Your own database | Product usage for that account, read-only via SQL | Postgres, MongoDB |
You do not need all of these on day one. Calendar plus email alone already produces a brief better than most people's actual prep. Add the CRM in week two, the tracker in week three. For a wider look at what agents can reach, see AI agent tools and integrations, and for the calendar-specific mechanics, AI agent for Google Calendar.
The public-web column deserves a caveat. Searching for "recent news about Acme Corp" is genuinely useful before a sales call and genuinely noisy for a common company name. Constrain it in the instructions: only search the web for external meetings, only include results the agent can date to the last 30 days, and skip the section entirely rather than including filler.
Keeping it safe: read-only by design, approvals if it ever writes
A meeting prep agent should not need to write anything to your tools, and that is exactly why it is a good first agent. Grant read access, let reads run automatically, and the worst realistic outcome is a mediocre document.
The moment you extend it, the calculus changes. Two popular extensions:
- Drop the brief into Slack so it is waiting in a DM instead of a run report. Posting a message is a write. On Skopx you can set that toolkit's grant to "asks first every time", or use drafts-only mode while you tune the format.
- Block prep time on the calendar before big meetings. Creating events is a write with real consequences for other people's calendars.
Skopx's approval model is precise about what approval means: a write-shaped action parks as a pending approval showing the exact call and arguments. Approving executes exactly that parked call, once. Rejecting executes nothing. Approvals can expire, which matters for time-sensitive things like a morning Slack post: an approval you grant at noon should not fire a "before your 9am call" message. The full pattern is covered in AI agents with human approval.
And because every agent has a kill switch, pausing the agent stops queued runs, and a run in flight can be stopped mid-run. You are never committed to letting a bad run finish.
A concrete morning, walked through
An example, clearly hypothetical, to make the mechanics tangible. Suppose your Tuesday has four events: a 9:30 internal standup, a 10:00 call with a prospect named Dana at Riverbend Logistics, a 13:00 renewal call with an existing customer, and a 15:00 focus block.
At 6:30 UTC the agent runs. The step timeline would read something like:
- Fetched today's events from Google Calendar (4 found).
- Filtered to external meetings (2 remain: standup and focus block skipped per instructions).
- Searched Gmail for threads with dana@riverbend example address (3 threads, last activity 12 days ago).
- Pulled HubSpot contact and deal for Riverbend (deal stage: proposal sent).
- Checked memory: last brief for Riverbend was 12 days ago; noted proposal was promised "by end of week" in that thread.
- Flagged open loop: proposal thread has no reply from our side after their pricing question.
- Repeated 3-6 for the 13:00 renewal call.
- Wrote report: two briefs, one page each.
The Riverbend brief surfaces the thing you would have missed: Dana asked a pricing question eleven days ago and nobody answered. You now walk into the 10:00 call leading with the apology and the answer instead of discovering the gap live. That single catch is the product. It is also exactly Skopx's positioning: the platform exists to catch what falls between your tools, and an unanswered pricing question sitting between Gmail and HubSpot is the canonical example.
The second Tuesday, memory makes the run cheaper and the brief sharper: "Riverbend: no new email since your call on the 10th. Your notes said you owed them a revised SOW. No SOW found in Drive or the thread." Deltas, not re-narration.
Honest limits: what this agent will not do
Candor section, because the gap between the pitch and the reality is where trust dies.
- It cannot read what is not written down. If the real state of the deal lives in a hallway conversation or an unlogged phone call, the brief will be confidently incomplete. The agent reports what the systems know. Garbage in, gaps out.
- Entity resolution is imperfect. Matching an attendee email to the right CRM record is easy when emails match, and fragile when someone accepts from a personal address or the CRM has duplicates. Expect occasional "no record found" for people you definitely know, and instruct the agent to say so rather than guess.
- Open-loop detection is inference, not fact. "I'll send it by Friday" is easy to catch. A commitment implied across three messages is not, and the agent will sometimes miss those or flag non-commitments. Treat the open-loops section as a strong first pass, not a contract audit.
- It summarizes; it does not strategize. The brief tells you the deal is stalled at proposal stage with an unanswered pricing question. It does not know your discounting authority or the relationship subtext. Talking points are prompts, not a script.
- Web enrichment is the noisiest input. Keep it constrained or drop it. A wrong "recent news" item in a brief costs more credibility than the right one adds.
- It costs tokens every day. A daily multi-tool run is not free. Budgets and delta-style memory keep it proportionate, and the per-run token count on every report tells you exactly what you are paying in usage. If your calendar is two internal meetings a day, you may not need this agent at all, and it is fine to say so.
The right posture for the first two weeks is trust-but-verify: read the brief, then spot-check one meeting against your own inbox. The run's step timeline makes that audit fast. Once the agent has earned trust, the audits become occasional.
Iterating: from tolerated to indispensable
The first version of the brief will be too long, too generic, or both. That is normal and fixable, because the instructions are plain language, editable, and versioned. The tuning loop that works:
- Run it manually a few times before trusting the schedule. Trigger it by asking, on a day whose context you know well, and grade the output. This is the general pattern from testing AI agents safely.
- Tighten definitions. "External meeting" needs a definition (any attendee outside your domain?). So does "recent" (30 days? 90?). Vague terms in, vague briefs out.
- Ban filler explicitly. "If there is no meaningful history, say 'no prior contact found' in one line and stop" is one of the highest-leverage sentences you can add.
- Use success criteria as your quality bar. "Every brief cites at least one dated source or states that none exists" turns the run report into a self-check instead of a vibe.
- Watch the token count trend. If runs get more expensive over time, memory is not being used well or the instructions are inviting over-searching.
Most teams get to a brief they actually read within a handful of instruction edits. The versioning means a bad edit is reversible, and the append-only run history means you can compare this week's briefs to last week's directly.
FAQ
How is this different from just reading my calendar and inbox myself?
Mechanically, nothing the agent does is beyond you. The difference is that it does all of it, every morning, across every tool, before you wake up, and it never skips the CRM check because it was busy. The compounding value is consistency: the one meeting per week where prep would have caught something is the meeting you would have skipped prepping for.
Does the agent need write access to any of my tools?
No. The core meeting prep pipeline is entirely read-shaped: calendar, email, CRM, and tracker reads plus a written report. On Skopx, reads flow without approval even under the strictest grant tier. You only need write grants if you extend it, for example posting the brief to Slack, and those writes can be gated behind per-action approval or drafts-only mode.
What happens if the agent misidentifies someone or gets the context wrong?
The brief will be wrong for that meeting, and the run timeline will show you why: you can expand each step and see the exact searches and raw results. Common causes are personal email addresses that do not match CRM records and duplicate contacts. The mitigation is instructing the agent to state uncertainty ("no confident match found") instead of guessing, and to cite dated sources so you can verify claims in one click.
How far in advance should it run?
Early enough to be waiting before your first meeting, late enough to capture overnight calendar changes. For most people that is a daily run 1-3 hours before the workday starts. If your calendar churns during the day, keep the same agent runnable on demand and trigger it manually before late-added calls. Some people run it the evening before instead, trading freshness for the ability to prep the night before big meetings.
Which model should the meeting prep agent use?
On Skopx you pick the model per agent, across Claude, GPT, Gemini, Kimi, and more, either with your own keys at zero markup or on the $16/seat Team plan with included tokens. Prep is a summarization-and-judgment task, so a strong general model earns its keep in the open-loops section, where the work is inference rather than retrieval. It is reasonable to start with a top-tier model, confirm the brief format is right, then test whether a cheaper model holds the quality bar for your daily run.
Can one agent prep meetings for a whole team?
You can, but per-person agents usually work better. The brief depends on whose inbox and whose commitments are being examined, and a shared agent either needs access to everyone's mail or produces briefs missing the personal context that makes them useful. The pattern that scales is each person running their own copy of the same instructions, which the versioned, plain-language instruction format makes cheap to share.
Start with tomorrow's calendar
Meeting prep is the rare automation with a clean trial: build the agent, run it manually against tomorrow's real calendar, and compare its brief to what you would have assembled yourself. It is read-only, so the trial risks nothing, and the run report shows its work, so grading it takes minutes. If the brief catches one open loop you had lost track of, you have your answer.
You can describe the first version in a few sentences at skopx.com/agents, grant it your calendar and inbox, and have a brief waiting before your first call tomorrow.
Skopx Team
The Skopx engineering and product team