
How to Find Acquisition Targets from an Investment Thesis Using AI
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:
| Check | What counts as support | What is not enough |
|---|---|---|
| UK headquarters | Evidence identifying the company's headquarters in the UK | Selling to UK customers or having a UK registration alone |
| Trade-SMB software | A proprietary product explicitly serving trade or field-service businesses | A generic software consultancy or unrelated project tool |
| Independent company | Positive evidence about the operating company and ownership | Assuming 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.
Why use DeepResearch instead of a company-name search?
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.
| Need | Use | What remains your responsibility |
|---|---|---|
| Find evidence about a known company | Search | Verify entity identity, dates and source support |
| Read a known company or investor page | Contents | Check that the page answers the criterion |
| Discover and investigate a candidate set | DeepResearch | Review 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 jsonfrom pathlib import Pathfrom valyu import Valyuspec = 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:
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:
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 states | Queue | Next action |
|---|---|---|
| All supported | advance | Have an analyst verify the evidence before deeper diligence |
| No contradiction, at least one unknown | review | Resolve the missing location, product or ownership information |
| Any contradiction | exclude | Record 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
reviewentries, zeroadvanceentries and zeroexcludeentries. It preserved the leads and the questions, rather than manufacturing a qualified list.
| Company or product surfaced | What the checked material supports | Next research action |
|---|---|---|
| The official team page explicitly places headquarters in London; its plumbing page describes trade software | Verify current controlling ownership and independence | |
| The vendor describes software for UK trades; its company information states UK headquarters | Verify current controlling ownership rather than infer it from private-company status | |
| The official site describes heating/plumbing software and UK office locations | Resolve the operating entity, headquarters and ownership | |
| The product page describes job management and gas-compliance software for UK gas engineers | Verify company headquarters and ownership; the founder's location is not a headquarters record | |
| The vendor describes plumbing software and identifies a UK registered office | Verify operational headquarters and current controlling ownership | |
| The contact page distinguishes a London main office from an Amersham registered office | Verify current controlling ownership and independence | |
| The vendor describes a Lichfield-based team and identifies Onsite Pro as a RUN PHP Ltd product | Research the operating company, not just the product brand | |
| The careers page identifies a Bristol office and software for clean-energy installers | Confirm 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:
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.
Related Blogs
The Funds Furthest Ahead on AI Research Are Building Their Own Platforms
How to Build a Financial Research Agent with Valyu
The Best Investment Research APIs for AI Agents in 2026
How AI Is Reshaping Investment Research: Evidence from 4.2 Million API Queries
More from the blog





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.
