How to write a good sourcing brief for company data

A sourcing brief is the document an AI lab sends when it wants us to go out and find companies whose data fits a specific need. The better the brief, the tighter the target list, the more useful the calls our reps make and the faster usable data starts arriving. This post covers what a good brief contains and how to avoid the ones that stall.

Before any filters, say what you plan to do with the data. Agent training, RL environments, post-training and evaluations each want slightly different things.

An evaluation set might need fewer companies but clean, well-bounded tasks with clear outcomes. An RL environment might need enough depth in one tool stack to rebuild a realistic workspace. Post-training might need breadth across many companies and roles. A sentence or two on the use case lets us make sensible trade-offs when a candidate company is a near miss on one filter but strong on another.

You do not need to share anything confidential about your models. "We are building evaluations for agents that triage support tickets end to end" is enough.

Every brief we work from covers the same core fields. Being specific on each one is the single most useful thing you can do.

• Sector. Name the industries, and be as narrow as is useful. "B2B software" is broad; "vertical SaaS for logistics and field services" gives our team something to search on.
• Headcount. Give a range. Headcount drives how many people, conversations and parallel projects appear in the data.
• Tool stack. List the systems that must be present and those that are nice to have. For example: Slack and Jira required, GitHub preferred, Salesforce or HubSpot a bonus.
• Years of history. State a minimum. Two years shows a few cycles; five years shows reorganizations, tool migrations and long-running projects.
• Regions. Note where companies should be based, or where their operations and customers should be. Language matters here too.
• Operating vs. winding down. Say whether you want operating companies, companies that are closing or have closed, or both. Each brings different timing and different conversations.

The most common reason a campaign is slower than it needs to be is that every criterion is written as a requirement. A brief that demands a specific sector, a narrow headcount band, five years of history, four specific tools and one region can describe a very small pool of companies.

Mark each criterion as required or preferred. If Jira is essential because your environment is built around it, say so. If you would accept Linear or Asana as long as the project data links to code, say that instead. Flexibility on one or two dimensions often makes the difference between a handful of candidates and a healthy pipeline.

It also helps to rank the preferences. If we have to choose between a company with more years of history and one with a more complete tool stack, which would you take?

The value of company data comes mostly from connection depth: the same project traceable across several tools. A company with modest message volume but tight links between tickets, pull requests, chat and email is usually more useful than a larger company whose tools barely reference each other.

If your use case depends on specific connections, describe them. "We need support tickets that link to engineering issues and then to merged code" tells us what to check during evaluation. It also helps our reps explain to a seller why their particular setup is a good fit.

Exclusions save time on both sides. If you already hold data from a certain type of company, or a sector is out of scope for policy reasons, put it in the brief. The same goes for data types: if you do not need images, or have no use for CRM data, say so, and we can leave it out of the evaluation and the anonymization work.

Sellers set their own scope and exclusions too, so the final dataset is always the overlap between what you asked for and what the company chose to include. Knowing your must-haves helps us spot early when a seller's exclusions would remove the part you care about most.

Imagine a lab building agents for engineering teams. A workable brief might read like this. Sector: B2B software, any vertical. Headcount: 30 to 300. Tools: Slack and GitHub required; Jira or Linear required; a support tool preferred. History: at least three years. Regions: US, Canada and EU. Status: operating or winding down, no preference. Use case: training and evaluating agents that take a ticket from report to merged fix. Must-have connection: tickets linked to pull requests.

That is short, specific and honest about priorities. From it our team can build a target list using company and technographic data, and our reps know exactly what to listen for when they reach someone who can sign.

Once we have the brief, we build the target list, our onshore reps call the people with authority to sign, and qualifying companies move through a read-only evaluation, in-house anonymization and seller sample review. Data is delivered on a rolling basis as each company completes, so you see results before the whole campaign is done. Briefs can be revised as early deliveries tell you more about what works.

If you have a need in mind, send us a sourcing brief. It does not have to be perfect; we will help you tighten it on the first call.