Skip to main content
This page documents what each Gravity Agents Lite module does: what triggers a run, what categories of your own tools it reads from, what it produces and where, and exactly which of its settings you can tune yourself through the config MCP server today versus what’s still fixed at onboarding time. That’s the whole scope, deliberately — it does not describe the specific judgment a module applies (how it weighs one signal against another, what its own instructions tell it to prioritize). That reasoning lives inside each agent’s own system prompt, is versioned independently of this documentation, and isn’t itself something a reference page like this one describes.
Every configurable-field claim below is checked directly against Gravity’s live lib/config-surface.ts allow-list — the single source of truth for what the config MCP server will actually let you read or write. Where a module’s registry-listed setting turns out not to be wired up yet, or where a module touches more of your tools than its own summary suggests, this page says so plainly rather than smoothing it over. See Known gaps at the bottom for the cross-cutting list.

​
How to read each entry

  • Trigger & schedule — most modules run on a stacked schedule: a primary trigger kicks off the workflow, and one or more backup crons fire shortly after in case the primary is missed, with a same-day guard so a module never runs twice in one morning. The times below are the real, current schedule, in plain English — not a literal promise of the exact minute.
  • Configurable today — fields you can read and write yourself through the config MCP server’s update_config tool, taken directly from the live allow-list. A field can be lowered/turned off freely but only raised/turned on up to an operator-set ceiling — noted per-field where that applies.
  • Not yet configurable — anything fixed at onboarding time (which Slack channel a module posts to, what time it runs — every module’s schedule and channel are set once during deployment, not editable through the config MCP server today; see Self-serve configuration), plus anything read-only by design (internal Slack channel routing — see Security & credentials), plus any registry-listed setting confirmed not actually wired to a live field yet. Founder identity is no longer in the read-only bucket — as of 2026-08-14, adding and removing a founder is self-service too (see Self-serve configuration).

​
Pipeline & revenue operations

​
Pipeline Strategy

Purpose. Every day, reviews your sales pipeline and recent prospect email threads, flags deals that need attention (stalled, gone quiet, or showing a buying signal), and drafts an on-voice follow-up email for each one — delivered as a daily briefing so nothing important slips through. Trigger & schedule. Runs once each weekday morning, around 6 AM Mountain Time, with two automatic backup triggers in case the primary is missed. Mondays run as a distinct “weekly strategic” pass with a wider discovery sweep — same daily cadence, just a deeper session that day. Inputs. Your pipeline and prospects sheet tabs; Gmail (searches existing threads, creates drafts); Calendar; Slack (reads recent channel activity and the prior day’s digest to avoid repeating itself); Drive; web search and LinkedIn/company-data lookups (via Gravity-managed enrichment services) for sourcing new prospects. Outputs. A daily Slack digest plus per-founder DMs; Gmail drafts for prospect and pipeline outreach; new/updated pipeline and prospect rows; a parked-contact list (for a prospect with no email on file) that a founder can promote with a Slack reaction. If programmatic sending is turned on for a qualifying cold prospect, the draft routes into an approval-gated send sequence instead of a raw Gmail draft. Configurable today. Your content.* voice fields (pitch, CTA, sender bios, banned phrases — directly confirmed as real, code-read fields for Market Intelligence and Email Follow-up below) almost certainly feed this module’s drafting too, since it’s flagged for voice calibration — but that’s inferred from the flag, not independently confirmed as a direct read inside this specific module’s own code, which we’re disclosing rather than asserting as fact. Not yet configurable. Which Slack channel the digest posts to, and what time it runs, are both fixed during deployment — not exposed through the config MCP server today (ask Gravity for a change). icp.deal_size.tiers and icp.size_gates exist as read fields but aren’t self-serve writable yet (their shapes are too free-form to validate safely today).

​
Email Follow-up

Purpose. Scans every open email thread where your team sent the last message, catches the ones that have gone quiet past your follow-up window, and drafts a ready-to-send, context-aware follow-up for each — so leads don’t go cold just because someone forgot to check back in. Trigger & schedule. Once every weekday morning, around 6 AM Mountain Time, with a same-morning backup: a fleet-wide watchdog re-triggers this module’s run about an hour later on any weekday its primary run hasn’t already gone through. Inputs. Gmail across your team’s mailboxes (messages sent a fixed number of business days ago with no reply since); your pipeline and investor sheet tabs (to exclude threads already closed/passed, and for CRM context); Granola and Drive meeting notes as best-effort supplementary context. Outputs. A Gmail reply draft in the original thread for each qualifying stale thread. For a narrow class of simple follow-ups, it can send directly instead of drafting — gated by configuration, a daily per-founder cap, and a hard rule against ever auto-sending if the recipient has already replied. A Slack digest to your team channel, plus a private per-founder DM listing their own new drafts and any overdue-unsent-draft reminders. Configurable today. Not yet configurable. Turning gmail_autosend.enabled ON is operator-only today (you can always turn it off yourself). No other onboarding-time setting is registered for this module’s schedule or channel beyond the universal pattern.

​
GTM Signal Capture

Purpose. Watches your email and meeting notes continuously (checking every 15 minutes) and updates your pipeline the moment something changes — a reply lands, a meeting wraps, a signal appears — so your data store stays current without manual data entry. Trigger & schedule. Nominally every 15 minutes on weekdays, though in practice GitHub’s own infrastructure throttles a schedule this frequent, so real runs land less often than that. The module compensates for this itself: each run computes how much time has actually passed since the last clean run and looks back over that whole gap (capped at 72 hours), so a less-frequent real cadence doesn’t quietly create a capture gap. Inputs. Granola meeting notes; Gmail replies from known pipeline/investor contacts; Drive documents that look like meeting notes; a queue of relevant Slack messages and 📤-reaction “promote this contact” events forwarded from your Slack app; your pipeline and investor sheet tabs as the match/lookup base. Outputs. Direct field updates to pipeline/investor rows (stage changes, last-contact stamps, dated notes) whenever a signal is detected; promotion of a parked contact into your active pipeline on a founder’s reaction; one end-of-day Slack summary per sheet (real stage advances and promotions only, plus a “gone quiet” staleness list) rather than a message every 15 minutes. Configurable today. None. This module doesn’t read any ICP, discovery, content, or send-related configuration field at all — it doesn’t draft copy or qualify prospects, only detects and records signals, so none of the self-serve config fields apply to it. Not yet configurable. No settings are listed for this module at onboarding time either — its cadence and channel routing are fixed the same way every module’s are.

​
Context & intelligence

​
Meeting Prep

Purpose. Before every external meeting on your calendar, puts together a short briefing — company background, recent news, your prior email history, and suggested talking points — delivered ahead of time so you walk in prepared without digging for context yourself. Trigger & schedule. Honest framing: despite covering “every meeting,” this isn’t a distinct trigger per meeting — it’s one batch run each weekday morning (multiple backup triggers stacked through the morning) that scans the whole day’s calendar up front and produces a brief for every qualifying meeting in that single pass. Inputs. Everyone’s calendar for the day; Gmail history with each counterpart; Granola notes searched by counterpart name; your pipeline and investor sheet tabs for deal-stage context; LinkedIn profile/headline lookups (via Gravity-managed enrichment). Outputs. One formatted Slack message per meeting needing prep, to whichever channel fits the meeting type. Read-and-post only — no sheet writes, no Gmail drafts. Configurable today. Two related fields live in the same module’s code but govern its adjacent post-meeting-summary capability rather than the pre-meeting brief itself: meeting_followup.owner_signal_order (which founder a follow-up draft attributes to) and meeting_summary.relevance_gate_enabled (whether a personal/non-business meeting’s summary gets suppressed). Both are real and self-serve writable, just tied to that adjacent flow. Not yet configurable. How long before a meeting the brief should ideally arrive is a registry-listed setting with no live field behind it today — the schedule is a fixed daily batch, not a per-meeting lead time, so there’s nothing to configure here yet even at onboarding time. A handful of other calendar-classification inputs the module’s code reads (which calendars count as “external,” personal-appointment phrasing beyond the one field above) aren’t exposed through the config server yet either.

​
Market Intelligence

Purpose. Scans your market every day for what actually matters to you — funding announcements, executive moves, competitor news — and delivers one short daily summary to your team’s channel instead of anyone having to hunt for it. Trigger & schedule. Once each weekday morning, early — around 6 AM Mountain Time. Inputs. Web search; Gmail (newsletter-type signals); your pipeline and investor sheet tabs (to cross-reference news against companies you already track); Granola and Drive as supporting research; LinkedIn/company-data lookups for a newly-surfaced company. Outputs. The daily digest itself (funding/M&A, executive moves, customer wins, product launches, and more). Beyond the digest, worth knowing plainly: when a scan surfaces what looks like a new sales prospect, this module can also add a row to your prospects tab, find and enrich a likely decision-maker contact, and create a Gmail draft to them — a real, lighter-weight secondary prospecting path running alongside the news digest, not just a summary. Configurable today. Its own decision-maker title filter isn’t driven by your ICP configuration at all — it’s a fixed list in the module’s own code, so don’t expect icp.target_roles/icp.excluded_industries to change its prospecting behavior. Narrower than “no ICP fields at all,” though: this module does classify each newly-surfaced prospect row into your ICP vertical/industry taxonomy, the same way Pipeline Strategy does — that taxonomy field just isn’t self-serve exposed through the config server today, so there’s nothing to tune here either way. Not yet configurable. Which channel the daily brief posts to is fixed at onboarding time, same as every module’s channel routing.

​
Company Clarity

Purpose. A daily, cross-domain check-in that reads across everything your other agents are doing plus your own stated goals, and speaks up only when something’s off track, signals conflict, or there’s a high-leverage move worth a founder’s attention — quiet otherwise, with a guaranteed end-of-day summary either way. Trigger & schedule. Four passes on weekdays, each with its own same-day backup, plus a separate Saturday pass that has no backup slot of its own: a lighter morning scan, a deeper post-morning review, a light midday check, and the full evening synthesis (the only run guaranteed to post something, and the only one that can also reach an optional founders-only channel) — then, on Saturdays, a single weekend scan for anything urgent. Two of the four weekday passes run on a more capable model tier as a deliberate cost/quality tradeoff — not something you tune yourself. Inputs. Recent posts across every Slack channel your other agents post into (plus anywhere else the bot is invited); Gmail; your pipeline, investor, and prospects sheet tabs; Granola (including an internal-only founder-strategy folder, kept separate from every outward-facing agent); a configured strategy/board Drive folder when set; GitHub Actions run history for the health of your other scheduled agents; web search; your own stated north star. Outputs. Mostly silence — a post to its own dedicated channel only when something clears the bar, plus a guaranteed full daily summary at the evening run. Two additional actions exist, both off by default and each gated behind both a customer-facing toggle and a separate operator-side switch: re-triggering another agent’s run early (rate-limited, restricted to a fixed set of other agents, never itself or any credential file), and proposing (never directly committing) a specific prompt/config change for human review. Configurable today. clarity.write_enabled (whether it may propose a prompt/config change) is read-only through the config server — an operator-only setting with its own review process, since it governs a capability that ships disabled by default regardless of this value. Not yet configurable. No registry setting is listed for this module’s own schedule or channel, same fixed-at-onboarding pattern as the rest. Which internal Granola folder counts as “founder-only strategy notes” is set outside the config server today.

​
Fundraising & PR

​
Fundraising Digest

Purpose. The same daily pipeline discipline as Pipeline Strategy, but aimed at your investor relationships instead of your customers — tracks investor email threads, flags who’s due for a follow-up, and drafts on-voice investor update or outreach emails. Trigger & schedule. Once each weekday morning, around 6:15 AM Mountain Time, with a same-morning backup. The heavier investor-discovery pass (more warm-connection sourcing, expanded sourcing) runs on configured prospecting days — Monday/Wednesday/Friday by default — not specifically on Mondays. Monday is separately this module’s “weekly strategic” pass: a deeper synthesis layered on top of that day’s regular run. The two only appear linked because Monday happens to be the first of the three default prospecting days — change the configured days and the strategic pass still runs Monday, independent of which days carry the heavier sourcing sweep. Inputs. Your investor sheet tab; Gmail (searches investor threads, creates drafts, verifies a send actually went out); Calendar; Slack (recent channel activity, prior digest for dedup); Drive; Granola notes as supplementary context; web search and LinkedIn/company-data lookups for investor-discovery sourcing. Outputs. A daily Slack digest and per-founder DMs; Gmail drafts for investor outreach/follow-up; new/updated investor pipeline rows; promotion of qualifying investor prospects into your active investor pipeline. Configurable today. Your fundraising-facing voice fields (content.investor_pitch, plus the shared content.sender_bios/content.cred_lines/content.banned_phrases) very likely feed this module’s drafting too, given it’s flagged for voice calibration, but — same disclosure as Pipeline Strategy above — this wasn’t independently confirmed as a direct code read in this specific module. Not yet configurable. No onboarding-time setting is registered for this module’s schedule or channel beyond the universal fixed-at-deployment pattern. Worth flagging plainly: this module’s own warm-connection-sweep size lives in its own code as a field that has no entry at all in the config server’s allow-list today — not writable, not marked read-only, simply not yet registered there. A similarly-named field under the discovery.* prefix (rather than fundraising_discovery.*) is allow-listed and self-serve writable, but it governs Pipeline Strategy’s sweep, not this module’s — editing that one has no effect on Fundraising Digest’s sweep size. Ask Gravity directly if you need this module’s sweep size changed until it’s exposed under its own real field.

​
Investor Relations

Purpose. Tracks how recently you’ve been in touch with each investor, drafts on-voice update emails before a relationship goes quiet, and keeps you informed on portfolio-company news your investors care about — a regular check so fundraising relationships don’t get neglected between rounds. Trigger & schedule. Worth stating precisely rather than just “weekly”: this module actually runs in two different modes on two different days — an update pass twice a week (targeting early morning, roughly 5–7 AM Mountain Time — the underlying schedule is deliberately set earlier than that to compensate for GitHub’s own scheduling delay), plus a separate warm-introduction pass once a week on Monday mornings, each with its own backup triggers. Inputs. Your investor and pipeline sheet tabs; Gmail (searches, creates drafts); Slack (reads recent channel activity); Granola notes searched by name; Drive documents; on its Monday warm-introduction pass specifically, also web search and LinkedIn/connection-data lookups (via Gravity-managed enrichment) to find and validate a path to a target investor through your own network. Outputs. A Gmail draft update per investor due for one; a Slack summary of the update run. No sheet writes were found in this module — it reads for context and drafts, but doesn’t write pipeline/investor rows itself. Configurable today. Given it’s flagged for voice calibration in the registry, your voice/content fields likely apply the same way they do for the other Managed-Agent modules above, but that’s not independently confirmed here. Not yet configurable. No settings are registered for this module beyond the universal schedule/channel pattern.

​
PR & Media Outreach

Purpose. Builds and works a list of the journalists, podcasts, and publications that fit your story, then drafts an on-voice, tailored pitch for each — so your media relationships stay warm without a dedicated PR hire. Trigger & schedule. Once a week, Thursday mornings around 7 AM Mountain Time. Inputs. Web search; Gmail (checks for existing coverage/threads, creates drafts); a fallback traction summary and a contextual industry-exclusion note (see below) for framing. Outputs. A Gmail draft pitch per identified target; a Slack summary to your team channel. Configurable today. This module also reads content.traction — your fallback traction copy (committed capital, term sheets, etc.), used only when a live figure isn’t available — but that field isn’t self-serve writable yet (see below). Not yet configurable. No settings are registered for this module beyond the universal schedule/channel pattern. content.traction is a real, confirmed, code-read fallback field, but its shape is too free-form to validate safely yet, so it isn’t self-serve writable through the config server today.

​
LinkedIn & content

​
LinkedIn Engagement

Purpose. Finds the LinkedIn posts worth your founders’ attention — from prospects, investors, and industry voices — and drafts on-voice comments a few times a week for a quick review-and-post. Builds visibility without anyone scrolling LinkedIn looking for things to say, and doesn’t require connecting your own LinkedIn account. Trigger & schedule. Monday/Wednesday/Friday mornings, roughly 5–9 AM Mountain/Eastern depending on the day’s backup trigger. Skips US federal holidays automatically. Inputs. Recent posts (via Gravity-managed LinkedIn data access) from a fixed watch-list of external profiles plus profiles resolved from your own investor/prospect sheet contacts; your investor and prospect sheet tabs, read-only; recent Slack channel history, to avoid repeat suggestions. Outputs. A Slack DM per founder with a handful of comment opportunities (post link, a drafted comment, a one-line rationale) to manually copy/paste onto LinkedIn — this module never posts to LinkedIn directly and never touches a LinkedIn login. A short internal team-channel summary. Configurable today. None. This module reads no ICP, discovery, routing, or send-related configuration field. Not yet configurable. The fixed watch-list of external profiles it always checks, and an optional tone-override block it can read, both exist in your underlying configuration but aren’t exposed through the config server yet.

​
LinkedIn Engagement Harvest

Purpose. Watches who engages with the LinkedIn posts that matter, filters for the people who match your ideal customer profile, and turns them into new pipeline — added to your data store with a personalized outreach email already drafted. Like LinkedIn Engagement, it runs on Gravity’s own data access rather than yours, so no LinkedIn login is required on your side. Trigger & schedule. Tuesday and Thursday mornings, around 9 AM Mountain Time — timed so posts have had a day or two to accumulate engagement. Inputs. Engagement (reactions/comments) on your founders’ own posts and a configured set of external influencer/competitor profiles, via Gravity-managed LinkedIn data access; profile and company enrichment for qualifying engagers; email lookup for each one; your prospects sheet tab (dedup and upsert) and investor sheet headers. Outputs. New prospect rows for each new ICP-fit engager; a Gmail draft (never auto-sent) with personalized outreach; a Slack summary broken down by source (your own posts, influencer posts, competitor pages), plus a separate summary for investor-track leads. Configurable today. icp.size_gates (a minimum-employee-count filter) exists as a modeled field but isn’t self-serve writable yet. Separately worth flagging: this module’s code also reads a content.investor_cta field for investor-track drafts that has no entry at all in the config server’s allow-list today — not writable, not marked read-only, simply not yet registered there. If your investor-track drafts read oddly generic on the CTA line, this is why — ask Gravity to set it directly until it’s exposed. Not yet configurable. No onboarding-time setting is registered for this module’s schedule or channel beyond the universal pattern.

​
Content Publishing

Purpose. Keeps a queue of LinkedIn posts ready for your founders and/or company page — you approve, edit, or reject each one in Slack, then it publishes on schedule. Unlike the Engagement modules above, this one posts on your behalf, so it requires connecting your founders’ (and/or company page’s) LinkedIn accounts. Trigger & schedule. Two separate schedules under one module: drafts are generated once a week (Monday morning, around 6:15–7:15 AM Mountain Time); a separate publish check then runs Tuesday–Friday mornings (around 8:30 AM Mountain Time), publishing whatever’s been approved by then. Inputs. Web search; Gmail (as an optional, fail-open signal — never a hard requirement); Granola notes (privacy-guarded — only notes where a founder actually attended); your pipeline/investor sheet tabs as an optional signal; your team’s own Slack channel history, including past edits/rejections as a feedback signal; each founder’s voice corpus. Outputs. Per-founder draft posts delivered as a Slack DM with approve/edit/skip actions — nothing reaches LinkedIn until approved. A full-length blog draft written to a new Google Doc each week, linked in that week’s Slack messages. Worth knowing plainly before enabling this one:
  • The approval promise applies to personal posts, not company-page posts. A personal (founder) post only goes live after you approve it in Slack. A company-page post, once your company-page LinkedIn connection is fully approved, publishes automatically as soon as it’s generated — no Slack approval step for that half. Until that LinkedIn approval is granted, company-page posts instead land as plain text in your team’s internal channel for manual copy/paste, same as the Engagement modules above.
  • No performance read-back exists yet. What you get after a post publishes is a confirmation message (post ID and a link to your recent activity) — not impressions, likes, or comment counts. Don’t expect an analytics readout unless Gravity confirms it’s been added since this page was written.
  • Microsoft Teams is available on request, not out of the box. Slack is fully built; Teams is scoped and built per customer who asks for it.
Configurable today. None registered specifically for this module. An optional tone-override block its code reads (content.platform_messaging) exists in your underlying configuration but isn’t exposed through the config server yet. Not yet configurable. Both of this module’s schedules (generation and publish) are fixed at deployment, same as every module’s cadence.

​
Known gaps worth knowing about

A few honest, source-confirmed limitations, gathered in one place rather than buried module by module:
  • Email Follow-up, Meeting Prep, Investor Relations, and LinkedIn Engagement Harvest all post to Slack as a core, guaranteed part of every run, even though none of them list messaging as a requirement. In practice this rarely matters — every deployment connects messaging anyway — but if you’re deciding what to skip, don’t assume a module with no messaging requirement stays silent. GTM Signal Capture shares the same undeclared messaging dependency, but not the “every run” part — see its own section above: it posts at most once a day, at its end-of-day summary, not on every 15-minute check.
  • Fundraising Digest’s warm-connection-sweep size has no real configurable field yet, despite a similarly-named one existing. See that module’s own section above: the field it actually reads has no entry in the config server’s allow-list at all, and the similarly-named, allow-listed field under the discovery.* prefix controls Pipeline Strategy’s sweep instead — editing that one does nothing for Fundraising Digest.
  • Meeting Prep also reads your pipeline and investor sheets every run (to populate each brief’s deal-status section) despite a data store not being listed as something it needs either.
  • Market Intelligence does more than its “posts to your channel” requirement label suggests. Beyond needing messaging, it also reads and writes email (Gmail search, and Gmail drafts to a newly-surfaced contact) and a data store (sheet reads, plus new prospect rows) every run — a bigger footprint than just the news digest, and not reflected in its stated requirements.
  • Company Clarity also reads your email and meeting notes every run (plus your file storage, when configured) on top of the messaging and data-store access it’s already listed as needing.
  • A few registry-listed “settings” aren’t backed by a live field yet: Pipeline Strategy’s digest channel/time, Meeting Prep’s lead time, and Market Intelligence’s brief channel are all currently fixed values set once during deployment — none are editable through the config MCP server today. Email Follow-up’s own follow-up window is the exception: it is self-serve editable (email_followup.window_days, see that module’s own section above) — a real config-driven path exists for it, not a gap.
  • Content Publishing’s approval flow only fully covers personal posts — see that module’s own section above for the company-page carve-out.

​
Next steps