Introducing the Wiley x Valyu HLS Startup Program
Valyu
A woodworker shaping a timber board at a workbench, surrounded by tools and wood shavings.
Tutorial

How to Find Acquisition Targets from an Investment Thesis Using AI

Prosper
Share this article

On this page

TL;DR

To find acquisition targets from an investment thesis, turn the thesis into explicit criteria, use Valyu DeepResearch to discover and investigate candidate companies, and keep the evidence behind each match. Separate supported matches, unresolved questions and clear mismatches before deciding which companies deserve further diligence.

This tutorial builds a source-backed research queue in Python and TypeScript. The example looks for UK-headquartered software businesses serving trades such as plumbing, heating and electrical maintenance. It produces a CSV and an evidence file, not a claim that any company is for sale or a recommendation to acquire it.

If you're an agent: Set up Valyu and make your first search.

If you're a human: Create an account and get an API key.

MCP onboarding: Connect your agent to https://mcp.valyu.ai/mcp and follow the MCP setup guide for authentication.

What will this acquisition-sourcing workflow produce?

Suppose your acquisition team wants to expand a software platform serving small trade businesses. The brief is straightforward:

Find UK-headquartered vendors with their own job-management or field-service software for plumbers, heating engineers, electricians and similar businesses. Check the company behind each product and whether it is an independent business or already part of a larger software group.

The next decision is not “which company should we buy?” It is “which companies should enter our diligence queue, and what must we establish before contacting them?”

The application writes:

  • candidates.csv: company, website, criterion-level statuses, ownership notes, financial-data gaps and source URLs.
  • evidence.json: the research response and source catalogue, so the evidence remains available for review.
  • task.json: the task ID, saved before the application waits for the result.

The dated example below returned eight research leads. After reviewing the evidence, all eight still needed ownership verification. That is an unresolved sourcing queue, not eight qualified acquisitions.

For each company, the queue is derived from three evidence checks:

CheckWhat counts as supportWhat is not enough
UK headquartersEvidence identifying the company's headquarters in the UKSelling to UK customers or having a UK registration alone
Trade-SMB softwareA proprietary product explicitly serving trade or field-service businessesA generic software consultancy or unrelated project tool
Independent companyPositive evidence about the operating company and ownershipAssuming independence because no acquisition announcement appeared in a search

Sponsor backing does not automatically disqualify a company. The question is what the ownership evidence actually establishes. A known group-owned product fails this particular initial screen, not a universal rule that subsidiaries can never be acquired.

Figure 1. The useful output is a research queue with evidence and open questions. It is not a list of confirmed transaction opportunities.

A company-name search answers a lookup question. Acquisition discovery starts before you know the company names. It needs several related steps: discover businesses, resolve company and product identities, inspect customer fit, check location, and investigate ownership.

Valyu DeepResearch performs that multi-source investigation. Your application defines the thesis and output contract, saves the task, and checks the returned evidence. It does not need a separate model-provider API key.

NeedUseWhat remains your responsibility
Find evidence about a known companySearchVerify entity identity, dates and source support
Read a known company or investor pageContentsCheck that the page answers the criterion
Discover and investigate a candidate setDeepResearchReview the evidence, resolve gaps and decide the next diligence action

For a larger diligence workflow, see Valyu for private equity. This example does not replace a complete market database, transaction process or financial due diligence.

Step 1: write the thesis as checkable criteria

Use criteria that public evidence can establish. “Has field-service software for heating engineers” is researchable from product and customer pages. “The owner wants to exit this year” usually is not.

Do not quietly turn an investment preference into a fabricated fact. If your mandate requires a revenue or EBITDA range, preserve an unverified value as unknown until reliable disclosure or direct diligence establishes it.

The example's research specification asks for up to eight companies, including useful near-matches that fail a criterion. It prioritises official company, product and ownership sources and requests three states for every check:

  • supported: evidence affirmatively supports the criterion.
  • contradicted: evidence establishes a mismatch.
  • unknown: evidence is missing, inaccessible or ambiguous.

“Unknown” is not a weak match. It is a different next action: resolve the evidence gap before advancing the company on that criterion.

The runnable example bundle contains the exact research specification, JSON Schema, both clients and the local checks. The thesis is in research-spec.json; the structured output contract is in runtime-schema.json. Start with those files when adapting the example.

Step 2: create the research task with Python or TypeScript

Set VALYU_API_KEY in your server environment. Keep the key out of source files and logs. Install valyu==2.13.1 for Python, or valyu-js@2.11.1 for TypeScript. The complete Python client needs Python 3.11 or later; the TypeScript client runs directly with Node.js 24.2 or later.

The core request is the same in either SDK. It uses standard mode, currently 100 credits per task, with no optional tools or file deliverables. Check current pricing before running. The CSV is generated locally from the structured result.

import json
from pathlib import Path
from valyu import Valyu
 
spec = json.loads(Path("research-spec.json").read_text())
schema = json.loads(Path("runtime-schema.json").read_text())
client = Valyu()
 
task = client.deepresearch.create(
query=spec["query"],
mode="standard",
research_strategy=spec["research_strategy"],
report_format=spec["report_format"],
output_formats=[schema],
)
if not task.success or not task.deepresearch_id:
raise RuntimeError("No task ID returned; inspect before retrying")
 
Path("task.json").write_text(json.dumps({
"deepresearch_id": task.deepresearch_id
}))
print("Saved task ID:", task.deepresearch_id)

These snippets show task creation, which is paid. Do not rerun them just because a client times out or an ID was not returned. Check the existing submission first. The full clients in the bundle add an explicit start command and a local submission reservation so ordinary reruns do not silently start another research job.

To run a new investigation with the complete client, choose one language:

Shell
python discover_targets.py start --approve-standard
 
# Or, after installing the TypeScript package dependencies:
node discover-targets.ts start --approve-standard

Do not run both start commands for the same question unless you intend to create two paid tasks. The Python and TypeScript implementations can inspect the same task ID instead.

Step 3: resume the task and build the candidate queue

Once the ID is saved, later executions should resume that task rather than create another. With the complete clients:

Shell
python discover_targets.py resume --task-id YOUR_SAVED_TASK_ID
 
# Or:
node discover-targets.ts resume --task-id YOUR_SAVED_TASK_ID

The clients wait for the saved task and render only a completed result. A failed or still-running task is not a finished candidate list. A local wait timeout does not cancel the remote task; keep the ID and inspect its status.

The local checks reject missing criteria, invalid states, duplicate company domains and supported/contradicted claims without sources. Each criterion URL must belong to the returned source catalogue. Fragment markers are normalised so a passage link can match its underlying source.

Then the application derives a queue:

Returned criterion statesQueueNext action
All supportedadvanceHave an analyst verify the evidence before deeper diligence
No contradiction, at least one unknownreviewResolve the missing location, product or ownership information
Any contradictionexcludeRecord which part of this thesis the company fails

Figure 2. These rules organise the returned research. They do not prove that the underlying classifications are correct.

For offline inspection of a response already saved on disk, use render --response response.json. That step makes no research API call.

What did the acquisition-target example return?

On 27 October 2026, one standard-mode research task returned eight candidate entries and 86 catalogue sources. Those are counts from this run, not a promised result size or evidence that 86 sources support every company.

The raw output marked all 24 criterion checks as supported. We did not accept that as a verified shortlist:

  • The local validator stopped because two distinct cited URLs did not exactly match the returned catalogue. One redirected to a catalogue URL; the other could not be independently fetched and was removed from the reviewed checks. We did not silently add it to the original catalogue.
  • Reviewing the company evidence left eight independence checks and four headquarters checks unresolved. A founder biography, private limited status, a registered office or an old funding announcement did not establish everything the thesis required.
  • The reviewed copy therefore produced eight review entries, zero advance entries and zero exclude entries. It preserved the leads and the questions, rather than manufacturing a qualified list.
Company or product surfacedWhat the checked material supportsNext research action
The official team page explicitly places headquarters in London; its plumbing page describes trade softwareVerify current controlling ownership and independence
The vendor describes software for UK trades; its company information states UK headquartersVerify current controlling ownership rather than infer it from private-company status
The official site describes heating/plumbing software and UK office locationsResolve the operating entity, headquarters and ownership
The product page describes job management and gas-compliance software for UK gas engineersVerify company headquarters and ownership; the founder's location is not a headquarters record
The vendor describes plumbing software and identifies a UK registered officeVerify operational headquarters and current controlling ownership
The contact page distinguishes a London main office from an Amersham registered officeVerify current controlling ownership and independence
The vendor describes a Lichfield-based team and identifies Onsite Pro as a RUN PHP Ltd productResearch the operating company, not just the product brand
The careers page identifies a Bristol office and software for clean-energy installersConfirm headquarters and current ownership rather than rely on historic funding reports

These are research leads, not verified acquisition opportunities. The strict screen did not establish a company that could advance automatically. The outcome was still useful: eight businesses or brands to investigate, with specific unresolved criteria rather than an unsupported acquisition score.

The original response is retained separately from the editorially reviewed copy. Both SDK clients resumed the same completed task and both blocked the raw citation mismatch. Python and TypeScript then rendered the same CSV from the separately reviewed response. This does not mean the unmodified agent output passed the checks.

The run did not return a clear negative near-match, despite the request. The exclude rule was checked with offline fixtures, not presented as a live rejection from this investigation. A later run may surface different companies and evidence.

To inspect this checked example without another API call, the bundle includes reviewed-response.json:

Shell
python discover_targets.py render --response reviewed-response.json
 
# Or:
node discover-targets.ts render --response reviewed-response.json

For a new run, investigate validation failures and review the evidence before preparing a separate reviewed copy. Do not weaken catalogue checks or relabel missing information just to make the CSV look complete.

What should you verify before advancing a candidate?

Read the original pages behind the criteria. A URL belonging to a research source catalogue does not prove that its content supports the claim.

  • Company identity: confirm the actual business and its product brands. Domain deduplication alone does not resolve subsidiaries, rebrands or parent companies.
  • Headquarters: distinguish operational headquarters from a registered office, a branch or the countries where customers operate.
  • Product and customer fit: check product pages and customer examples. Generic “small business” positioning is not the same as explicit trade/field-service fit.
  • Ownership: use dated company/investor announcements or other reliable disclosure. Missing ownership evidence remains unknown.
  • Financial fit: do not turn missing revenue or EBITDA into zero, an estimate, or an assumed fit to a mandate.
  • Transaction availability: a product match does not establish that the owner wants to sell, that a sale process exists or that the business is affordable.

The outcome is a better diligence queue: a company worth investigating, a specific question to resolve, or a reason to stop researching a mismatch. Human review owns that decision.

How to adapt the workflow to another acquisition thesis

Change the industry, geography, product/customer criteria and ownership requirements together. Update the schema and local checks if the number or meaning of the criteria changes.

For a scientific acquisition thesis, the evidence may span company materials, clinical-trial records, papers and patents. For a public-company screen, filings can establish reported metrics and risks. The financial research-agent tutorial shows how to preserve those periods, claims and citations.

Keep discovery separate from enrichment. First determine whether a company belongs in the candidate set. Then investigate a shortlisted business in more depth. Researching a known company and discovering a company from a thesis are different jobs.

For recurring sourcing, add application-owned scheduling, saved snapshots and review history. For production task completion, prefer webhooks over keeping a request open while waiting. Do not describe those application features as a native acquisition-monitoring product.

FAQ

Does this find companies that are currently for sale?

No. It finds businesses to investigate against a thesis using available evidence. Sale processes, owner intent and transaction terms require separate verification and often direct conversations.

Can I filter private companies by revenue or EBITDA?

Only when reliable evidence establishes those values and the reporting period. This example leaves unsupported financial information unknown. A private-company revenue estimate is not the same as a disclosed figure.

Is the result a complete acquisition universe?

No. It is a bounded research run, not a census of every matching business. Source coverage, the question, access and research budget affect what it finds. Retain rejected candidates and limitations rather than treating absence as proof a company does not exist.

Does sponsor backing mean a company should be excluded?

Not automatically. A sponsor-backed operating company can still be relevant to an acquisition thesis. This example asks for the actual ownership evidence and distinguishes a business from a product already absorbed into a larger group.

Do the local checks fact-check the companies?

No. They validate output structure, source-catalogue membership, basic domain duplication and queue rules. A reviewer still checks source support, dates, corporate identity and the investment mandate.

Do I need a separate LLM API key?

No. Valyu DeepResearch performs the hosted investigation. The example uses a Valyu key and ordinary Python or TypeScript code to manage the task and output.

What happens if the client stops waiting?

The research can continue remotely. Resume the saved task ID or inspect status before creating another. If creation itself returns no ID, inspect your task list instead of immediately resubmitting.

Build your acquisition-sourcing workflow

Start with a checkable thesis, retain the evidence behind each criterion, and keep the unresolved questions visible. Explore Valyu's private-equity workflows, compare investment research APIs, or give your agents access to Valyu.

Valyu Add

Join 12,000+ professionals and knowledge workers.

Valyu Add is a free weekly research briefing for builders, investors and operators. Every issue is sourced, cited and verified with Valyu DeepResearch.