You run product at a software company with customers who look nothing alike. Some have five users. One has thousands. Your team has just shipped an agent that drafts orders and an API that partners call, and the question on your desk is what to charge for either. You have a spreadsheet. You do not trust it.
Then you read a Workato customer session with the chief product officer of DMSi, and the first thing he says is the thing you were afraid to say out loud. Jason Niemi: "I don't think anybody has really figured out the pricing." He says he has tried to redo DMSi's pricing about ten times. DMSi is a 350-person ERP vendor with roughly 650 customers, and its base runs from five-user lumber yards to a company with 7,000 users. Every new model breaks on someone. In his words: "This customer is going to go up by 300x. And then our biggest customer went down by half."
So DMSi is not starting with a price sheet, and the post suggests you shouldn't either. The company is sending everything, whether an API call or an agent, through a single access point. Next come monthly usage allowances. Only after that comes the price. In the post's summary, the sequence is to control the plumbing, drive down the cost, then monetize. You build the meter before you decide what the meter is worth.
The operational advice is practical. Start on a frontier model, then work down through smaller ones, using evals to check each step. Treat tool definitions as prompt engineering. And watch for what the session calls doom loops, where "the agent gets stuck and can't proceed." The fix described is a hard cap on retries.
You should read the numbers with care, and the post tells you why. This is a customer story on the vendor's own site, and it ends with a call to explore Workato's product. The "10x cost reduction" from moving to open models is the claim of Preston Badeer, DMSi's AI partner. The "roughly 87% cheaper" is Badeer's own estimate of his own company's offering. Neither is a benchmark. The post's view is that the sequence survives without them.
Here is where the post turns, and it turns on Workato's own record. The APIs.io catalog lists 11 API pages for Workato. The ones this story leans on are easy to name: the Embedded Partner API, for a vendor putting Workato in every user's hands whether they know it or not; the Recipes API, for the integrations DMSi is rebuilding; and the MCP Servers, Tools and Policies APIs for the agent-facing side. The catalog description agrees with the positioning, recording Enterprise MCP, Genies and Workato Embedded layered on the iPaaS foundation. The agentic access profile also echoes the order-entry agent that holds a draft for review: it marks 5 of 60 operations human-in-the-loop, with 40 acting.
The scores are mixed. Workato's Kin Score is 65.7, strong, with developer ergonomics at 76.8 and contract quality at 70.6. Contract governance trails at 45.5. Agent Readiness is 49.5, and it lights dimensions most of the market leaves dark: MCP server, delegated identity, protected resource metadata, dynamic client registration. For a platform selling a controlled access point, those are the right ones to have lit.
Then the unlit list, which the post asks you to read beside the doom loop advice: idempotency, reversibility and dry-run mode. This is the catch for you. A retry cap limits how many times an agent repeats a call. Only idempotency decides what each repeat does. If your agent drafts an order and a retry creates a second one, the cap has not saved you; it has merely bounded the damage.
What you take away is an order of work. Put every call, human or agent, through one door you can count. Set allowances before prices. Cap retries, and then check whether a repeated call is safe to repeat. And when you read a vendor's customer story, including the numbers inside it, keep the claims separate from the sequence, and check the vendor's own record against the advice it publishes.
Read the original: https://apis.io/2026/11/02/workato-customer-says-nobody-has-figured-out-agent-pricing-so-build-the-meter-first/