An agent that reviews tenders every day and flags the ones worth pursuing

Who the client was and what was getting in the way

A construction company bids on public tenders and faced a recurring problem. Someone had to visit tender portals every day, click through the listings, open a dozen or more notices and check whether any were worth bidding on. It took a meaningful part of the day, was tedious and therefore easy to get wrong, especially on Monday mornings, when notices had piled up over the weekend.

Submission deadlines are short. A notice spotted three days after publication is often already out of reach because preparing the documents takes time. The value lies not only in finding a tender, but in finding it quickly.

The biggest problem, however, was noise. Most notices in the databases concerned supplies or work outside the company’s profile. Reviewing all of them just to reject well over ninety percent wasted the time of someone who should have been preparing cost estimates. One more thing is easy to overlook in a project like this: the real filter for a bid decision is not the contract value, but the participation requirements. Required references and a bid bond can disqualify a company from a tender that looks ideal on price. Those requirements need to be read before anyone starts preparing a bid.

What we built

We built an agent that handles the entire process once a day, from collecting notices to producing a recommendation.

Collection runs on Python and public tender-database APIs. We connect to both an EU source and a national one, so the company does not have to remember to check two portals. A cron job starts the process at a fixed time, ensuring new notices are reviewed by the following morning at the latest.

The first filter is inexpensive and deterministic. Heuristic scoring filters by industry codes, keywords and contract type, distinguishing construction work from supplies. This removes most of the noise without calling a model or incurring its cost.

Anything that passes the filter goes to a decision model. It receives the notice, participation requirements and company profile, then returns a yes, maybe or no verdict with a reason. The explanation mattered more than it might seem at first: a verdict without a reason is useless. No one will risk dropping a tender based only on an automated no.

The results appear in a decision dashboard built on Supabase. Each notice has a verdict, explanation and status that the company sets itself: submitted or rejected. The dashboard is both a review queue and a record of decisions.

How it works today

Every day, the agent fetches new notices from both sources, runs them through the scoring filter and the model, then updates the dashboard. The person responsible for tenders opens a single view in the morning and reviews a handful of items with verdicts already prepared, instead of clicking through the portals. Rejected notices remain in the dashboard with their explanations, so the team can revisit them and reverse a decision at any time.

The submitted and rejected statuses are updated manually, by design. This decision must stay with a person, because only they know whether the company has capacity at that moment. The whole system was built in about one week.

What changed

The databases are reviewed automatically once a day, without human involvement. The agent monitors two tender sources at once: one EU-wide and one national. Every notice that passes the first filter receives a yes, maybe or no verdict from the model. Work outside the company’s profile is filtered automatically, leaving only a fraction of the previous volume to review.

What we would do differently

We relied too heavily on the model at the start. The first version sent nearly everything returned by the API to the model, which made the process both more expensive and slower than necessary. Adding an inexpensive heuristic filter before the model made the design practical; that is how we will start next time. Our second lesson concerns participation requirements. We added references and bid bonds to the assessment later, even though they are often the deciding factors. Starting with them would have made the first verdicts more accurate and helped the company trust the shortlist sooner.