Building a market map an agent can defend and keep current

A market map looks like a slide: a grid of logos sorted into neat boxes. The slide is the last and least important part. Underneath it sits a dataset, and that dataset is only as good as three decisions made before any search runs: what the category is, what it takes to belong in it, and how you will know what you missed. This guide walks through building that dataset with an agent doing the collection: defining the category, writing inclusion criteria a machine can test, gathering candidates with evidence attached, reporting coverage limits honestly, and keeping the map from going stale the week after it ships.

Start with the decision the map supports

Maps get built for different reasons, and the reason shapes everything downstream. A product team deciding whether to build or partner needs to know which capabilities are already well served. A corporate development team needs a screen of possible targets, with size and ownership. A founder writing a pitch needs a credible view of where the gaps are. The same category can produce three quite different maps.

Write one sentence that names the decision and the reader. “Help the product team decide whether to build invoice capture in house, by showing who already sells it to mid-size companies in Europe and Turkey” is specific enough to tell an agent what to look for and, more usefully, what to ignore.

Define the category before the first query

Vague categories produce maps that cannot be checked. “AI for finance” has no edges; any company with a chatbot and a bank customer can claim to be in it. A usable definition states the unit, the boundary and the exclusions explicitly:

category   software that captures and codes supplier invoices automatically
unit       one row per product (a company with two products gets two rows)
includes   standalone products and modules that can be bought separately
excludes   outsourced bookkeeping services, generic OCR toolkits,
           products that have been discontinued
market     sold to mid-size companies, available in Europe or Turkey

Then list the boundary cases you can already predict and decide them in writing. Does a suite that bundles invoice capture count, or only if the module is priced separately? Does an open-source project with a paid hosted version count? What about a product that was acquired and folded into another brand? Each answer is partly arbitrary, but it has to be made once, recorded, and applied to every candidate. If you change it halfway through, you are building a different map, and the work so far needs a fresh look; a changed question needs a new plan, not a quiet patch.

Turn the definition into criteria an agent can test

An agent cannot apply “is a serious player in the space”. It can apply a criterion that resolves to yes, no or unknown from something it can read. Rewrite each part of the definition that way, and say what evidence settles it.

Keep inclusion criteria separate from descriptive columns. Inclusion decides whether a row exists. Descriptive columns, such as target segment, deployment model or headquarters, decide where it sits on the map. Mixing the two leads to products being dropped because a descriptive field was hard to find.

Each row should then carry its evidence, not just its verdict:

{
  "product":   "Example Capture",
  "domain":    "example.com",
  "criterion": "captures supplier invoices automatically",
  "verdict":   "yes",
  "quote":     "Upload or forward invoices; fields are read and coded for you.",
  "source":    "https://example.com/product",
  "retrieved": "YYYY-MM-DD"
}

Collect wide, then verify narrow

Discovery and verification are different jobs and work better as separate steps. Discovery should favor recall: find every plausible name, and record where each one was found. Verification should favor precision: test each candidate against each criterion using a primary source, usually the vendor's own pages.

Useful discovery routes for a software category include varied search phrasings (the words buyers use, not only the industry term, and queries in local languages), category listings in app marketplaces and integration directories, exhibitor lists from trade events, the alternatives and comparison pages vendors publish about each other, job postings that name the category, investor portfolio pages and, for some categories, business registries. Each route has a bias. Marketplaces over-represent products that integrate with that platform; search over-represents companies that invest in content.

A few design choices make the agent's output much easier to trust:

• Resolve entities early. Normalize on domain, merge rebrands and record parent companies, or one product will appear three times under three names.
• Give the verifier fresh context. Let it read sources for itself rather than inheriting the discovery step's reasoning, so a confident guess upstream does not become a confirmed row downstream.
• Allow unknown. A criterion with no readable evidence stays unknown, and the row goes to a borderline list for a person. Missing evidence is an open question, not a no.
• Budget per candidate. Cap the pages and tool calls each verification may use, so a few hard cases cannot consume the whole run.

This is the shape FindAll is built around in GoCux: you state matching criteria and the columns you want, and the result is a table in which each row brings its own evidence. GoCux does not crawl the open web itself; pages come in through an authorized browsing or export step and keep their original address and retrieval date, which is exactly the provenance a map row needs.

Report coverage, do not imply it

The most common dishonesty in market maps is unintentional: a map with forty logos reads as “the forty companies in this market”. Nobody claimed completeness, but nobody denied it either. A result count tells you how many rows you have, not how many companies exist.

You cannot know the true size of a market, but you can estimate how far you are from its visible edge. Run two discovery routes that are as independent as you can make them, for example marketplace listings and search, and compare what each found. If most candidates from the second route were already on your list, you are probably close. If the second route keeps surfacing new names, the map is still thin. Repeat with a third route when the decision is important.

Then write the limits down next to the map, where readers will see them:

coverage note
  routes used    marketplace listings, search (EN + TR), event exhibitor lists
  overlap        second route mostly confirmed the first; event lists added a few
  known gaps     products sold only through resellers; companies without a
                 public website; local-language markets other than Turkish
  borderline     listed separately, with the criterion that is still unknown

A coverage note costs a few minutes and saves the reader from drawing conclusions the data cannot support, such as “nobody does this in Turkey” when the real finding is “we found nobody with a Turkish-language site”.

Keep the map current without rebuilding it

Markets move. New entrants appear, products are discontinued or absorbed after an acquisition, companies rebrand, and products drift out of the category as they pivot. A map has a shelf life, and it should say when it was last verified.

Treat the first verified version as a baseline and watch for change against it, rather than re-running everything from scratch. A practical split:

• Existing rows: watch the pages that carried the evidence, such as product, pricing and newsroom pages, and flag changes that touch an inclusion criterion. A wording edit is noise; a sunset notice is not.
• New entrants: re-run discovery on a slower cycle and send only new names to verification.
• Events: acquisitions and funding change the descriptive columns; the guide to tracking funding rounds and M&A covers the sources.

Every detected change should arrive as a proposal for a person to accept, not as an automatic edit. In GoCux, Pulse runs a recurring question over sources you pick, with the cadence and the meaning of a material change approved in advance, and each change is reviewed one at a time; a detected change never edits anything by itself. Version the map, so that anyone citing it can say which version they used. Setting a baseline before you monitor explains why that first snapshot matters so much.

Before you publish the map

• The decision and the reader are written in one sentence at the top.
• The category has a unit, a boundary and written exclusions, and the boundary cases are decided.
• Every inclusion criterion resolves to yes, no or unknown, with a stated kind of evidence.
• Every row carries a quote, a source address and a retrieval date per criterion.
• Unknowns sit on a borderline list instead of being silently included or dropped.
• A coverage note lists the discovery routes, their overlap and the known gaps.
• The map is versioned and dated, with a plan for watching existing rows and finding new ones.

Once the map exists, it feeds other work: competitor analysis goes deeper on a few rows, and market research reports turn the dataset into a narrative.