Most GTM questions can’t be answered reliably from a CRM record or static company profile: Is this company still in our ICP? Are they hiring salespeople right now? What was their latest funding round? Which companies in this market are we missing?

Those answers live on the open web, scattered across company sites, careers pages and ATS boards, funding announcements, press releases, and industry publications. They also change constantly.

Take Eve, the legal AI company we use below. Its stated customer count went from 450 to more than 1,200 in roughly a year. Meanwhile, Crunchbase still lists its headcount at 1–10.

Nimble’s web search and research tools let developers build GTM workflows around that live evidence instead of treating every task as the same search problem.

This post walks through three GTM use cases. For each, we show two ways to build it:

• Search API: your application controls the workflow; Nimble retrieves the web data.
• Agent API (Web Search Agents): you hand Nimble the research objective, constraints, and output structure; the Agent runs the research workflow itself.

Key takeaways

• GTM data changes quickly and rarely lives in one place. Enrichment, buying-trigger monitoring, and company discovery often require combining evidence from company pages, funding announcements, careers sites, ATS boards, and other sources.
• Nimble’s Search API is useful when the workflow belongs in your code: which searches to run, which sources to trust, and how qualification or scoring works.
• Nimble’s Web Search Agents handle the broader research workflow: planning, searching, site navigation, cross-checking, synthesis, structured output, citations, and confidence scoring.
• Search and Agents are complementary. The choice is less about which one “finds more” and more about how much of the research workflow you want Nimble to own.

Use Case 1: Lead and Account Enrichment

Lead enrichment usually starts with very little: a company name, a domain, or a partially completed CRM record.

The job is to turn that into something an SDR, scoring model, or routing system can actually use: what the company sells, who it sells to, where it operates, how large it is, how it is funded, who runs it, whether it is hiring, and what changed recently.

The challenge is that no single page contains all of this information, and the sources often disagree.

For this example, we started with eve.legal. “Eve” is shared by several unrelated companies, so the workflow has to resolve the company from the domain rather than the name alone.

Want to run the below examples yourself? Both are available for download here:  gtm-account-enrichment-agent

Search API: when your application owns enrichment

Use the Search API when the enrichment rules belong in your application: which fields to fill, which sources take precedence, how fresh a hiring signal must be, and what happens when two sources disagree.

Instead of trying to answer everything with one query, the workflow can run focused passes for identity and products, funding, leadership and headquarters, hiring, and recent company signals.

The request:

from nimble_python import Nimble

nimble = Nimble()

DOMAIN = "eve.legal"

queries = [
    {
        "query": "Eve legal AI platform plaintiff law firms what it does products",
        "include_domains": [DOMAIN],
        "search_depth": "standard",
        "max_results": 5,
    },
    {
        "query": "Eve legal AI plaintiff firms raises funding round valuation investors",
        "search_depth": "standard",
        "max_results": 6,
    },
    {
        "query": "Eve legal AI founders CEO leadership headquarters employees",
        "search_depth": "standard",
        "max_results": 5,
    },
    {
        "query": "Eve legal jobs",
        "include_domains": [
            "job-boards.greenhouse.io",
            "jobs.ashbyhq.com",
            "jobs.lever.co",
        ],
        "search_depth": "lite",
        "max_results": 20,
    },
]

evidence = [nimble.search(**query).results for query in queries]

Parameters used:

• include_domains set to Eve’s own domain on the identity pass, so the product and company description comes from first-party pages.
• include_domains set to Greenhouse, Ashby, and Lever on the hiring pass, so open roles come straight from ATS boards.
• search_depth="standard" where the answer sits in the page text (identity, funding, leadership), and "lite" where titles and URLs are enough (job listings).
• max_results sized to each pass: 5 or 6 for company facts, 20 for job listings.
• A fifth pass for recent company news adds time_range="year".

The agent passes the results to an LLM step that fills a fixed company profile and keeps every conflicting value it finds, each with its source URL and date. Code-side precedence rules then decide which value goes into the CRM.

Agent API: when you want the finished profile

If you want Nimble to perform the research and return the enriched record, give a Web Search Agent the company, source preferences, and output schema.

The request:

run = nimble.agents.run(
    agent_name="gtm-account-enrichment",
    use_case="enrichment",
    effort="high",
    input=(
        "Enrich this CRM account into a current company profile. "
        "Resolve the company from its domain. Prioritize the company's "
        "own website, newsroom and careers pages. Use reputable reporting "
        "for funding and announcements. When sources disagree, choose the "
        "best-supported value and record the disagreement. Leave a field "
        "null rather than guess."
    ),
    input_data={
        "company_name": "Eve",
        "domain": "eve.legal",
        "headquarters": None,
        "employee_count": None,
        "last_round": None,
        "currently_hiring": None,
    },
    output_schema=PROFILE_SCHEMA,
)

Parameters used:

• use_case="enrichment": fills fields on a record you already have, rather than building a new list.
• effort="high": deeper research across several sources. The run took about three minutes for this account.
• input: the research rules. Resolve the company from its domain, prefer first-party pages, record disagreements, and leave a field empty rather than guess.
• input_data: the CRM record, with the fields to fill set to None.
• output_schema: the profile fields to return, such as headquarters, employee_count, last_round, customer_count, currently_hiring, and the source conflicts.

The Agent returned a structured profile covering funding, leadership, headcount, hiring, customer count, recent signals, and source conflicts.

Among the results:

{
  "headquarters": "San Mateo, California, United States",
  "employee_count": "~376 employees",
  "last_round": "Series B, $103M, September 30, 2025",
  "customer_count": "1,200+ plaintiff law firms",
  "currently_hiring": "Yes",
  "open_roles_summary": "20 open roles across Engineering, Sales, Marketing and other functions"
}

Every field comes back with claim-level confidence and citations, so an agent can act on the profile directly: write well-supported fields to the CRM, send low-confidence or conflicting fields to a verification step, and use changes such as new sales leadership or open roles to trigger scoring or outreach.

With the Search API, your application owns enrichment and the rules for resolving conflicting data. With a Web Search Agent, Nimble runs that research workflow and returns the assembled profile.

Use Case 2: Buying Trigger Monitoring

Enrichment is an indispensable step, but generally it focuses more on the big picture - the story behind a lead or account. Effective action requires not just the big story, it also demands understanding the lead’s current situation.

A new CRO or CMO, a funding round, an acquisition, or a large customer win can reset an account’s go-to-market priorities and budget within weeks. Those events show up first in company newsrooms, press releases, and trade press, spread across every account on a watchlist.

The job is to watch a list of accounts, find the events inside a recent window, date each one by when it happened rather than when it was covered, and give a rep a reason to reach out.

For this example, the watchlist was five B2B software companies: Cato Networks, Mark43, Veylo, BlueVoyant, and commercetools. The window was the 30 days ending October 12, 2026, and the seller offers revenue and go-to-market software to fast-growing B2B software companies.

Want to run the below examples yourself? Both are available for download here: gtm-buying-trigger-agent

Search API: when your application decides what counts as a trigger

Use the Search API when the trigger definition belongs in your application: which event types count, how strong each one is, and which accounts get an alert.

The workflow runs one news search per trigger family for each account, limited to the monitoring window.

The request:

from nimble_python import Nimble

nimble = Nimble()

WATCHLIST = [
    {"name": "Cato Networks", "descriptor": "SASE"},
    {"name": "Mark43", "descriptor": "public safety software"},
    {"name": "Veylo", "descriptor": "AI modernization"},
    {"name": "BlueVoyant", "descriptor": "cybersecurity"},
    {"name": "commercetools", "descriptor": "commerce platform"},
]

TRIGGER_FAMILIES = [
    "funding round acquisition",
    "appoints executive hire chief",
    "launches expansion partnership",
]

evidence = {
    account["name"]: [
        nimble.search(
            query=f"{account['name']} {account['descriptor']} {family}",
            focus="news",
            search_depth="lite",
            start_date="2026-09-12",
            max_results=8,
        ).results
        for family in TRIGGER_FAMILIES
    ]
    for account in WATCHLIST
}

Parameters used:

• focus="news": searches news sources, and each result carries a publish date and source name.
• start_date="2026-09-12": limits results to the 30-day monitoring window.
• search_depth="lite": titles, snippets, and URLs are enough to spot and date an event.
• Three queries per account, one per trigger family (funding and acquisitions, executive hires, launches and partnerships), with max_results=8 each: 15 searches for the watchlist.
• A short descriptor per account, such as “SASE” for Cato Networks, keeps results about the company rather than its market.

The agent passes each account’s results to an LLM step that returns triggers dated by the event rather than the article, typed (funding round, leadership hire, acquisition, customer win, and others), graded High, Medium, or Low, and linked to a source. Code then keeps only events inside the window, merges several articles about the same event into one trigger, and picks each account’s strongest trigger.

Agent API: when you want the trigger brief

If you want Nimble to research the watchlist and return the finished brief, give a Web Search Agent the accounts, the window, what you sell, and the output structure.

The request:

agent = nimble.agents.create(
    agent_name="gtm-buying-trigger-monitor",
    use_case="research",
    effort="high",
    goals=[
        "Report only events whose own date falls inside the monitoring window.",
        "Resolve each account by its domain.",
        "Return one entry per account, with its triggers nested inside it.",
        "Cite the company newsroom, blog or press release when one exists.",
        "Return one trigger per underlying event.",
        "Return trigger_count 0 instead of padding an account with weak events.",
    ],
    sources={
        "prioritize": "Company newsrooms, press releases, business and tech press",
        "avoid": "Listicles and aggregator pages that re-date old news",
    },
    output_schema=TRIGGER_SCHEMA,
)

run = nimble.agents.runs.create(
    agent.id,
    input=(
        "Monitor these accounts for buying triggers in the window "
        "2026-09-12 to 2026-10-12: Cato Networks (catonetworks.com), "
        "Mark43 (mark43.com), Veylo (veylo.com), BlueVoyant "
        "(bluevoyant.com), commercetools (commercetools.com). The seller "
        "offers revenue and go-to-market software to fast-growing B2B "
        "software companies. For each account, return every qualifying "
        "event with its date, trigger type, strength, reason and source, "
        "plus a one-sentence outreach angle."
    ),
)

Parameters used:

• use_case="research" and effort="high": open-ended research across several sources per account. The run took about four and a half minutes for five accounts.
• goals: the rules every trigger must meet. It is dated by the event, falls inside the window, cites the company’s own page when one exists, and appears once however many outlets covered it.
• sources: prioritize company newsrooms, press-release wires, and business and technology press; avoid listicles and aggregators that re-date old news.
• output_schema: one entry per account with company, domain, trigger_count, strongest_trigger, outreach_angle, and a triggers list (event_date, trigger_type, headline, why_it_is_a_trigger, strength, source_url), plus excluded_events with the reason each event was left out.

Among the results:

{
  "company": "Mark43",
  "domain": "mark43.com",
  "trigger_count": 3,
  "strongest_trigger": "Mark43 Appoints Alison Durant as Chief Marketing Officer",
  "triggers": [
    {
      "event_date": "2026-10-05",
      "trigger_type": "customer_win",
      "strength": "High",
      "headline": "San Diego County Sheriff's Office Modernizes Dispatch with Launch of Mark43 Platform"
    },
    {
      "event_date": "2026-10-01",
      "trigger_type": "leadership_hire",
      "strength": "High",
      "headline": "Mark43 Appoints Alison Durant as Chief Marketing Officer"
    },
    {
      "event_date": "2026-09-28",
      "trigger_type": "acquisition",
      "strength": "High",
      "headline": "Mark43 Acquires ForceMetrics"
    }
  ]
}

Each account arrives as a brief: every trigger is dated, typed, graded, and cited, and excluded events come back with the reason. An agent can route High-strength triggers to the account owner, open a CRM task with the outreach angle, or start an enrichment run on any account that just hired a CRO or CMO.

With the Search API, your application owns the trigger definition, the dating rules, and the ranking. With a Web Search Agent, Nimble runs the monitoring research and returns one brief per account.

Use Case 3: Company Discovery and Account List Building

Enrichment and trigger monitoring start with companies you already know.

Discovery starts with the ICP and asks a harder question: Who are we missing?

The relevant evidence is spread across funding announcements, company sites, legal-tech publications, investor portfolios, careers pages, and ATS boards. No single query produces a qualified target-account list.

For this example, the ICP was:

• US headquarters
• AI software for legal teams
• 50–500 employees
• Latest priced round is Series A, B, or C after April 1, 2025
• At least one open quota-carrying US sales role

Want to run the below examples yourself? Both are available for download here: gtm-account-discovery-agent

Search API: when the qualification logic is yours

With the Search API, discovery becomes a broaden-and-narrow workflow.

First, run several searches from different angles to produce candidate companies:

queries = [
    "legal AI startup raises Series A funding",
    "legal AI company raises Series B 2026",
    "AI for in-house legal teams startup funding round",
    "AI plaintiff law firm software startup raises funding",
    "legal tech AI Series C funding 2026",
]

pages = []

for query in queries:
    response = nimble.search(
        query=query,
        start_date="2025-04-01",
        search_depth="lite",
        max_results=10,
    )
    pages.extend(response.results)

Then deduplicate the candidates and research each one against the hard criteria.

Parameters used:

• Discovery queries from different angles: funding stage, buyer segment (in-house teams, plaintiff firms), and one more limited to legal-tech publications with include_domains.
• start_date="2025-04-01": only coverage published since the start of the funding window in the ICP.
• search_depth="lite" and max_results=10: titles, snippets, and URLs are enough to collect candidate names.
• One firmographic search per candidate (company name and domain plus funding, headquarters, and employees), search_depth="lite", 5 results.
• A sales-hiring search limited with include_domains to ATS boards and the company’s own domain, run only for candidates that pass the firmographic checks.

The agent pulls candidate companies out of the discovery results and deduplicates them. An LLM reads each candidate’s evidence against the ICP, and code-side rules make the pass or fail call, recording the failed criterion for every rejected candidate.

Agent API: when you want the finished dataset

With a Web Search Agent, the discovery objective itself becomes the input.

The Agent can search broadly, investigate candidates, navigate company and careers sites, validate the ICP criteria, and return structured rows plus near-misses.

The request:

agent = nimble.agents.create(
    agent_name="gtm-icp-discovery",
    use_case="dataset_building",
    effort="high",
    goals=[
        "Return a company only when every ICP criterion is supported by cited evidence.",
        "Never add rows simply to reach the requested count.",
        "Confirm at least one live US quota-carrying sales role.",
        "Use a dated source for employee count.",
        "Resolve and verify the company's public domain.",
    ],
    output_schema=DISCOVERY_SCHEMA,
)

run = nimble.agents.runs.create(
    agent.id,
    input=(
        "Find up to 15 US-headquartered companies building AI software "
        "for legal work. Require 50-500 employees, a most recent Series "
        "A, B or C closed on or after 2025-04-01, and at least one open "
        "quota-carrying US sales role. List near-misses with the criterion "
        "they failed."
    ),
)

Parameters used:

• use_case="dataset_building": builds a list of companies that match criteria, rather than researching one known company.
• effort="high": the minimum tier for dataset building. The run took about seven and a half minutes.
• goals: hard rules for every row. Each ICP criterion needs a cited page, rows are never added to reach the count, the sales role must be a live US posting, and headcount must come from a dated source.
• input: the ICP as hard constraints, a cap of 15 companies, and a request for near-misses.
• output_schema: a companies list (company, domain, hq, customer_segment, employee_count, latest_round, sales_role, sales_role_url, recognizability, why_it_fits, evidence_urls) and a near_misses list (company, domain, failed_criterion, reason).

Among the results:

{
  "companies": [
    {
      "company": "Supio",
      "domain": "supio.com",
      "hq": "Seattle, WA (with San Francisco office)",
      "customer_segment": "Personal injury and mass tort law firms in the US",
      "latest_round": "Series B, $60M, April 2025, led by Sapphire Ventures",
      "sales_role": "Account Executive, Mid Market (Boston/NY) - Remote US",
      "sales_role_url": "https://jobs.gem.com/supio",
      "recognizability": "Under-the-radar"
    }
  ],
  "near_misses": [
    {
      "company": "Spellbook",
      "domain": "spellbook.com",
      "failed_criterion": "Headquartered in the United States",
      "reason": "Headquartered in Toronto, Canada (with St. John's NL incorporation) - fails US-HQ requirement, despite Oct 2025 Series B ($50M, Khosla)"
    }
  ]
}

Every row links to the pages behind each criterion, including the live sales posting, and every near-miss names the criterion it failed. An agent can load the qualified rows into the CRM and send near-misses to review or a later re-check.

Each approach also qualified an account the other missed. The Agent found Supio’s open sales role on a Gem-hosted careers board, outside the fixed list of ATS boards in the Search workflow. The Search workflow found Ivo’s sales roles on Ashby and Lever, which the Agent did not verify from Ivo’s own careers page.

Combined, the two approaches produced four verified accounts:

• Eve
• GC AI
• Supio
• Ivo

That distinction is useful when designing production GTM systems.

A search engine returns pages. A company-discovery workflow needs a qualified dataset, evidence for every row, and a reason for every rejection.

The Search API gives you a deterministic pipeline you can control and audit. A Web Search Agent gives you broader research and site navigation without requiring you to encode every possible source in advance. Confidence scoring tells you where additional verification is worth spending effort.

Why Nimble Goes Deeper for GTM Research

Specialized retrieval for the task.

Finding a company name is simple. Determining whether that company meets five GTM criteria is not. Enrichment, trigger monitoring, and discovery each require different queries, sources, and evidence. Nimble lets retrieval adapt to the job rather than treating every request as the same generic search.

Go beyond the first result with site navigation.

Important GTM signals often sit deeper inside company sites and careers platforms. In the buying-trigger example, every trigger the Agent returned was cited to a page in the company’s own newsroom. In discovery, the Agent found a Gem-hosted careers board that the fixed Search workflow had not included.

Live evidence instead of a frozen company record.

Company data changes continuously. Eve’s stated customer count moved from 450 to more than 1,200 in roughly a year, while third-party headcount figures ranged from 1–10 to 376. Searching the live web gives your workflow the current page, announcement, or job posting alongside the value itself.

Full research orchestration.

Web Search Agents can handle planning, search, navigation, extraction, cross-checking, structured output, and confidence scoring. Instead of writing the entire research loop yourself, you define the objective and the shape of the answer.

Structured output for downstream systems.

Every workflow in this post ends in something another system can consume: a company profile, a per-account trigger brief, or a qualified account list. Pass an output_schema and the research comes back as structured JSON with citations and confidence attached to individual claims.

Research that can improve across recurring runs.

Web Search Agents support persistent agent memory across repeated use cases, including source and retrieval patterns that proved useful before. For recurring enrichment, qualification, or market-mapping workflows, that means the Agent can reuse what it has learned instead of approaching every run from scratch.

How to Get Started with Nimble’s Search API and Web Search Agents

We suggest starting by testing Nimble with your own AI assistant. Give it this link to get set up.

To embed Nimble into your GTM workflows:

• Explore Nimble’s integrations with LangChain, LlamaIndex, LiteLLM, and other AI frameworks.
• Install the Nimble SDK for your preferred language.
• Or connect through the Nimble MCP Server.

Before you do any of these things, start a free trial.