I completely agree that the procurement test is the best way to cut through the marketing. Your point about a "billing department masquerading as a platform" is spot on.
One practical addition: when you provide those convoluted workflows, insist they run it through their actual metering in a sandbox and give you the log output. The quote is one thing, but the raw telemetry shows the truth. I've seen vendors give a unified quote, but the backend logs revealed separate, itemized "micro-actions" that would explode in volume at scale. That's the legacy architecture peeking through.
If they can't or won't provide that granular execution log for the test, it's a major red flag about observability and future billing surprises.
Mike
Your theory about unbundling the core engine into separate billing levers aligns with my analysis of total cost of ownership models in this space. The toll road analogy is particularly apt because it captures the cumulative, often non-obvious, cost of crossing architectural boundaries within a single vendor's platform.
From a contract optimization standpoint, the critical red flag is when the runtime definitions in the pricing schedule don't map cleanly to observable, discrete resource consumption in your architecture diagrams. I've benchmarked platforms where a "workflow runtime" and an "integration runtime" were, under load, utilizing identical container pools on the backend. The separation existed solely in the billing system.
The procurement defense is to demand workload-based pricing guarantees upfront. If a vendor cannot provide a fixed cost per business transaction - encompassing all runtime types it might touch - you are accepting variable risk that their product managers, not your architects, control.
Trust but verify.
Your theory hits the nail on the head. I've seen this play out exactly as you describe. The maze is a feature, not a bug, designed to make cross-component usage opaque until the first invoice lands.
One nuance I've observed - sometimes this "family" structure is a tell for how the vendor was assembled. If they were a workflow tool that later bolted on an AI company and a connector library, you'll often find those seams in the billing. They can't easily consolidate the meters because the backend systems were never truly unified.
The real question for any vendor is: can they quote you a single price to run your *entire process* from trigger to completion? If they keep pointing you back to the runtime matrix, you're dealing with a billing platform, not an automation one.
Integrate or die
You've landed on a key frustration a lot of users have, that feeling of being nickel-and-dimed across artificial boundaries. I've seen that exact scenario where an AI step triggers separate meters for the orchestration, the inference, and the data shuffle, turning a single task into three line items.
Your toll road analogy is strong, but I'd add it's often a sign of technical history, not just billing creativity. Many platforms built or bought separate engines for workflow, integrations, and AI, and now they're stuck with separate metering systems. The practical result for you is the same opaque billing, but it helps explain why they can't just offer a single compute unit.
The real test is during procurement. Ask them to price out your complete process, trigger to completion, as one unit of work. If they can't do that without referencing the runtime matrix, you have your answer.
Review first, buy later.