Build an M&A Research Bot on Twin.so

An M&A research bot can collect company facts, scan public sources, and prepare a first-pass deal brief before an analyst opens a spreadsheet. Twin.so fits this workflow because it can combine plain-language instructions, browser actions, web search, APIs, and scheduled runs.

The bot should not make an investment decision. It should collect evidence, structure findings, flag conflicts, and send uncertain items to a human reviewer. Start with a narrow research workflow, then expand it after the outputs become reliable.

What the M&A Research Bot Should Do

M&A research usually starts with scattered tasks. An analyst searches the target’s website, reviews filings, checks ownership records, reads industry news, compares competitors, and records every source manually.

Each task looks manageable. The full process is slower because the information sits across different websites and formats. Some sources have APIs. Others require browser access. Some pages use dynamic content, while others publish PDFs or scanned documents.

Twin.so can sit above these systems as an agent and workflow layer. Its natural-language builder lets you describe the result you want. Its browser automation can work with sites that lack usable APIs. Its connectors can handle systems that already expose structured data. The workflow can also run on a schedule or respond to a webhook.

A useful first version should return:

• A verified company profile.
• Ownership and transaction information.
• Products, customers, markets, and competitors.
• Reported financial information.
• Recent company and industry developments.
• Potential diligence questions.
• A source record for every material claim.
• A clear label for reported, inferred, conflicting, or missing data.

This scope keeps the bot focused. It also prevents a common failure mode, where a single prompt asks for every possible fact and returns an uneven report that nobody can audit.

AI due diligence systems already focus on document review, data extraction, and research acceleration. This AI due diligence workflow overview provides useful context, but the same principle applies to a custom Twin.so workflow: automation should reduce manual collection without removing professional review.

Plan the Workflow Before Opening Twin.so

A reliable bot starts with a process map. Write down what enters the workflow, what actions the agent takes, and what output the team needs.

Use one target company and one research purpose for the first test. For example, you might build a public-company profile for an initial acquisition screen. Do not begin with confidential data room files, legal contracts, employee records, and financial models in the same run.

Define the input fields first:

• Target company name.
• Official website.
• Country or operating region.
• Known legal entity name.
• Research date.
• Research purpose.
• Required output destination.

Then define the source hierarchy. Official filings and government records should outrank company summaries or third-party databases. Company websites can support product, leadership, and market information. Reputable publications can support transaction announcements and external developments.

Use the following order where it fits the target:

Research area	Preferred source	Backup source
Public filings	Official regulator or exchange	Company investor relations site
Ownership	Corporate registry or filing	Reputable business database
Products	Company website and filings	Industry publication
Transactions	Filing, press release, regulator	Reputable financial publication
Market activity	Government data or research source	Trade publication
Competitors	Company filings and market sources	Analyst review

Set the stopping rules before you build. The bot should stop when a source requires a login that has not been approved, a page returns no data, a document is unreadable, or two sources report materially different figures.

A bot that reports uncertainty is more useful than one that fills every empty field with a confident guess.

Your workflow should also define where results go. A spreadsheet works for an initial test. Airtable, Notion, an internal database, or a deal-management system may work better once multiple analysts use the process.

How to Build an M&A research bot on Twin.so

Open Twin.so and create a new agent or workflow. The exact interface can change, but the build logic remains the same. Describe the outcome first. Then add the actions, sources, output structure, and review controls.

Step 1: Define the bot’s job

Start with a narrow build prompt. Tell Twin.so what the agent should research, what it must not do, and how it should handle missing information.

Build an M&A research workflow for public-source target screening. Accept a company name, official website, country, and research date. Collect company identity, ownership, products, markets, leadership, disclosed financial figures, recent transactions, competitors, and material news. Use official and first-party sources before secondary sources. Record the source URL, page title, publication date, access date, and supporting excerpt for every material claim. Mark missing information as “Not found.” Never infer undisclosed revenue, ownership, valuation, or transaction terms.

This prompt creates the operating boundary. It also gives the agent an output goal instead of asking it to behave like a general-purpose chatbot.

Step 2: Add the source actions

Use web search for open research. Add browser actions for public websites that require navigation or page interaction. Use direct integrations where a source offers a stable API.

The browser agent can navigate pages, submit search fields, download documents, and extract content. Keep browser workflows narrow. A filing page, company profile page, and news archive may each require different navigation instructions.

If an API is available, use it for structured records. Direct data retrieval is usually easier to test than browser extraction. Browser automation adds access to websites without APIs, but it can fail when layouts change, login sessions expire, or content loads dynamically.

Add a wait instruction for pages that need time to render. Tell the agent to capture the final page URL after navigation. If it downloads a file, preserve the original file and record the download time.

Step 3: Create the input form

Your input form should contain only the fields the workflow needs. A simple form reduces errors at launch.

Use these fields:

1. Target company name.
2. Official website.
3. Jurisdiction.
4. Legal entity name, if known.
5. Research scope.
6. Output destination.
7. Review owner.

Require the analyst to confirm the official website before the run. Company names often match unrelated entities. The domain is a useful identity check, but it isn’t proof of ownership or legal status.

Step 4: Configure the output

Ask Twin.so to return structured fields instead of a long narrative. A structured result is easier to compare, export, and review.

Require one record per claim where practical. Each record should contain the field name, extracted value, source, date, confidence label, and reviewer status.

Do not let the agent convert an absence of evidence into a negative conclusion. “No public information found” is different from “the company has no debt” or “the company has no acquisition history.”

Step 5: Add a review gate

Configure the workflow to pause before it sends results to a deal team or writes to a permanent system. The reviewer should confirm the target identity, source quality, material figures, and unresolved conflicts.

A review gate matters most for:

• Revenue, EBITDA, cash, debt, and valuation figures.
• Ownership percentages.
• Transaction dates and consideration.
• Litigation, regulatory, or sanctions information.
• Customer concentration.
• Claims about market position.
• Any output used in a board or investment committee document.

Twin.so supports workflows that can route results and produce deliverables. Use that capability to prepare a review package, not to approve a transaction automatically.

Write Prompts for Financial Research

A weak prompt asks Twin.so to “research the company and provide insights.” That instruction leaves too much room for inconsistent scope and unsupported conclusions.

A stronger prompt defines five things:

1. The target and research period.
2. The sources the bot should prioritize.
3. The fields it must extract.
4. The evidence it must attach.
5. The rules for missing or conflicting data.

Use separate prompts for separate research tasks. A company profile prompt should not also perform valuation analysis or legal document review.

For company facts, use:

Research [company name] using public sources available as of [date]. Confirm the legal name, official website, headquarters, operating countries, founding year, ownership, products, customer segments, employee count if disclosed, and named competitors. For each field, return the value, source URL, page title, publication date if available, access date, and a short supporting excerpt. Label each result as Reported, Conflicting, Inferred, or Not found. Do not estimate missing values.

For transaction screening, use:

Find publicly reported acquisitions, mergers, divestitures, investments, and announced strategic transactions involving [company name] between [start date] and [end date]. Prioritize regulatory filings, exchange announcements, company releases, and reputable financial publications. Return announcement date, parties, transaction type, disclosed consideration, status, and source evidence. Separate announced, completed, terminated, and rumored transactions. Do not treat a rumor as a completed deal.

For conflict checking, use:

Compare the extracted figures and claims across all collected sources. Identify differences in revenue, ownership, employee count, transaction status, and dates. Do not choose a preferred value without evidence. Return each conflicting value, the supporting source, the likely reason for the difference if stated by a source, and a reviewer question.

Use plain instructions. Avoid asking the agent to “think like an investment banker” or “deliver a definitive view.” Those phrases don’t create a measurable workflow.

Prompts should also specify the reporting period. A current company page may show a different period than an annual filing. Without a date boundary, the bot can combine facts that don’t belong together.

Build Source Traceability Into Every Run

Source traceability is the difference between a useful research assistant and an unverified summary.

Require the bot to capture the original URL, page title, source type, publication date, access date, and exact supporting passage. For downloaded documents, store the filename, document date, and original file. If the source is a PDF, record the page number when the extraction process provides it.

Use a separate source record for each important claim. One source can support several fields, but the output should still show which fields came from it.

A source record should include:

Field	Required content
Claim	The exact fact being reported
Value	The extracted value or statement
Source	Full URL and page title
Timing	Publication date and access date
Evidence	Short quote or document reference
Status	Reported, Conflicting, Inferred, or Not found
Reviewer	Person responsible for validation
Decision	Accepted, changed, rejected, or unresolved

Keep the bot from copying entire articles into the output. Short excerpts support review without creating an unnecessary document archive.

The agent should also identify source quality. An official filing may support a disclosed revenue number. A company blog may support a product launch. A third-party profile may provide a lead, but it should not automatically outrank a filing.

Use the sample output structure below in the workflow instructions.

Sample M&A research output template

Research metadata

• Target company:
• Official website:
• Legal entity:
• Jurisdiction:
• Research scope:
• Research date:
• Agent run ID:
• Reviewer:
• Overall status:

Executive profile

• Business description:
• Primary products:
• Customer segments:
• Operating regions:
• Ownership:
• Public or private status:
• Key competitors:

Financial information

Metric	Value	Period	Currency	Source	Status
Revenue
EBITDA or operating profit
Cash
Debt
Employee count

Transaction history

Date	Parties	Type	Consideration	Status	Source

Research questions

• Which figures require confirmation?
• Which sources conflict?
• Which claims lack primary evidence?
• What information should be requested from management?
• Which legal, regulatory, customer, or market topics need specialist review?

Source log

Source ID	URL	Title	Source type	Access date	Claims supported
S-001

This structure gives an analyst a usable starting point. It doesn’t turn collected data into a completed diligence conclusion.

Run a Public-Source Research Workflow

Test the bot with one public target before adding schedules or downstream integrations. Use a company with a clear official website and accessible filings.

Enter the target details. Start the run. Watch the first execution instead of leaving it unattended. Record where the agent pauses, which pages it cannot read, and whether it repeats the same source.

Check the output in this order:

1. Confirm that the bot researched the correct legal entity.
2. Check that the source dates fit the requested period.
3. Open each source supporting a material financial claim.
4. Compare reported figures with the original filing or release.
5. Review the status labels.
6. Check for duplicate sources and duplicate claims.
7. Confirm that missing data remains blank or marked Not found.
8. Approve only the records that pass review.

The bot should create an exception when a page is blocked, a document is empty, a login is required, or a source provides conflicting information. The exception should identify the source, failed action, time of failure, and next review step.

“Task failed” is not enough. A useful message says that the investor-relations PDF for a given reporting period could not be downloaded, or that two sources report different ownership percentages.

After the manual test works, add a schedule for recurring monitoring. A monthly or weekly run can look for new filings, acquisition announcements, leadership changes, and material company news. Use a webhook when another system needs to start the research process.

Don’t run recurring monitoring against every possible website. Choose a small source list and review false positives before expanding it.

For broader context on current AI tooling in M&A diligence, compare the workflow boundaries described in this M&A diligence tools guide. The relevant question isn’t whether a tool produces a polished report. The question is whether the report can be checked.

Protect Deal Data and Credentials

Public research is the safest starting point. Confidential deal information requires a separate review of your firm’s security policy, vendor terms, access controls, retention settings, and approved integrations.

Don’t paste passwords, API keys, personal identification numbers, or sensitive employee information into a prompt. Use approved authentication connections where available. Limit each connection to the permissions the workflow needs.

Apply these controls before using non-public data:

• Use a dedicated workspace for each team or deal.
• Give the bot read access unless writing is necessary.
• Keep credentials outside prompt text.
• Remove personal data that isn’t required for the research task.
• Confirm who can view agent runs and downloaded files.
• Set a retention period for temporary documents.
• Preserve an audit record for every run.
• Review vendor privacy and data-processing terms.
• Require human approval before external messages or system updates.

Browser automation needs extra care. A bot that can log into a portal can often reach more information than the analyst intended. Restrict the allowed domains and test the workflow with a low-risk account.

Do not upload a confidential data room to a general research workflow. Build a separate document workflow with access restrictions, approved storage, and an explicit deletion process. Review whether the platform is permitted to process the data before testing.

The same rule applies to legal contracts and customer data. An automated extractor may identify clauses or names, but a qualified professional must decide what those clauses mean.

Review AI-Generated Financial Research

An M&A research bot can extract numbers. It cannot guarantee that the numbers are comparable, current, or complete.

Financial data creates several common problems. A company may report revenue in different currencies. One source may use a fiscal year while another uses a calendar year. A database may list an estimate as if it were a reported figure. A press release may describe a transaction without disclosing consideration.

AI can also combine facts from related companies. Similar names, subsidiaries, parent entities, and regional websites create identity errors. Dynamic pages can expose incomplete content. Scanned PDFs can produce incorrect text recognition. Paywalls and blocked pages can leave gaps that the output doesn’t make obvious.

Treat every material figure as unapproved until a reviewer checks the source. Pay particular attention to:

• Revenue and growth rates.
• EBITDA, operating income, and adjusted metrics.
• Net debt and cash.
• Ownership and voting rights.
• Customer concentration.
• Transaction consideration.
• Closing status.
• Litigation and regulatory claims.
• Market share and competitor rankings.

Use a separate calculation model for valuation, accretion, dilution, purchase accounting, and return analysis. Twin.so can collect inputs and move them into an approved spreadsheet or finance system. It shouldn’t invent assumptions or replace tested formulas.

An automated workflow also shouldn’t make legal conclusions. It can find public litigation records or extract a contract clause for review. Legal counsel must interpret the issue and advise the deal team.

AI-generated research is an intake layer. The source document and the human decision remain the control points.

Label the final report clearly. State that the output is research support and not investment, legal, tax, accounting, or financial advice. Keep the language factual. Avoid terms such as “safe acquisition,” “confirmed risk-free,” or “guaranteed valuation.”

Test the Bot Before Wider Deployment

Run at least three test cases before giving the bot to a wider team:

1. A company with strong public disclosure.
2. A company with limited public information.
3. A company with multiple entities or conflicting sources.

Compare the results against a manually prepared review. Measure extraction accuracy, source coverage, duplicate rate, exception quality, and reviewer correction time.

Keep a change log for prompts and workflow settings. A small prompt change can affect output fields, source selection, or how the agent handles missing data.

Use a simple acceptance standard:

• Every material claim has a source.
• Every financial figure has a period and currency.
• Conflicts remain visible.
• Missing facts aren’t filled with guesses.
• The target identity is confirmed.
• Exceptions explain what failed.
• A reviewer can reproduce the result.
• No unapproved external action occurs.

Once the workflow passes these tests, connect it to the team’s existing workspace. Export the structured result to a spreadsheet, database, or deal-management tool. Add review status and owner fields so the output doesn’t become another untracked document.

If the bot uses a browser agent, retest it when the source website changes. If the source offers a stable API, move repeated extraction to that connection instead.

Conclusion

A useful M&A research bot does more than collect pages. It creates a repeatable record of what was searched, what was found, which source supports each claim, and what still needs review.

Build the first Twin.so workflow around public sources, structured fields, strict stopping rules, and a human approval gate. Keep financial calculations, legal interpretation, confidential data, and investment decisions outside the bot’s authority.

The strongest output isn’t the longest report. It’s a short, traceable research package that lets an analyst verify the facts and move to the next diligence question.