Shipped, Committed or Hoped For: Reading an AI Vendor Roadmap

To evaluate an AI vendor roadmap, sort every item into one of four groups: shipped, committed, planned direction, or aspiration. Then compare the first two groups with what your use case needs today and over the next planning cycle. Pay for what exists or is written into the contract, and treat everything else as possible upside.

Key takeaways

• A roadmap is a statement of intent from a seller. It becomes evidence only when you can match items to shipped releases, documentation or contract language.
• Sort every item into shipped, committed, planned direction or aspiration, and base your decision on the first two.
• Start from your own role definition, not the vendor's feature list. A roadmap is useful only where it touches a capability you depend on.
• Any capability you need on day one that exists only on the roadmap is a blocker, not a feature.
• Put the roadmap items you rely on into the written agreement, with an acceptance test and an exit path if they do not arrive.

Why does a roadmap deserve scrutiny before you sign?

AI products change faster than most business software. Models are replaced, interfaces are renamed, tool connections are added and retired, and behavior can shift between versions. That pace makes a roadmap attractive to buyers, because it promises that today's gaps will close. It also makes the roadmap one of the most persuasive parts of a sales conversation.

That is the problem to manage. A roadmap in a sales meeting is doing a job: it reduces your perceived risk so you will commit. It may be honest, and often is. But honesty about intent is not the same as a commitment to deliver. Your task is to convert a presentation into something you can check.

The cost of getting this wrong is rarely dramatic. It is usually a slow drift: a connector you were told was close stays close, a control you assumed would exist has to be built by hand, and the team that was meant to adopt the agent works around it instead. By the time the gap is obvious, you have already built processes, trained people and moved data.

What are the four kinds of roadmap statements?

Most roadmap slides mix very different kinds of claims on the same page. Separate them before you discuss any of them.

• Shipped: the capability is released, documented and available to your account type. You can test it this week.
• Committed: the vendor has named an owner, a delivery mechanism and a way for you to verify delivery, and is willing to write it down. A beta you can use under stated terms sits here.
• Planned direction: the vendor intends to build it and believes it is a good idea, but scope and timing can change. No one is accountable for the outcome.
• Aspiration: a vision, a theme or a category label. It tells you what the vendor wants to be known for, not what you will receive.

The most common mistake is treating planned direction as if it were committed. The second most common is giving credit for an aspiration because it is well illustrated. A useful habit is to ask, for each item, "What would I be able to do on the day this arrives that I cannot do now?" If the answer is vague, the item is probably an aspiration.

How can you tell committed work from marketing?

Language gives some hints, but evidence is better. Words such as "coming soon", "exploring", "on our radar" and "vision" signal intent without obligation. Words such as "available to all accounts", "documented in the reference" and "covered by the service terms" signal something you can hold the vendor to. Still, treat wording only as a prompt for questions.

These checks separate the two more reliably:

• Release history: ask to see the changelog or release notes for the past year and compare them with what the vendor said it would deliver at that time. A vendor that delivers close to what it announced has earned some trust on the next item.
• Documentation: shipped features have reference pages, limits and known issues. Marketing features have a landing page and a demo.
• Status labels: find out whether an item is in preview, limited access or general availability, and what each label means for support and stability.
• Ownership: a committed item has a named team or role responsible. If nobody can say who owns it, nobody does.
• Deprecation policy: a vendor serious about change tells you how much notice you get before something you use is altered or removed. That policy matters as much as any new feature.
• Dependencies: ask what the item relies on, such as a third-party model, a partner integration or a regulatory approval. Items with outside dependencies have outside risks.
• Customer access: ask whether any customer is using the item in daily work, without asking for names. A vendor can say yes or no, and the answer is informative.

When a claim comes with a demo, remember that a demo is a rehearsed path. The article on how to test an AI vendor's claims before you commit covers how to turn a demo into a test on your own material.

Does the roadmap fit what you actually need?

A roadmap can be accurate and still irrelevant to you. Fit comes from your requirements, so begin there, not with the vendor's slides. This plan takes a few working sessions and gives you a document you can reuse at renewal.

• Step 1: Write down the role you want the agent to perform in plain language: who it serves, what it decides, what it must never do alone.
• Step 2: List the capabilities that role depends on: model quality for your language and documents, memory, connections to your tools, permission controls, logging, channels, and the ability to export what you have built.
• Step 3: Mark each capability as needed on day one, needed within the first months, or nice to have.
• Step 4: Place every roadmap item next to the capability it would affect, and label the item shipped, committed, planned or aspiration.
• Step 5: Look at the day-one column. Anything resting on a planned or aspirational item is a blocker. Either find a working alternative, reduce the scope of the role, or do not proceed.
• Step 6: For the later column, accept committed items as reasonable and planned items as upside. Write down what you will do if they never arrive.
• Step 7: Test the shipped items with your own documents, your own tools and a realistic volume of requests, and record what you observe.
• Step 8: Decide with the whole picture: what works now, what is promised in writing, and what your fallback is.

Step 6 is where most evaluations stop short. The question is not only whether the roadmap is credible, but whether you can live without it. If the answer is yes, the roadmap is a pleasant bonus and the decision is easy. If the answer is no, you are buying a promise, and the agreement should reflect that.

The seven layers of company AI infrastructure are a handy checklist for step 2. They stop you from evaluating only the model and forgetting the layers that make the agent usable and controllable.

What does this look like in a realistic case?

Here is an illustrative scenario, not a real company. A distribution business wants an agent to answer routine supplier questions and prepare updates to records in its order system. A vendor presents a roadmap with four items: a native connection to the order system described as coming soon, an approval workflow for sensitive actions described as planned, an audit log that is already documented, and a theme called autonomous operations.

Sorted honestly, the audit log is shipped. The order system connection is planned direction until the vendor names an owner and a way to verify it. The approval workflow is also planned. Autonomous operations is an aspiration.

The company's role definition says the agent may draft record updates but a person approves each one, and that every action must be traceable. Approval is needed on day one, and the item that delivers it is unproven. That is a blocker as stated. The company has three honest options. It can ask the vendor to commit the approval workflow in writing with an acceptance test. It can design approval outside the product, for example by having the agent prepare drafts that a person submits through the existing system. Or it can walk away.

The company chooses the second option for a limited pilot, uses only the shipped audit log, and treats the native connection as a bonus. If the connection arrives, it will be evaluated like any other change. If it does not, nothing in the pilot breaks. The roadmap informed the decision without carrying it.

What should you put in writing?

A roadmap item you rely on but have not written down belongs to the vendor, not to you. Once you have identified which items matter, move them into the agreement or the statement of work. The guide to what to put in an AI agent statement of work goes through the sections in order. For roadmap matters, these points deserve attention:

• Named items: describe each capability you depend on in terms of what you will be able to do, not the marketing label.
• Acceptance test: define how you will confirm the item works, using your own material.
• Remedy: state what happens if the item is not delivered as described, including the right to end or reduce the engagement.
• Change notice: require advance notice when a feature you use is altered, limited or removed.
• Portability: confirm that your configuration, instructions, memory content and logs can be exported in a usable form. The article on avoiding AI vendor lock-in with business agents explains what to preserve.
• Review point: schedule a moment to compare delivered work with the roadmap you were shown. This also gives you a better position at renewal.

Vendors will not accept every one of these, and that is useful information. A provider willing to commit in writing has told you something about its confidence. A provider that insists on keeping the roadmap informal has told you something too.

It also helps to ask what the vendor does when it changes its mind. Roadmaps do change, for good reasons. What matters is whether you hear about it early, whether you have a say in how it affects you, and whether you can step back without losing your work.

How does Be Human handle roadmap risk?

Be Human designs a first engagement around one useful role, the memory and tools it needs, approval boundaries and an observable success criterion. That scope is built on capabilities that exist and can be tested, so the first deployment does not depend on unreleased features. The agent's identity, memory, permissions and operating context are kept under the company's control, which means a change in a model or provider is an adjustment to the setup, not a rebuild. Under managed operations, new capabilities are evaluated against the role before adoption, and changes go through review with the company's approval, alongside monitoring, recurring evaluations and integration maintenance.

Frequently asked questions

How far ahead should I trust an AI vendor's roadmap? Trust it as far as the vendor's delivery record and written commitments support. Near-term items with a named owner and a verification method are reasonable to plan around. Distant items are direction only, and your decision should still make sense if they never arrive.

Should a missing roadmap item stop me from buying? Only if the capability is needed on day one and has no workable alternative. If you can design around the gap, run a limited pilot, or reduce the role's scope, a missing item is a manageable cost. If the whole business case depends on it, wait until it ships.

What if the vendor refuses to share a roadmap? Many vendors keep roadmaps private for legitimate reasons, so focus on what you can verify instead: shipped features, documentation, deprecation policy and contract terms. A vendor with no roadmap but a clear, tested product and good exit terms may be a safer choice than one with an impressive roadmap and weak terms.

Who in my company should own this evaluation? Choose someone who understands the role the agent will perform and can say what is needed on day one, supported by whoever handles contracts and security. An executive sponsor should make the final call, since the decision concerns risk and commitment, not only features. Keep the sorted roadmap document so the next review starts from evidence, not memory.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.