How We Catch Vendor Agent Launches Within a Week

Most Wednesdays, a cron in our stack reads somewhere between 50 and 70 vendor blog posts and queues 2 to 5 of them for a human to look at. Most of those get rejected too. That sounds like a system barely doing anything. It is actually the system working exactly as intended, and the reason why is the whole point of this post.

The problem: catalogs go stale in weeks, not quarters

A catalog that a CFO uses to model AI agent savings has a freshness problem. Vendors ship agents constantly, and they change prices on the ones already shipped. If you refresh your catalog once a quarter by hand, you are routinely six to ten weeks behind a launch that a board member already read about. We lived that: quarterly manual audits kept surfacing agent launches and price moves weeks after they happened.

The fix is to notice launches fast. The trap, which we walked straight into on the pricing side and wrote up honestly, is to assume that noticing fast and updating automatically are the same job. They are not. Noticing is a machine job. Deciding what goes in the catalog is a human job. This system is built on that split.

The pipeline

Every Wednesday the cron polls 11 vendor newsroom and changelog feeds, the AI giants and the enterprise incumbents most likely to ship an agent that matters to a CFO's stack.

It reads feeds the boring, reliable way. For sources that publish RSS or Atom, it walks the feed and tracks a guid cursor, so it only ever processes posts it has not seen before. For sources that only have an HTML changelog, it hashes the page and compares against last week, so an unchanged page costs nothing. This is deterministic plumbing. It does not guess. It just tells us what is new.

A classifier reads each new post through a relevance gate. Most vendor posts are not agent launches. They are feature notes, customer showcases, conference recaps, hiring announcements. The classifier's first job is to throw those out and keep only posts that plausibly describe a new or repriced agent.

The tool-name field is an enum, not free text. This is the part that matters most, and it is a structural decision, not a prompt one. When the classifier proposes that a new agent compresses some tool, the tool it names has to come from a fixed enum built out of our catalog, and that enum deliberately excludes AI products as compression targets. You cannot map a new agent against ChatGPT or Claude or another AI agent, because those are not in the enum. The reason we did it as an enum instead of a prompt instruction is simple: prompt instructions leak. Tell a model "never target an AI product" and it will mostly comply and occasionally not. An enum cannot emit a value that is not in it. The model literally cannot name a target we did not allow.

Nothing auto-publishes. Every candidate the classifier keeps lands in a human review queue, marked pending. A person reads it and decides. This is the same no-auto-publish contract that runs under why we source every compression percentage: a machine can propose, only a human commits.

A typical week

The numbers are lopsided on purpose. A normal week looks like this: 50 to 70 posts come in across the 11 feeds, the relevance gate and classifier narrow that to 2 to 5 candidates, and on review most of those candidates get rejected too. Feature posts that slipped the gate. Customer showcases dressed up as launches. Preview announcements for products that are not GA and have no public price, which we do not give rows to until they ship.

The first real run tells the story well. It caught the Microsoft Scout announcement and two Microsoft price changes. Scout got rejected on review, correctly, because it was a preview with no verifiable price. The two price changes were real and got actioned. So the first run's yield was: several candidates surfaced, one high-profile launch caught and then deliberately declined, two genuine price moves kept. That is a good week. The system found the real changes and gave a human the chance to reject the noise.

Why "mostly rejects" is the system working, not failing

Here is the contrarian part. A queue that is mostly rejects looks inefficient. It is the opposite.

The asymmetry is the reason. The cost of reviewing five candidates and rejecting four of them is a few minutes of a human's attention. The cost of one wrong catalog row (a preview agent with a made-up price, an AI-against-AI mapping that inflates a savings number, a feature post misread as a launch) is a number in a CFO's board deck that falls apart the first time a vendor challenges it. Those two costs are not close. Reviewing five to guard against one bad row is a trade you take every week.

So we do not tune the system to queue less. We tune it to catch everything plausible and let a human throw out the noise. The classifier is allowed to be a little trigger-happy, because the human queue is the backstop, and a false positive costs minutes while a false negative, a real launch we missed, costs weeks of staleness. The freshness of the catalog is worth a queue full of rejects.

What a CFO should ask their own tool

If you are evaluating a SaaS or AI spend platform, ask how its catalog stays current, and listen for the shape of the answer.

"We scrape vendor pages and update automatically" is a red flag. Automatic extraction from marketing pages produces confident, wrong numbers. We know, because we built that on the pricing side and shut it off. Auto-updating a CFO-facing catalog with unreviewed machine output is how a flat monthly fee becomes a per-seat rate that is 100 times too high.

"We detect changes automatically and a human confirms them" is the right shape. Detection should be a machine. Commitment should be a person. If the vendor cannot tell you where the human is in the loop, assume there isn't one.

Ask how fast they catch a launch. Weeks behind is the default for hand-audited catalogs. If your renewal calendar has a vendor on it and their newest agent is not in your tool's catalog yet, your tool is behind, and you are negotiating with stale information.

Our answer is a Wednesday cron, 11 feeds, a relevance gate, an enum that structurally refuses to map agents against AI products, and a human who reads every candidate before it becomes a row. Most weeks that human rejects most of what they see. That is the cost of a catalog you can actually trust.

Try the free calculator, 15 seconds, no signup. The agents in it are there because a human decided they belonged, not because a scraper found them.