Developer open-sources core of procurement lead-finding agent with 726 tests

A company has published a server procurement notice, giving a salesperson a reason to start a conversation. But between the notification and a useful call lies manual work: opening the technical specifications, understanding the equipment, reviewing the buyer's financial statements and finding someone to call. The creator of AI Tender Radar described how they handed this preparation to an AI agent and open-sourced the project's research core on GitHub.

The output is a Telegram card: what the buyer needs, its financial metrics, which number to call and which questions to start with. According to the creator, the system is running in production and has processed procurement notices from hundreds of companies. The article provides no measurements of time savings or search accuracy, so the case is best assessed primarily on its system design.

From technical specifications to a pre-call briefing card

The program collects public-sector and commercial procurement notices for servers, data storage systems and components, downloads the documents and extracts their text. It supports PDF, DOCX, DOC, XLSX, TXT, ZIP and 7z archives. Scans without a text layer, RAR archives and the older XLS format remain gaps in its coverage.

Suppose a procurement notice is titled simply "equipment supply." That is not enough for a sales rep. The agent needs to open the attachments, identify the items, quantities and deadlines, then find a contact at the buyer. It obtains revenue, profit and capital figures from the latest published financial statements available through Russia's Federal Tax Service (FNS). This helps prepare for the conversation, although it does not, on its own, establish whether the company will pay for a particular delivery.

The card has "Pursue" and "Skip" buttons, and users can add a note. Leads can be exported to Excel. The agent does not contact buyers on its own or promise delivery terms: it does not know the seller's prices or capabilities.

The agent chooses the path; code checks the contacts

The first version followed a sequence of predefined steps. It searched for contacts in the documents, then on the website, then along other planned branches. Different procurement notices required new exceptions, making the program increasingly complex.

In the second version, the model received tools for reading documents, searching the web, opening pages and retrieving financial statements. Instructions set the source priorities, while the agent chooses what to open next. Each research task has limits on the number of steps and model spending.

The most useful engineering detail comes after the search. Before saving the card, conventional code checks the proposed contacts against texts the agent actually read. For a phone number, it looks for the number's ten-digit core; for a name, its constituent parts with allowance for inflectional endings; for an email address, an exact, case-insensitive match. Unverified information is removed.

The system then assigns the card a category: A means a person with a phone number was found; B means a phone number without a name, or a contact from a third-party directory; C means no phone number. Only the first two categories are sent to the sales rep. If the agent fails to find a person with a number, the procurement notice is passed to a fallback model.

But matching a source has clear limits. It does not prove that the phone number belongs to the named person or is still current. The creator also acknowledges the possibility of an accidental match involving adjacent numbers; extensions are not checked. This makes the check best understood as a filter against fabricated contacts, rather than a guarantee of reaching the right person.

What you can bring into your own product

According to the creator's description, the open-source core includes the agent, tools, contact verification, logging, Telegram delivery, notes and export. It lists 726 automated tests using synthetic data and an AGPL-3.0 license. Procurement platform integrations, operational instructions and server settings remain closed. You will need to prepare those parts separately to run your own instance.

The practical value of this case lies in the division of responsibility. The model interprets varied documents and chooses a search path, while the program limits spending and verifies information before sending it. Duplicate handling, waiting for documents and ambiguous Telegram responses are addressed separately: these are the details that determine how convenient the system is in daily use.

Developers can learn from its result verification and failure handling. Product managers should measure the share of useful cards, preparation time and cost per lead using their own procurement notices. Without those metrics, the account demonstrates a working approach, but does not yet establish its economic impact.