Why Preview Agents Don't Get Catalog Rows

On June 2, 2026, Microsoft announced Scout, an always-on personal agent. Within a day it was in our vendor-launch review queue. We looked at it, and we did not give it a catalog row. Here is the reasoning, because it is a rule we apply to every prerelease agent and it is one of the more important trust decisions in the product.

The problem with covering what does not exist yet

A SaaS spend tool lives or dies on whether a CFO can trust the numbers in it. Every agent row in our catalog carries a price and, where it targets a per-seat tool, a compression percentage that drives real renegotiation math. If a row says an agent costs $99 a seat and compresses 30 percent of your Zendesk, someone is going to put that into a board deck.

So the question for any new agent is not "is it exciting." It is "can we stand behind every number in the row when a vendor's rep challenges it in a renewal call." For a product that is announced but not shipped, the answer is almost always no, and Scout is a clean example of why.

What we actually found on Scout

We researched Scout the way we research any launch. Here is what was true when we looked:

• No general availability. Scout was announced, not shipped. The documentation was prerelease.
• Gated access. Getting into Scout required the Frontier preview program. It was not something a customer could go buy.
• A license dependency. Access required a GitHub Copilot license on top of the preview enrollment.
• No public price. There was no per-seat price published on any real Microsoft pricing page.

There was a $99 figure floating in search-result snippets. We could not trace it to an actual Microsoft page. It was not on a pricing page, not in the prerelease docs, not in the announcement. So we excluded it. A number you cannot open in a browser and read off the vendor's own site is not a price. It is a rumor with a dollar sign.

The rule: no GA, no public price, no row

Our rule for prerelease agents has three gates, and a product has to clear all three before it earns a catalog row:

1. It is generally available. A CFO can actually deploy it, not join a waitlist.
2. It has a public price. A per-seat or flat number published on the vendor's own page, that we can quote and link.
3. It targets something real. A per-seat tool with a defensible compression percentage and a contract that renews.

Scout cleared none of them at announcement. So it got no row, and it will get one when it goes GA with a published price. Not before.

The instinct this fights against is the coverage instinct. It is tempting to add every announced agent the day it lands, because a bigger catalog looks more comprehensive and "we track Microsoft Scout" is a nicer thing to say than "we don't." But a catalog measured by row count rewards exactly the wrong behavior. The honest measure is whether every row you do have is one a CFO can act on.

What a fabricated Scout row would have done

Walk through what adding Scout at announcement would have produced.

We would have needed a price, so we would have used the $99 snippet, because it was the only number available. That $99 is now in a CFO's model as if it were a Microsoft-published rate. It is not. When procurement takes it into a conversation with their Microsoft rep and the rep says "we have never published that number," the CFO's credibility takes the hit. Not ours in the room. Theirs.

We would also have needed a compression target. Scout has no defined per-seat tool it replaces at a measured rate, because it is not shipped and there is no deployment data. So the compression side of the row would be pure invention. Two fabricated numbers stacked on each other, presented with the same visual confidence as a Decagon on Zendesk row that traces to a real case study.

That is the liability. A missing row is a gap a CFO can see. A fabricated row is a landmine a CFO cannot see until it goes off in a negotiation. We would rather have the visible gap.

This is the same discipline behind why we source every compression percentage and tag the ones we cannot source as estimates. An unsourceable price is worse than an admitted absence, every time, in a tool a finance team is supposed to be able to defend.

How the launch caught it and the queue killed it

Scout did not slip past us. Our vendor-launch cron polls Microsoft's newsroom among other feeds, and it flagged the Scout announcement on the first run. The system worked exactly as designed: it noticed the launch, routed it to a human review queue, and a human read it and rejected it as a preview with no public price. Nothing auto-published. The catch and the rejection are both the system working.

That is the pattern for prerelease products in general. The cron surfaces them fast, and most of them get rejected on review, because "announced" and "buyable with a published price" are months apart for enterprise software.

What a CFO should do with a preview agent

When a vendor demos an agent that is not yet GA, or a board member forwards you a launch blog for something in preview, here is the discipline.

Do not budget for it. A preview product has no committed price, no committed capability, and no renewal window. There is nothing to put in a plan except a placeholder, and placeholders in a budget have a way of hardening into commitments.

Ask for the published price, on the vendor's own page. If the vendor cannot point you to a pricing URL you can open yourself, you do not have a price. You have a projection. The questions to ask an AI agent vendor in a demo start here: source, price, target, renewal window.

Wait for GA. A preview agent is a reason to schedule a revisit, not to move a dollar. Put a note in the file to re-check at general availability, and run the real numbers then.

We will give Scout a catalog row the day it ships with a price we can read on a Microsoft page. Until then, the honest entry is no entry.

Try the free calculator, 15 seconds, no signup. Every agent in it is GA with a price we can point you to. The ones that are not ready are not in there, and that is on purpose.