Skip to main content
Microgravity is a suite of autonomous, Anthropic-Claude-based agents that run your day-to-day GTM motion for you — reading your inbox and calendar, watching your pipeline, prepping you before meetings, and drafting the outreach and digests a GTM team would otherwise write by hand. Each agent runs on a schedule (or in response to an event like an upcoming meeting), reads from your own tools, and posts its output to Slack or writes it straight into your pipeline — a fleet that works in the background and shows its work, whether or not anyone’s watching. As of 2026-08-14, that background fleet is also a live conversation when you want one. A Slack assistant responds to a direct message or an @mention for on-demand web, company, and people research, and reads Slack itself to help answer what it’s asked. The same approval cards the fleet already posts for an email or a LinkedIn-post draft are now interactive too — tap Approve, Edit, or Cancel right on the card instead of acting on it somewhere else.
It still can’t read your Gmail, Sheets, Drive, or Calendar directly as part of a live conversation — those stay automated-agent-only, and the sheet tools it does have can change an existing row but never read one back. Within that boundary, though, this has grown well past research-only: it can now update or archive a pipeline/investor row, merge duplicate entries, generate a contract or proposal, tune your configuration (behind a real approve/reject card — nothing writes until you tap it), and capture standing feedback that shapes future drafts. See The Slack assistant for the full list.
Looking for the on-demand LinkedIn/company-data enrichment API instead? See Horizon — a separate product on this same docs site. Microgravity can use enrichment data as part of a workflow, but the two ship, price, and deploy independently. See How this differs from Horizon below.

​
What the agents actually do

The fleet is modular — you turn on the agents relevant to your team, not all of them. Typical modules include:
  • Pipeline Strategy — a daily digest of where every deal stands and what needs attention next, posted to Slack.
  • Meeting Prep — a brief before every meeting, pulled from your calendar, past notes, and CRM/pipeline history.
  • Fundraising Digest — investor pipeline status, outreach state, and next steps, for teams actively raising.
  • Email Follow-up, Market Intelligence, GTM Signal Capture, LinkedIn Engagement, Investor Relations, and others, depending on what your team needs.
Every module reads from the tools you already use (email, calendar, meeting notes, a data store, Slack) rather than asking you to adopt a new system of record. See Available integrations & modules for the full, current list of what’s built and what each module requires, and Agent reference for exactly what each module does, reads, and writes — trigger and schedule, inputs, outputs, and what’s configurable today versus onboarding-time-only.

​
The three deployment tiers

Every agent fleet needs four pieces of infrastructure underneath it: a place the agent code runs (GitHub Actions), a Claude/Anthropic account the agents think with, somewhere the Slack app is hosted, and a small key-value store the agents use to avoid double-processing the same event. Who owns each of those four pieces is a spectrum, not a single switch — and, as of 2026-08-12, the default isn’t the same for all four:
  • Claude/Anthropic, app hosting, and the key-value store default to Gravity-managed — the fewest accounts for you to create, hand- provisioned by a Gravity operator on request. Moving ownership of one of these three to you makes sense when you have a specific reason to hold it yourself — infrastructure you already have in place, or a concrete compliance or data-residency requirement — not as a general goal to work toward.
  • Code hosting (GitHub) defaults the other way — to customer-owned. A Gravity-owned repository holds your actual business configuration (your ICP, deal sizes, Slack IDs, content corpus), and a Gravity-hosted default here would mean that data sits in a repo under one shared Gravity credential alongside other customers’ — a security review found that concentration risk isn’t worth the small amount of setup it saves you (creating a private repo and adding Gravity’s deploy bot as a collaborator). Ask your Gravity contact if you’d specifically like Gravity to host your repo instead — it’s still available, just not the starting point.
The small set of enrichment APIs stays Gravity-owned regardless of tier either way (see Security & credentials). Tier 2 is available as a stepping-stone for teams who want to take on just one or two pieces without going all the way to tier 3:
  1. Gravity-hosted — Gravity provisions and owns all four: your agents’ code repository, the Anthropic environment, the hosted Slack app, and the key-value store. Available on request, but not the default — GitHub specifically defaults to customer-owned per the security rationale above, so choosing this tier means explicitly asking Gravity to take on your repo too.
  2. Hybrid (mixed ownership, the default for a new deployment) — you own some of the four pieces while Gravity manages the rest, and which pieces is a genuinely independent choice per piece, not a fixed second option. The starting-point mix is: Gravity manages Claude/Anthropic, hosting, and the key-value store; you keep your own GitHub repo. Talk to your Gravity contact if you’d like a different mix — e.g. taking on your own Anthropic environment, or handing GitHub to Gravity too.
  3. Fully customer-managed — you own all four: your own GitHub repo (with Gravity added as a collaborator to push agent code), your own Anthropic account and API key, your own hosting for the Slack app, and your own key-value store. Almost every secret you generate stays entirely in your own accounts; the two exceptions (your Anthropic API key and your key-value store credentials) are shared with Gravity once, securely, since Gravity’s provisioning step needs them — see Security & credentials for the full trust model. Appropriate when you have a specific reason to own Anthropic/hosting/KV yourself — existing infrastructure investment already in place, or a concrete compliance or data-residency requirement — not as a default starting point (GitHub, as always, stays customer-owned by default regardless of tier). See Getting started for the onboarding conversation every new deployment starts with, and the account-setup walkthrough this tier uses once you submit it.
A fourth deployment tier is planned: fully automated provisioning of all four pieces with no Gravity operator doing it by hand, eventually eliminating per-customer GitHub repos entirely (Gravity’s or the customer’s), which is what makes today’s GitHub-customer-owned default a deliberate stepping stone rather than a permanent architecture. That automated tier is still in development and not yet generally available. Until it ships, choosing the Gravity-hosted tier means a Gravity operator sets the four pieces up on your behalf, not a one-click automated flow.
Whichever tier you’re on, day-to-day configuration works the same way — through the self-serve config MCP server described in Self-serve configuration.

​
How this differs from Horizon

Horizon is an on-demand enrichment API: you (or an agent) ask it a question — find this person’s email, look up this company — and it answers in one API call, billed per call from a prepaid credit balance. Microgravity is the opposite shape: long-running, autonomous agents that work on a schedule without being asked, deployed once per customer, configured rather than called. They’re built and sold independently, though a deployed agent fleet is free to use Horizon (or any other tool) as one of the resources it reads from during a run.

​
Next steps