Push Intelligence: How Autonomous Agents Should Prepare You for Meetings

The Concept

Most AI tools today are pull-based. You open a chat, type a question, and get an answer. The user carries the entire cognitive burden: knowing what to ask, when to ask it, and which tool to ask it in.

Push intelligence flips this model. Instead of waiting for a query, the system monitors what's coming next on your schedule and proactively assembles the context you'll need before you need it.

Meeting preparation is the clearest example. Before any meeting, you need roughly the same things: what's the current status of the project being discussed, what's blocked, what should you bring up, and what do you need to walk out with. This information exists across your email, project tracker, chat history, and shared documents. The problem isn't that the information is missing. It's that it's scattered, and manually assembling it takes 10-15 minutes per meeting.

Pull intelligence is a search engine: you type a query when you realize you need something. Push intelligence is a newspaper delivered to your door: curated for you, timed to when you'll need it.

When to apply this: Any recurring event where one person needs context assembled from multiple sources. Meetings are the obvious case, but the pattern extends to weekly standups, client check-ins, sprint reviews, 1-on-1s, and even deployment windows.

Common pitfalls:

Pushing too much. A brief that dumps every tangentially related email into your lap is worse than no brief. The value is in curation, not aggregation.
Pushing too early. Context assembled 48 hours before a meeting is stale by meeting time. The sweet spot is two passes: a lightweight heads-up at 24 hours, and a fully enriched brief at 1 hour.
No signal correlation. A brief that lists raw emails, raw tickets, and raw chat messages in three separate blocks forces you to do the synthesis yourself. The system should correlate signals and present a unified narrative.

Quick Win: Claude Skill

Here's a prompt you can use right now to generate a structured meeting brief from raw context:

You are a chief of staff preparing a meeting brief. I will provide:
1. Meeting details (title, time, participants, my role)
2. Raw context signals from multiple sources

Produce a structured brief with these exact sections:

**Current Status** - 2-3 sentences on where the project/topic stands right now
**Active Blockers** - Bullet list of what's stuck and who owns each blocker
**Suggested Talking Points** - 3-5 specific points to raise, ordered by priority
**Your Objective** - One sentence: what I need to walk out of this meeting with
**Recent Activity Summary** - Brief chronological list of relevant events from the past 7 days

Be concise. Each section should be skimmable in under 30 seconds.
The entire brief should fit on one screen.

Meeting details:
[PASTE MEETING TITLE, TIME, PARTICIPANTS, YOUR ROLE]

Context signals:
[PASTE RELEVANT EMAILS, TICKETS, CHAT MESSAGES, DOC SNIPPETS]

Example input (paste after the prompt):

Meeting: Q3 Product Review
Time: Tuesday 2:00 PM
Participants: Sarah (PM), Dev Team, Myself (Engineering Lead)
My role: Present technical progress, flag risks

Signals:
- Email from Sarah (Monday): "Can we discuss the API migration timeline? Client X is asking."
- Jira ticket PROJ-142: "API v2 migration - Status: In Progress, Assignee: James, Blocked by: legacy auth deprecation"
- Slack thread (Friday): Dev team discussing a performance regression in the staging environment, no resolution yet
- Google Doc "Q3 Roadmap": Last edited yesterday, Sarah added a new section on client onboarding priorities
- Jira ticket PROJ-158: "Staging perf regression - Status: Open, Priority: High, Created: Friday"

What you'll get back: A structured brief telling you that the API migration is blocked by auth deprecation (raise this with Sarah), there's an unresolved staging regression (need a timeline from the team), and Sarah has added new onboarding priorities to the roadmap (review before the meeting). Your objective: get alignment on whether to prioritize the migration blocker or the perf regression.

Iteration tips:

Add participant history ("last 3 meetings with Sarah") for relationship context and continuity.
Include a "Decisions Needed" section for meetings where you're the decision-maker, not just a participant.

Full System Specification

Problem Statement

Professionals spend 10-15 minutes per meeting manually assembling context from scattered sources, or they walk in unprepared. The information needed exists across calendar, email, project trackers, and chat, but is never consolidated into a single, actionable brief.

Architecture

Four components, each independently deployable:

Calendar Monitor — Polls the calendar API every 15 minutes. Identifies meetings in the upcoming window (next 24 hours). Extracts participants, title, description, and any linked documents. Deduplicates using the calendar event ID as an idempotency key.
Signal Collector — For each upcoming meeting, queries connected systems for relevant context. Uses participant names, project keywords from the meeting title/description, and a time range (past 7 days) as search parameters. Sources: email API (threads involving participants), project tracker API (tickets mentioning project keywords), chat API (threads in relevant channels), document API (recently edited docs shared with participants).
Brief Generator — Takes the raw signals and meeting metadata, scores each signal for relevance (recent > old, same participants > tangential, same project > different project), and calls an LLM with a structured prompt to produce a brief with predefined sections: Status, Blockers, Talking Points, Objective, Recent Activity.
Delivery Engine — Sends the brief at configured times. Two-pass delivery: a lightweight preview at 24 hours ("You have a meeting with Sarah tomorrow about Q3 Review. 2 blockers detected.") and a full enriched brief at 1 hour before the meeting.

Data Model

MeetingBrief {
  id, calendarEventId, meetingTitle, meetingTime,
  participants, briefJson, status, deliveredAt, createdAt
}

BriefSignal {
  id, briefId, source, sourceId, content,
  relevanceScore, includedInBrief
}

Key Design Decisions

Idempotency: Use calendarEventId to prevent duplicate briefs. If a meeting is rescheduled, regenerate the brief with fresh signals.
Relevance scoring: Not all signals are equal. Score by recency (exponential decay), participant overlap (exact match > partial), and source type (project tracker > general email).
Graceful degradation: If a signal source is unavailable (e.g., Jira is down), generate the brief with whatever sources responded. A partial brief is better than no brief.

Phased Rollout

MVP: Calendar poll + email-only signals + single brief delivery at 1 hour before the meeting. No relevance scoring; include all signals under a token limit.

v1: Add project tracker signals (Jira/Linear). Two-pass delivery (24h lightweight + 1h full). Structured sections (status, blockers, talking points, objective). Relevance scoring to filter noise.

v2: Participant relationship history (summary of last N meetings with each person, sentiment trends). Post-meeting follow-up generation (action items extracted from meeting notes). Feedback loop: track which sections users actually read, which briefs they rate as helpful, and use this to tune relevance scoring over time.

Technology Recommendations

Calendar: Google Calendar API (or Microsoft Graph for Outlook environments)
Email: Gmail API with thread-level search, or Microsoft Graph
Project tracker: Jira REST API or Linear GraphQL API
Chat: Slack Web API or Google Chat API
Scheduler: A background worker polling on a 15-minute interval (PM2 process, Kubernetes CronJob, or cloud function on a timer)
LLM: Any capable model; route to a mid-tier model since brief generation is structured but not trivially simple