A meeting brief from your mail, calendar and notes, in one request
How an agent builds a meeting brief from Gmail, Google Calendar and Notion through private connections, remembers your format, and never holds a token.
A meeting brief from one request means the agent reads tomorrow's calendar, pulls the email threads with each attendee, finds the related Notion pages, and writes a one-page summary. It does this through the Gmail, Google Calendar and Notion connectors, each a connection you made yourself, with memory holding how you like the brief laid out.
Every person, company and meeting in this post is a fictional example. The tool names are real.
Which connections does it need?
Three connectors, connected from Dashboard → Connectors. Your inbox and calendar are yours, so those two stay private: only you and your clients reach them. The Notion workspace can be private or shared with the organization.
| Connector | Connection | What the agent does with it |
|---|---|---|
| Google Calendar | private | Reads tomorrow's events and their attendees |
| Gmail | private | Reads recent threads with each attendee through gmail__search_emails |
| Notion | private or shared | Finds the account page, then writes the brief with notion__create_page |
The agent receives tools, never tokens. CoreSpeed stores each credential, refreshes it when the provider allows, and performs the action with the right account. If a credential stops working, the connection moves to needs_reauth: the tools stay visible, calls fail until you reauthorize in Dashboard → Connectors, and nothing else needs changing.
For Google apps, the vendor's review process gates a shared app, so your org admin may bring your own OAuth app: paste the client_id and client_secret once, and connections go through it. The connectors docs cover that route.
What does the request look like?
In Claude Code, with CoreSpeed added as the MCP server and signed in with your browser account, the request is one line: "Build my brief for tomorrow's 10:00 with Harbor Labs."
The agent reads the calendar event and finds two attendees. It calls gmail__search_emails for threads with each of them from the last month. It searches Notion for the Harbor Labs page and reads the last call notes. Then it writes the brief and creates a Notion page under your meetings database.
Harbor Labs, 2026-10-08 10:00
Who: two attendees, roles from the last thread
Last touch: 2026-09-24, they asked for a pilot timeline
Open items: pricing for 40 seats, data residency question
Suggested agenda: timeline, pricing, next stepAll of the reads go straight through. Reads are never gated by Smart Approval. Creating the Notion page is a write; on the Balanced default an ordinary write like this runs, unless a sentence in your policy names it.
How does memory shape the brief?
On every MCP initialize, the server sends instructions that tell the agent to search memory with two or three short queries at the start of a task. So the agent calls memory__search_memory for "meeting brief format" and "Harbor Labs" before it reads anything.
The first query finds a preference you saved earlier with memory__remember: "Meeting briefs: five lines, open items first, no history older than a month." The second finds a named relationship: "Harbor Labs: the technical lead joins every call and prefers a written agenda in advance." Both are private memories, the default scope, because they are yours.
After the meeting, the agent saves the outcome: "Harbor Labs agreed to a pilot starting November; pricing still open." The next brief starts from there. Pinning that memory surfaces it at the start of every session.
Keep the memory to preferences, decisions, named relationships and constraints. Do not save whole threads or anything secret. Memory is context for a later action, and memory operations cost 0 credits per call.
Why do these connections stay private?
A private connection is reached only by the member who connected it and their clients. An agent principal with an sk-csa- key reaches shared connections only, never a member's private ones. So this flow runs under your own sign-in, or under an sk-cs- API key you created, which acts as you with the same reach. An unattended bot you run elsewhere cannot read your inbox unless you share the connection, and an inbox is rarely something to share.
Treat fetched mail as untrusted content. A message that tells the agent to forward something is still just a message; keep client confirmation on for writes when other MCP servers are connected alongside.
What is recorded?
Dashboard → Activity holds one record per call: action, actor, outcome, surface and time. Prompts are not audit payloads, and sensitive request content is not copied, so the thread text the agent read is not in the trail. Each metered call references a charge in the organization ledger; per-action prices are on /pricing.
FAQ
Does the agent see my Google password or token? No. The agent receives the tools. The token lives in CoreSpeed's custody and is refreshed there.
Can a teammate's agent read my inbox? Not through a private connection. Only you and your clients reach it. Sharing a connection is an explicit choice you make when connecting.
What if Gmail shows needs_reauth? Reauthorize in Dashboard → Connectors. Do not rotate your CoreSpeed key or rewrite client config; neither is broken.
Does the brief need Smart Approval? No. Approvals are off until your organization turns them on, and reads are never gated either way. With the gate on, only the Notion write is judged.