How WorkOS gives every team shared GTM intelligence with Cargo

WorkOS had plenty of people building GTM tools. What those builders needed was a common way to enrich a contact, assess an account and read or update CRM data, with control over what each new tool would cost.

Today, tens of bots and internal tools run with Cargo as their backend. A lead question in Slack, a developer signup and an event list can all draw on the same customer intelligence. The central team manages the shared methods; teams across the business decide how to use them.

Why WorkOS chose Cargo

WorkOS’s earlier event-enrichment setup was error-prone. Supporting more internal tools meant finding a way to keep its own qualification logic and data access without taking on every integration and execution problem behind them.

Cargo gave WorkOS reusable building blocks it could define in code, with branching, error handling and execution at scale underneath. WorkOS built methods for enrichment, scoring, lookups and CRM upserts, then exposed them through its own MCP and API layer. Cargo runs the underlying workflows; WorkOS manages how people and agents consume them.

Example pattern: define once, reuse across workflows.

const accountEnrichment = defineTool("account_enrichment", {
  workflow: enrichCompanyData,
});

uses.accountEnrichment({ domain: input.domain });

Define the tool once, then call it from another workflow. Each caller reuses the same enrichment logic.

How WorkOS built the system

1. Put shared GTM methods behind self-service tools

Anyone at WorkOS can ask in Slack whether a company is a good lead and get context for priority, ownership and follow-up. Bots and internal tools call the same methods to research stakeholders, enrich people and companies, or read and update CRM records.

New tools reuse those capabilities without their builders wiring up another set of providers. Enrichment records persist in Snowflake, and recent results are reused across requests. WorkOS keeps caching and spend controls in one place, so another team can experiment without paying to fetch information already gathered elsewhere.

2. Apply the same intelligence to every signup

WorkOS evaluates, scores and routes every signup within minutes. Cargo enriches the person and company and applies WorkOS’s qualification logic, giving the follow-up process the account context it needs.

Inbound becomes another consumer of the same shared tools. Qualification establishes priority and ownership early, so reps can act on relevant interest while it is fresh. A refinement to the scoring logic can serve this automatic flow and the internal tools people use to research accounts.

3. Connect event decisions to sales follow-up

Before an event, the events team queries WorkOS’s database to select potential speakers from sponsor accounts. Account tier, readiness for WorkOS and customer status help determine whom to approach, without pulling a sales leader into every account review.

Afterward, the team uploads lead lists. Cargo enriches the records, and WorkOS’s system routes them to reps or automated email follow-up.

The workflow combines tools already running across the business with WorkOS’s own event logic. Builders can adapt targeting through the CLI and reuse the enrichment paths behind it. Events can operate independently while staying coordinated with sales on account priority, ownership and follow-up.

What Cargo makes possible

Custom logic that stays easy to change. Builders use Cargo’s CLI and coding agents to refine workflows, inspect outputs and apply improvements to shared tools. As Jack Perales puts it, “the feedback loop became a lot tighter.”

Example pattern: give each signup a qualified next step.

const company = uses.accountEnrichment({
  domain: input.domain,
});
const fit = uses.qualifySignup({ company });
if (fit.isQualified === true) {
  uses.routeToSales({
    email: input.email,
    company,
  });
}

The same enrichment tool feeds qualification and follow-up. Custom tools apply the team’s rules and route qualified signups with their company context.

Execution the team does not have to build itself. Cargo handles the different enrichment paths and their errors, with visibility into runs when something needs attention. WorkOS can focus on the business logic while Cargo operates the workflows behind it. That “takes a very big management burden off of us,” says Jack. Errors still surface, but in a weekly readout rather than a broken tool.

Experimentation with central control. Each team can build the interface it needs while WorkOS maintains common methods, enrichment records and spend controls. More ways to use customer data do not require a separate enrichment system for every tool.

What changed

40% lower cost per completed enrichment

Shared records and caching reduce repeated paid lookups. More teams can build GTM tools using existing enrichment while WorkOS manages spend centrally.

25% higher signup-to-qualified-opportunity conversion

Scoring and routing every signup within minutes gives sales a consistent way to identify promising accounts and act with the right context.

30% higher event-lead-to-qualified-opportunity conversion

Account intelligence connects event targeting to follow-up. Enriched leads reach the right rep or automated sequence with their priority established.

What other teams can learn

Start with the methods every GTM tool needs: enrichment, qualification and CRM access. Make those reusable before adding more bots or interfaces. Teams can then experiment with how they work, while the shared data, business rules and operating controls improve together.