How many AI solution providers have made their way into your inbox just this month? What to ask before you buy.
By the Spring, every system built for the aviation aftermarket will offer an Agent. Your inventory or ERP system will have one, your marketplaces will have one, and the startup that emailed you last week says they have one ready now. Some will be good. Most will impress on a demo call and disappoint when plugged in.
That puts you in an awkward spot, because the pressure is to move quickly but the information to choose confidently doesn’t exist yet. You’ll probably be wrong at least once. Hopefully it’s easily reversible; if not, it’ll be expensive and time-consuming.
If your agent lives inside a single vendor’s product and can only act through that product’s screens, then switching agents later means switching the whole system underneath it. It takes six months to know whether a system is any good, and by then the switching cost is significant.
The alternative is to treat the agent as a replaceable piece. That only works if the underlying sales process is reachable externally: if listing inventory, receiving requests, pricing them, sending a quote, and getting paid can all happen without a human moving a mouse. When that’s true, the agent becomes a component you can evaluate, swap, or run two of side by side against real traffic. When it isn’t, you’re stuck with whoever got there first.
So the question to put to any vendor pitching you AI: can I do everything your agent does with an API, using my own code? If the answer is no, be careful what you commit to.
This is hard in our industry because most of the surface area was designed around a human operator. Marketplace portals assume a person logs in, scans a list, opens a request, and types a price. Plenty of RFQs still arrive as free text in an email because a person on the other end wrote it that way.
An agent facing that world has two options. It can imitate a person, driving a browser and reading screens, which works in a demo and breaks when a portal changes its layout. Or it can go through an interface built for software.
Rotabull’s approach is to be the second. Marketplace and email demand comes in through integrations, which means ILS, PartsBase, SkySelect, StockMarket and others arrive as structured records. The public API covers all parts of the process an agent needs to touch: deals and their history, customer quotes and quote line items, vendor quotes, inventory, alternates, and the automation rules themselves. Quoting through the API is a first-class operation, not an export you post-process.
On the transaction side, quotes carry an Order Now path that goes from a price to a completed order and payment, with invoices sent out from the same system that produced the quote. The handoff from quote to cash already happens inside one system, so an agent working your quotes isn’t handing off to a process it can’t see.
A general-purpose sales agent will get roughly half of this business wrong, and it will be confident about it.
It won’t know whether the difference between FN and NS is important, or that an overhauled unit with a fresh tag and an as-removed core are sold to different buyers. Traces can matter more than price, and a quote without the right paperwork goes nowhere. An AOG request is worth answering in twelve minutes at a good-enough price instead of three hours at a good one, and a repair quote is a turn-time promise with a price attached rather than the other way around.
This is the case for an aviation-first agent, and it’s why we’re building one. It’s also the case for insisting on API access even if you eventually use ours: the shops with the most specific expertise, the ones who know exactly why their people quote the way they do, will want to encode that themselves.
The useful thing about building on programmable access is that it pays out immediately, even with no AI involvement.
Automation Rules already route inbound demand on conditions like buyer company and category, email address, country, and they’ll catch a duplicate RFQ that arrives twice within the hour. Autoquote already answers matching requests, bounded by prices, condition matching rules, and more. It’s deliberately narrow because sending a wrong price automatically is worse than sending a right price slowly.
Teams that implement this receive more than just time savings: a written record of their own quoting logic, and clean data about which of that logic wins business. That’s the raw material any agent will need. Teams still quoting entirely by feel have to produce that material from scratch before an agent can do anything but guess.
Can I reach the same data and take the same actions through your API that your agent can, and is that documented? What are the guardrails on autonomous action, and can I set them per customer? If I want to run my own agent instead of yours, does anything in your pricing or terms punish me for it? And if I want to turn all of this off next quarter, what breaks?
Vendors who answer those cleanly are selling you capability. Others may be locking you in.
Our answer: Both doors should be open. Use the agent we’re building for parts sales, or point your own at our API and keep full control of the logic. Our goal is to earn the agent business every year instead of winning it once through switching costs.
