Pulse — Proactive Intelligence Layer

Date: 2026-03-14
Status: Draft
Author: Uttam (with AI assist)
Companion docs: Data roadmap · Implementation plan

1. Problem

The Forge has meeting intelligence, client dashboards, deal tracking, ticket generation, time data, vault knowledge, and a dozen Mastra agents. Each system is excellent in isolation, but the connections between them are invisible — the place where real business intelligence lives.

Nobody has time to check every page daily. Meeting cadence dropping for a client only matters if you also know their SOW is near burn and their ticket backlog is stalling. A deal stage change only matters in the context of team utilization and upcoming calendar conflicts. Today, synthesizing that picture requires a person to check 5+ pages, hold everything in memory, and connect the dots themselves.

The meeting-created webhook already proves the pattern: one signal triggers classification + scoring + summary + tickets + vault sync. Pulse generalizes that pattern to every signal, running continuously.

2. What Pulse Is

A proactive intelligence layer that monitors all connected systems, maintains a real-time model of business health, and pushes actionable insights before anyone thinks to ask.

Three interfaces:

Surface	Description
`/pulse` page	Morning briefing — the first page anyone opens. Client health signals, your day, stale action items, business signals, team utilization.
Slack `#pulse` channel	Condensed briefing delivered at 8am ET. Thread replies per alert for inline discussion.
”Ask Pulse” chat	Conversational interface via CopilotKit — “What should I focus on today?”, “How’s Eden doing?”, “Am I on track for March revenue?“

3. Why This and Not Something Else

Multiplier, not addition. Every existing data source and feature becomes more valuable because Pulse connects them. A meeting transcript combined with knowledge that the client’s ticket velocity dropped and their SOW renews in 3 weeks is actionable intelligence.
Subsumes 6+ roadmap items. Client Health Scorecard, SOW Burn Tracker, Meeting Context Card, Timesheet Reminder Bot, Revenue Forecast Dashboard, Pipeline Capacity Overlay — these are all views that Pulse generates as side effects.
All plumbing exists. Supabase (meetings, clients), Linear API, Clockify SDK, HubSpot MCP, Mastra agents, CopilotKit, Google Calendar integration, vault transcripts, Slack bot infrastructure. This is orchestration, not infrastructure.
Push vs. pull. Dashboards require you to go look. Pulse comes to you. Fundamental UX shift.
Compounds over time. “Eden’s meeting cadence is 40% below their 90-day average” requires 90 days of baselines. The sooner it starts, the smarter it gets.
The moat. Any agency can adopt Linear + Clockify + HubSpot. An AI system that knows your specific business context, connects dots across all systems, and proactively tells you what to do — that’s not replicable by stacking tools.

4. Architecture

┌──────────────────────────────────────────────────────────────┐
│  Data Sources (all already wired)                            │
│  Supabase (meetings, clients) · Linear · Clockify · HubSpot │
│  Google Calendar · Slack · Vault · Operating                 │
└──────────────────────┬───────────────────────────────────────┘
                       │ scheduled + event-triggered
                       ▼
┌──────────────────────────────────────────────────────────────┐
│  Pulse Engine                                                │
│  ┌────────────────┐  ┌───────────────┐  ┌────────────────┐  │
│  │ Signal          │  │ Health        │  │ Synthesis      │  │
│  │ Collectors      │→ │ Scoring       │→ │ Agent (Mastra) │  │
│  │ (per source)    │  │ (per entity)  │  │                │  │
│  └────────────────┘  └───────────────┘  └────────────────┘  │
│          ↓                    ↓                  ↓           │
│  ┌─────────────────────────────────────────────────────┐     │
│  │  Alert Prioritization (severity × recency × context)│     │
│  └─────────────────────────────────────────────────────┘     │
└──────────────────────┬───────────────────────────────────────┘
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
       /pulse      Slack bot   CopilotKit
       (page)      (#pulse)    ("Ask Pulse")

4.1 Signal Collectors

One lightweight function per data source. Each returns structured signals, not raw data.

Collector	Source	Signals
Meeting cadence	Supabase `zoom_meeting_recording_files`	meetings/week per client, delta vs. 30-day rolling avg
Ticket velocity	Linear API	tickets completed/week per team, aging tickets, blocked items
Budget burn	Clockify + vault SOWs	hours logged vs. SOW budget, projected burn-through date
Deal pipeline	HubSpot MCP	stage changes, stale deals, weighted revenue
Calendar density	Google Calendar API	upcoming meetings per client, prep needed, gaps
Communication recency	Slack Supabase + meeting dates	days since last client contact (any channel)
Action item status	Meeting summaries → Linear cross-ref	action items from transcripts that never became tickets

Collectors run in parallel. Each returns a Signal[] array:

interface Signal {
  source: 'meetings' | 'linear' | 'clockify' | 'hubspot' | 'calendar' | 'slack' | 'vault';
  entity: string;       // client name, team member, deal name
  entityType: 'client' | 'person' | 'deal';
  metric: string;       // e.g. "meeting_cadence", "ticket_velocity"
  value: number;
  baseline: number;     // rolling average or target
  delta: number;        // value - baseline (or % change)
  severity: 'info' | 'warning' | 'critical';
  summary: string;      // human-readable one-liner
  timestamp: string;
}

4.2 Health Scoring

Weighted composite per entity type.

Client health (0–100):

Factor	Weight	Source
Meeting cadence vs. baseline	20%	Supabase
Ticket throughput vs. baseline	20%	Linear
Budget burn rate	25%	Clockify + SOW
Communication recency	15%	Slack + meetings
Deal momentum (if applicable)	10%	HubSpot
Action item follow-through	10%	Summaries + Linear

Team member utilization (simple):

Factor	Weight	Source
Hours logged vs. allocation	70%	Clockify + Operating
Spread across clients	30%	Clockify

Thresholds: Green ≥ 70, Yellow 50–69, Critical < 50.

4.3 Synthesis Agent

A Mastra agent (pulseSynthesisAgent) takes the raw signals and health scores and produces the briefing. The agent’s system prompt instructs it to:

Lead with the most urgent item (highest severity, most actionable)
Group by client, not by data source
Include specific numbers (“3 meetings/week → 0 this week”, not “meeting cadence dropped”)
End each alert with a concrete suggestion (“Schedule a check-in”, “Review scope with PM”)
Keep total briefing under 800 words

4.4 Storage

Table	Database	Purpose
`pulse_signals`	Internal Supabase	Raw signals from each run (append-only, used for baselines)
`pulse_briefings`	Internal Supabase	Generated briefings (one per day, archived for trend)
`pulse_health_scores`	Internal Supabase	Client + person scores over time (enables “health trend” chart)

5. The `/pulse` Page

Not a dashboard with 20 widgets. A briefing — more like a morning email from your smartest colleague than a BI tool.

Sections

Top-of-mind — 1–3 critical items with red badges. “LMNT hasn’t had a meeting in 12 days, their ticket velocity dropped 60%, and their SOW hits 80% burn Friday.”
Client health grid — one row per active client: name, health score (colored), sparkline trend (last 30 days), top signal. Click to expand full signal breakdown.
Your day — upcoming meetings from Google Calendar, each with auto-generated prep card (meeting-prep skill output). Shows: last meeting summary, open action items, relevant Linear tickets.
Stale action items — action items extracted from recent meeting summaries that don’t match any Linear ticket. “From Eden sync (Mar 10): ‘Migrate staging pipeline’ — no Linear ticket found.”
Team pulse — per-person utilization bar (hours logged / allocated). Flags overloaded (>110%) and underutilized (<60%).
Business signals — deal stage changes, new meetings with prospects, revenue run-rate vs. target.

UX principles

Single column, scrollable, no sidebar navigation within the page
Loads fast — parallel data fetching, no waterfalls
Briefing text is pre-generated (read from pulse_briefings), health scores and signals are live
Mobile-friendly — designed to check from phone before first meeting
“Ask Pulse” chat panel on the right (CopilotKit), same as existing chat pattern

6. Slack Integration

Morning briefing

Cron job at 8am ET (or configurable). Posts to #pulse:

☀️ Pulse — Friday Mar 14

🔴 LMNT — No meetings in 12 days. Ticket throughput ↓60%. SOW at 78% burn.
🟡 Eden — 2 stale action items from Mar 10 sync. Consider follow-up.
🟢 ABC — On track. 4 tickets shipped this week.
🟢 CTA — On track. Next meeting Monday.

📊 Team: 3/5 people on track for hours. Uttam at 120% — check rebalancing.
💰 Pipeline: $45K weighted (2 deals in negotiation).

Each colored line is a thread-starter. Thread replies contain the full signal breakdown.

Alert threading

When a critical signal fires mid-day (e.g., a deal stage changes, a ticket is blocked for >3 days), Pulse posts a thread reply on the relevant client’s morning line, or a new message if no morning post exists.

7. “Ask Pulse” (Conversational)

Uses the existing CopilotKit infrastructure with a pulseCopilotAgent that has access to:

Latest pulse_signals and pulse_health_scores from Supabase
Vault transcripts (via existing repo-context search)
Linear API (for ticket details)
Clockify API (for hours details)

Example interactions:

“What should I focus on today?” → Prioritized list from today’s signals
“How’s Eden doing this sprint?” → Health score + breakdown + recent context
“Which clients haven’t met with us in 2+ weeks?” → Query against meeting cadence signals
“Am I on track for March revenue?” → Pipeline + confirmed revenue from Operating
“What did we promise LMNT last week?” → Searches recent transcript summaries + action items

8. Phased Rollout

Phase 1 — Signal Collection + Page (2–3 weeks)

Goal: Ship /pulse with real data from the two most valuable signal sources.

Create pulse_signals, pulse_briefings, pulse_health_scores tables in Internal Supabase
Build meeting cadence collector (Supabase query, rolling average)
Build ticket velocity collector (Linear API)
Build health scoring function (client-level, just these two factors)
Build pulseSynthesisAgent (Mastra, generates briefing from signals)
Build /pulse page — briefing text + client health grid
Schedule daily run (Next.js cron or Vercel cron)

Outcome: Team can open /pulse every morning and see client health with meeting + ticket signals.

Phase 2 — Full Signals + Slack (2 weeks)

Add budget burn collector (Clockify + vault SOW parsing)
Add calendar density collector (Google Calendar API)
Add communication recency collector (Slack Supabase)
Add stale action items detection (summary parsing + Linear cross-ref)
Add team utilization section (Clockify hours vs. Operating allocation)
Build Slack morning briefing (cron → #pulse post with threads)
Health scoring with all weights active

Outcome: Full signal coverage. Slack delivery. No more manual cross-checking.

Phase 3 — Conversational + Alerts (1–2 weeks)

Build “Ask Pulse” CopilotKit agent with signal + vault + Linear context
Add real-time alert threading in Slack (mid-day critical signals)
Add “Your day” section (Calendar integration + meeting-prep auto-cards)
Add business signals section (HubSpot deal changes)
Health trend sparklines (30-day chart from pulse_health_scores history)

Outcome: Full Pulse system live — page, Slack, conversational, real-time alerts.

Phase 4 — Compound Intelligence (ongoing)

Anomaly detection improvements (seasonal patterns, project-phase awareness)
Per-person briefings (role-aware — PM sees different signals than engineer)
Weekly digest email (opt-in)
“Pulse told me about this” attribution tracking (did the alert lead to action?)
Integration with idea-to-tickets (Pulse flags a pattern → suggests a plan)

9. Relationship to Roadmap

Pulse absorbs or accelerates these roadmap items from knowledge/engineering/brainforge-internal-tools-roadmap.md:

Roadmap Item	How Pulse Handles It
3. Meeting Context Card	Phase 1 — “Your day” section with auto-generated prep cards
4. Client Health Scorecard	Phase 1 — Client health grid with composite scores
1. SOW Burn Tracker	Phase 2 — Budget burn collector + alerts at 80%
2. Timesheet Reminder Bot	Phase 2 — Team utilization section flags missing hours
5. Pipeline Capacity Overlay	Phase 3 — Business signals + “Ask Pulse” for capacity questions
7. Revenue Forecast Dashboard	Phase 3 — Business signals section with pipeline + confirmed revenue

These items don’t disappear from the roadmap — they may still deserve dedicated pages. But Pulse provides the alerting and synthesis layer that makes each one proactive rather than reactive.

10. Data Source Readiness

Source	API Exists	Used in Platform Today	Pulse Needs
Supabase (meetings)	Yes	Dashboard, meeting pages	Meeting cadence query — ready
Linear	Yes	Ticket generation, internal tools	Ticket velocity query — ready
Clockify	Yes	Calendar Clockify sync	Hours per client per week — ready
HubSpot	Yes (MCP)	Deals page	Deal stage changes — ready
Google Calendar	Yes	Calendar Clockify sync	Upcoming meetings — ready
Slack	Yes (Supabase)	Slack context skill	Last message date per client — ready
Vault SOWs	File-based	Meeting-prep skill reads them	SOW budget parsing — needs light parser
Operating	Partial	Planned for Allocation vs. Actuals	Allocation data — blocked on Operating SDK

Phase 1 can ship with zero new API integrations. Everything needed (Supabase meetings + Linear) is already wired.

11. Open Questions

Scheduling: Next.js cron (Vercel), Dagster job, or standalone cron? Dagster is already in the repo and handles scheduling, but adds Python dependency for a TypeScript feature.
Baseline period: How many days of data before health scores become meaningful? Proposal: 14 days minimum, with a “warming up” indicator for new clients.
Per-user vs. team briefing: Phase 1 is team-wide. Phase 4 introduces role-aware briefings. Is this the right sequencing?
Operating SDK dependency: Phase 2 team utilization needs Operating allocation data. If the SDK isn’t ready, fall back to Clockify-only utilization (hours logged vs. 40-hour target).
Alert fatigue: How to prevent Pulse from becoming noise? Proposal: max 3 critical + 3 warning signals per briefing; “info” signals are collapsed by default.

Brainforge Knowledge

Explorer

pulse-proactive-intelligence-2026

Pulse — Proactive Intelligence Layer

1. Problem

2. What Pulse Is

3. Why This and Not Something Else

4. Architecture

4.1 Signal Collectors

4.2 Health Scoring

4.3 Synthesis Agent

4.4 Storage

5. The `/pulse` Page

Sections

UX principles

6. Slack Integration

Morning briefing

Alert threading

7. “Ask Pulse” (Conversational)

8. Phased Rollout

Phase 1 — Signal Collection + Page (2–3 weeks)

Phase 2 — Full Signals + Slack (2 weeks)

Phase 3 — Conversational + Alerts (1–2 weeks)

Phase 4 — Compound Intelligence (ongoing)

9. Relationship to Roadmap

10. Data Source Readiness

11. Open Questions

Graph View

Table of Contents

Backlinks

Brainforge Knowledge

Explorer

pulse-proactive-intelligence-2026

Pulse — Proactive Intelligence Layer

1. Problem

2. What Pulse Is

3. Why This and Not Something Else

4. Architecture

4.1 Signal Collectors

4.2 Health Scoring

4.3 Synthesis Agent

4.4 Storage

5. The /pulse Page

Sections

UX principles

6. Slack Integration

Morning briefing

Alert threading

7. “Ask Pulse” (Conversational)

8. Phased Rollout

Phase 1 — Signal Collection + Page (2–3 weeks)

Phase 2 — Full Signals + Slack (2 weeks)

Phase 3 — Conversational + Alerts (1–2 weeks)

Phase 4 — Compound Intelligence (ongoing)

9. Relationship to Roadmap

10. Data Source Readiness

11. Open Questions

Graph View

Table of Contents

Backlinks

5. The `/pulse` Page