Skip to main content
Setting up your Gravity agent suite starts with a conversation, not a form or an email thread. You connect Gravity’s config MCP (Model Context Protocol) server to Claude.ai or ChatGPT, and a guided walkthrough asks what it needs to know — one section at a time, validating each answer as you go — until your configuration is complete enough to submit.
Connecting the server itself requires no infrastructure at all. A brand-new customer with no GitHub repo, no Anthropic account, and no hosting yet still gets a real, working, revocable credential from a genuine OAuth flow. Account creation comes later, as a result of finishing this conversation — never a prerequisite to starting it.
This page covers the whole journey: the onboarding conversation itself, the infrastructure Gravity’s operators help you stand up once you submit it, and the final live connections that switch your fleet on. For exactly how the connector and its OAuth flow work — the setup code, reconnecting a second client, what each tool call actually does — see Self-serve configuration. This page picks up once you’re connected and starts talking to the onboarding tools.
The onboarding conversation below is the same regardless of which deployment tier you end up on. The account-creation steps in “What happens after you submit” describe the fully customer-managed tier — the path with the most account-creation work, appropriate when your team has a specific reason to own Anthropic/hosting/KV infrastructure yourselves. On the default hybrid mix (Gravity manages Claude/Anthropic, hosting, and the key-value store; you keep your own GitHub repo) or the fully Gravity-hosted tier, some or all of those steps are handled for you instead.

​
How this works

The golden rule holds throughout: never put a password, API key, or token into email, Slack, or a chat message. The onboarding tools themselves never ask for one directly — anything sensitive is always deferred to a dedicated hosted page. See Security & credentials for the full trust model.

​
💬 The onboarding conversation

This section is a friendly, narrative summary. For the exact field paths, types, completeness rules, and a few known rough edges worth knowing about up front, see the Onboarding reference — a precise, field-by-field companion to this page.
Once you’re connected in onboarding mode, four tools drive the walkthrough: get_onboarding_status tells you where you currently stand, onboarding_next_step tells you exactly what to fill in next (and why), submit_onboarding_answer sets one field at a time — rejecting an unrecognized field or an invalid option immediately, rather than letting it sit in your draft unnoticed — and submit_for_review runs a final, full check. You don’t need to know these tool names to use them; your Claude.ai or ChatGPT session calls them for you as you talk. The walkthrough works through seven sections, always in the same order, because later sections build on earlier ones:

​
1. Team

Who’s on the team the agents work for — each person’s id, name, and email, at minimum — and which one of them is the single primary contact. Exactly one person has to be marked primary. Add a LinkedIn URL for anyone whose LinkedIn modules you plan to turn on later, since that’s needed before those modules can go live.

​
2. Your north star

Your actual goal, in your own words — not a generic checklist. This asks for three things: a short, specific description of what you’re aiming for, a timeframe (this month, this quarter, this year, or multi-year), and one sentence on how you’ll measure progress toward it. This comes second — before tool stack or modules — on purpose: once it’s set, the modules section below echoes your own stated goal back at you while you decide what to turn on, instead of asking you to judge a generic feature list in the abstract. Company Clarity, in particular, is built to read this goal directly.

​
3. Tool stack

Which tool you actually use for each category: messaging, email, calendar, data store, CRM, file storage, and meeting notes — plus, optionally, programmatic email sending (no module requires it — leave it unset and outbound stays Gmail-draft-only by default) and any LinkedIn accounts your modules will need. For each category, the walkthrough surfaces the real, currently valid options and which of your modules needs it. See Available integrations & modules for the full list of options per category, current build status, and settings — including the “something else” path for a tool that isn’t listed, which the walkthrough treats as a real answer (you describe what the tool actually is, and Gravity scopes a custom integration) rather than a dead end.

​
4. Modules

Which agents to actually turn on. Rather than handing you a bare technical list, the walkthrough surfaces a plain-English description of what each module does — and, since your north star is already set by this point, echoes your own stated goal back alongside it — so you can judge fit for yourself instead of guessing from a feature name. See Available integrations & modules for the full module reference, including per-module settings you can tune any time (a digest’s Slack channel and send time, a follow-up window, and so on). If a module you turn on needs a tool stack category or team detail you skipped earlier, the walkthrough sends you back to fill in exactly that gap before moving on.

​
5. Routing

Who gets alerted for what: a single team member marked as the recipient for anything urgent, and which Slack channels different kinds of agent output post to.

​
6. Content

Voice calibration — so drafts sound like your team, not generic AI — plus your ICP/goals context, which the strategic-monitoring modules read. For voice, pick one path: share a handful of real writing samples per teammate (cold emails, LinkedIn posts, investor updates), or book a short founder voice interview instead.

​
7. Infra

If any of your infrastructure — your GitHub repo, your Anthropic org, your hosting, your KV store — is on the customer-managed tier (available when you have a specific reason to own a given piece yourself), this section asks, for each piece still outstanding: have you already started? If you have, share what you’ve got — a repo slug, an org name, which hosting platform you’ve picked (and a deploy URL once one exists), or a KV database name — never a real credential, only a name, slug, or URL. If you haven’t started yet, that’s completely fine: nothing here blocks you from submitting, and you can report any of it later, any time before go-live. Which tier each piece of infrastructure is on isn’t a choice this conversation lets you make — that’s already decided before onboarding starts. Want to self-host something Gravity currently manages for you, but nobody’s made that call yet? You don’t need to wait for an operator decision first — tell the onboarding tools your preferred hosting platform as a heads-up (infra.hosting_platform_preference), and a Gravity operator follows up to actually set it up. This is a request, not a tier change, and it’s completely optional.

​
Submitting for review

Once everything above is filled in — infra excepted, since it’s the one section you’re always free to leave blank — submit_for_review re-validates your entire draft in one pass. Zero errors flips your status to submitted and hands off to a Gravity operator for provisioning. Any errors come back as a specific, itemized list — nothing advances silently, and nothing gets left for you to discover only once it fails for real later.

​
🟢 What happens after you submit

By default, this is where actual infrastructure creation begins in earnest — not before. Once your configuration is submitted, a Gravity operator runs the provisioning step, and that’s the point at which four pieces of infrastructure actually need to exist: a place your agent code runs, a Claude/Anthropic account the agents think with, somewhere your Slack app is hosted, and a small key-value store so agents never double-process the same event.
If you’re already ahead of the conversation — say you already have a GitHub org and just spin up the repo early — you don’t have to wait for provisioning to say so. The Infra section of the onboarding conversation itself invites you to report anything you’ve already set up (a repo slug, an org name, a hosting platform and deploy URL, a KV database name) as you go, so Gravity’s provisioning step never asks you to redo work you’ve already done. It’s entirely optional, and skipping it never blocks submission — see Onboarding reference for the exact fields.
On the fully customer-managed tier (appropriate when you have a specific reason to own a given piece yourself), you create and own all four:

​
Agent execution (GitHub)

  1. In your GitHub org, create a new private repository for your agents.
  2. Add Gravity’s deploy bot as a collaborator with write access — this is what lets Gravity push agent code to your repository.
  3. Create a Personal Access Token (fine-grained, scoped to that repo) and set it as your repository’s own GH_PAT Actions secret. You keep this token — it is never shared with Gravity.
  4. Share the repository name with your Gravity contact once it exists — not a secret, just a quick reply.

​
Claude / Anthropic account

  1. Create an account at console.anthropic.com if you don’t already have one, and generate an API key.
  2. Share that API key with Gravity securely — through the hosted /provision-secrets intake page, never over chat or email (see Security & credentials).
  3. Add Gravity as an org member with permission to create agents, environments, and API keys — or book a short agent-creation walkthrough with Gravity instead.
  4. Share your Anthropic org name with your Gravity contact.

​
App hosting

  1. Create an account with your hosting provider of choice and connect it to your GitHub org.
  2. Import your agents repository as a project.
  3. Share the resulting deploy URL with your Gravity contact once it exists.

​
Key-value store (dedup memory)

A small store so agents never process the same email or event twice (no message content is ever stored in it — only IDs).
  1. Create a database with a Redis-compatible provider (Gravity can point you to a recommended one with a generous free tier).
  2. Copy the REST URL and REST token into your own repository/hosting secrets, and share them with Gravity securely through the same /provision-secrets page — Gravity’s provisioning step needs them too.

​
Install the Slack app

  1. Gravity sends a pre-built Slack app manifest and install link.
  2. A workspace admin clicks Install and approves the requested scopes (a couple of minutes).
  3. Copy the resulting bot token, signing secret, and client credentials into your own repository/hosting secrets.
Once installed, the app is more than a one-way notifier. It responds to a direct message or an @mention for on-demand research, and the approval cards it posts for an email or a LinkedIn-post draft carry live Approve, Edit, and Cancel buttons you tap right there instead of acting elsewhere. A 📤 reaction on a parked, no-email contact promotes it straight into your active pipeline. And each teammate gets a Home tab showing which modules are currently active for your fleet, once installation completes.

​
If you turned on programmatic email sending

Only applies if you picked Resend for the programmatic email sending category back in the tool stack section.
  1. Share your company’s physical mailing address with Gravity — CAN-SPAM law requires it in the footer of every automated sequence send, and sends refuse to go out without it. It isn’t a secret — a plain reply to your Gravity contact is fine.

​
(Optional) Seed the pipeline from an existing CRM

If you’re moving off an existing CRM or spreadsheet, mention it to Gravity — exporting your existing contacts into your new data store to seed the pipeline is optional, async work you can do any time before go-live, not a prerequisite to submitting your configuration. Once all four pieces exist, Gravity’s provisioning step creates your Agent(s) and Environment inside your Anthropic account and wires in the configuration your onboarding conversation collected — including the handful of remaining operational values (data-enrichment keys, agent IDs, data-store IDs) that only come into being once the agents themselves do.
Almost every secret you generate in this section goes straight into your own stores and never reaches Gravity at all. The two exceptions — your Anthropic API key and your key-value store’s REST credentials — go through the same hosted /provision-secrets page, never chat or email. See Security & credentials for the complete trust model, including how the handful of values Gravity gives back to you (which its deploy bot can’t write directly, since it only holds Write access to your repo) get shared and set.

​
🤝 Final connections and go-live

A few connections are deliberately done live, since they involve one-time logins that should never travel over a message:
  1. Connect email/calendar for each teammate — a one-click OAuth consent screen, read + draft-only by default.
  2. Connect LinkedIn for each teammate, for modules that need it.
  3. Validation and go-live — a full connection check across everything above, then the fleet switches on.

​
Next steps