The Five-Word Test That Exposes Weak AI Vendors in 2026

A vendor walks into the room with a "fully autonomous AI agent" that supposedly drafts proposals, checks invoices, and takes work off the sales team's plate. The slides look great. Then the IT lead asks one question: "How does the agent access our CRM?" What follows is a vague detour into "flexible integration options" — and silence.

This scene plays out in conference rooms across the U.S. every single day in 2026. Executives and digital transformation leads are being asked to approve six-figure budgets for AI projects without being developers themselves. The core problem: key terms like agent, skill, or MCP get thrown around loosely in vendor pitches. What sounds identical on paper can be worlds apart technically — and the price gap between a chatbot wrapper and a genuine agentic architecture can easily run into six figures.

This article breaks down five precisely defined terms and gives you a practical test you can run live, mid-conversation, to pressure-test what a vendor is actually claiming. No developer background required — just the willingness to ask the right questions at the right moments.

The AI automation market has developed a vocabulary problem over the past 24 months. Anthropic, the company behind Claude, built two standard building blocks — the Model Context Protocol (MCP, released November 2024) and Agent Skills (2025) — that gained traction at record speed. Even direct competitors adopted MCP within a matter of months; we'll break down exactly which ones, and why that matters for decision-makers, in the MCP section below. The result: almost no vendor pitch today skips these terms — but using them and actually having built them are two very different things.

The scale of the problem is measurable. Gartner estimated in mid-2025 that out of the thousands of vendors marketing themselves as "agentic AI" specialists, only around 130 actually deliver agentic systems. The phenomenon even earned its own name: "agent washing" — relabeling chatbots, RPA tools, and prompt chains as autonomous agents. The same Gartner analysis projects that more than 40 percent of agentic AI projects will be scrapped by the end of 2027 — often because the promised level of autonomy never existed in the first place.

"Most agentic AI projects right now are early experiments or proof-of-concepts that are primarily hype-driven and often poorly deployed," Gartner analyst Anushree Verma noted in her June 2025 assessment.

For decision-makers, this creates a very real problem: two proposals with identical wording — "AI agent with skills and system integration" — can describe either a $15,000 chatbot project or a $250,000 automation architecture. The five terms Claude, Claude Code, Agent, Skill, and MCP form a kind of maturity ladder: from pure conversational AI at the bottom to automation fully wired into enterprise systems at the top. Anyone who knows the rungs of that ladder can immediately tell which step a given offer actually stands on — regardless of what the slide deck claims. And these are exactly the rungs we see blurred over and over in vendor conversations: not out of bad intent, but because even technically savvy sales teams tend to use these terms interchangeably, as if they were synonyms.

Before the test can be applied, each of the five terms needs a sharp, standalone definition. We'll start with the most common mix-up of them all.

"We're building on Claude" — you'll hear this line in almost every pitch, and on its own, it tells you almost nothing. Anthropic sells several fundamentally different products under the Claude name, and mixing them up regularly costs companies real money.

Claude is, first and foremost, the language model itself — currently at Claude Sonnet 5. It understands text, analyzes documents, holds conversations, and generates content. What it doesn't do out of the box: independently access file systems, run programs, or trigger processes in enterprise systems. Claude the model is an engine — not a vehicle. Anyone chatting with Claude through a web interface is using an application built on top of the model, not an automation infrastructure.

Claude Code is something fundamentally different: a command-line and IDE tool Anthropic built for software development. It can read and write files, run terminal commands, test code, and work through entire repositories. In other words, Claude Code has exactly the operational capability the raw model lacks — but primarily within the context of development work. We broke down just how much this tool is already reshaping engineering teams in our piece on Agentic Coding in 2026.

The costly confusion happens right at that boundary: vendors who pitch "Claude as an automation solution" almost always mean a custom-built application that calls the Claude model via API. That's entirely legitimate — but it means the actual engineering work isn't coming from Anthropic, it's coming from the vendor. And that's precisely the work that needs to be scrutinized. In our own client engagements, this is usually where serious vendors separate fastest from the pretenders: if a vendor can't clearly articulate their own value-add, chances are they didn't actually build one. A proposal that blurs the line between the model, the developer tool, and the vendor's own application is obscuring — whether out of ignorance or by design — exactly where its real value creation begins.

Even once you've confirmed the right product is in play, the more decisive question remains open: are you actually looking at an agent — or just a script with a prompt bolted on?

No term gets thrown around more loosely in 2026 than "AI agent." Yet the technically precise definition is surprisingly clear: an agent is a system that decides on its own what step needs to happen next. It observes a state, plans an action, executes it, evaluates the result — and adjusts its plan if the intermediate outcome doesn't match what it expected. This loop of observing, planning, and acting is the defining trait.

What gets sold instead is often something else entirely: a scheduled routine — a cron job, in developer speak — that fires off a hardcoded prompt to a language model, takes the response, and forwards it to a target system. Prompt in, answer out, email sent. This flow is rigid: if the model returns a useless answer, it gets passed along anyway. If the task requires one extra step, the system breaks. That's 2010s-style automation with a language model bolted on as a text generator — not agentic architecture.

This distinction isn't an academic footnote. It directly determines your return on investment:

The most reliable tell of a pseudo-agent is a missing feedback loop. Here's a simple stress test to run during any demo: deliberately feed the system an incomplete input — an invoice missing the sender's address, for example. A real agent spots the gap, asks a follow-up question, or pulls the missing detail from a connected system. A script just outputs a made-up or blank address and keeps going as if nothing happened. In our own project work, including the AI automation build for financial.com, this exact kind of error resilience was the deciding factor for whether the system went live — not how polished the output looked under ideal conditions. The lesson we keep relearning: the gap between a real agent and a script never shows up in a demo running clean sample data. It shows up the moment messy, real-world company data hits the system.

But a real agent still needs a set of callable capabilities it can draw on within that planning loop. And that's exactly where the next commonly misunderstood term comes in: the skill.

Since Anthropic introduced Agent Skills in 2025, the term "skill" has shown up in nearly every vendor pitch — usually without any clarity on what it actually means. Here's the precise definition: a skill is a packaged, self-contained set of instructions, examples, reference material, and sometimes executable code that a model loads on demand when a task calls for it. A skill for invoice review, for instance, would include the company's validation rules, examples of correct and incorrect invoices, and possibly a script to verify VAT ID numbers. The model activates that skill only when an actual invoice is on the table — and keeps its context lean the rest of the time.

The critical difference from what many vendors market as a "skill library": real skills are versioned, testable, and reusable. You can treat them like software — with change logs, defined test cases, and the ability to deploy the same skill across multiple agents and departments. A pile of copy-paste prompts sitting in a Notion doc or a shared folder meets none of these criteria. It's not testable, nobody knows which version is currently live, and every edit is a shot in the dark.

The tell for a missing skill structure is remarkably consistent in practice: the vendor has to reconfigure the entire setup for every new task. If the "agent" is suddenly supposed to handle order confirmations instead of just quotes, that means a new project, a new system prompt, a new round of testing and sign-off — and a new invoice. In a real skill architecture, that would simply be one more skill added to an existing library: defined, tested, deployed. The effort involved differs by a factor of five to ten.

For decision-makers, this translates into a simple diagnostic: the question "What skills already exist, and how are they maintained?" separates vendors who build structured systems from those who improvise. If the answer is a folder full of boilerplate text, that's not a skill library — it's prompts with better marketing. And this distinction only gets more important as more departments inside a company start building their own AI tools in parallel — a phenomenon we covered in depth in our piece on shadow AI inside organizations.

But even an agent with a cleanly structured set of skills is useless if it can't talk to real business systems. That's exactly the gap MCP is built to close.

The Model Context Protocol is the least glamorous of the five terms — and the most important. Anthropic released MCP as an open standard in November 2024: a protocol that lets AI models access external data sources and tools in a structured way — CRM systems, databases, ERP software, internal tools, file storage. The analogy that gets used most often is the right one: MCP is the USB-C port of the AI world. Instead of building a custom integration for every combination of model and business system, you deploy one MCP server for a given system, and any MCP-compatible model can plug into it.

The strategic weight of this becomes clear when you look at adoption. Within months of the release, OpenAI, Microsoft, and Google had all adopted the standard. A protocol Anthropic initiated turned into cross-vendor infrastructure almost overnight — a rare outcome in an industry that usually prefers proprietary lock-in.

Why does this matter so much for decision-makers? Without MCP or a comparable integration layer, even the smartest agent is stuck with two options. Either it runs on static knowledge that was fed in once and starts going stale the moment anything changes inside the business. Or employees manually copy-paste current data into it — at which point the "automation" you're paying for is really just human labor with extra steps. Both scenarios kill the business case. An agent that can't pull customer data straight from the CRM isn't an automation system. It's a text generator with a personal assistant.

And that's exactly why so many vendors go quiet on the MCP question. Real integration means sorting out authentication and permissions, standing up or customizing MCP servers for existing systems, logging access, and clearing security requirements with IT. That's serious integration work — the same kind of work that shows up in traditional software and API development projects. It's demanding, but it's also the only path to automation that actually holds up under real use. In our own experience, this is the exact moment that reveals whether a vendor can actually do software engineering — or whether they can only write prompts. Dropping a chat widget on a website, by contrast, takes an afternoon. So when a proposal goes deep on prompts and use cases but glosses over the integration layer in a single throwaway sentence, that's not an oversight. It's a deliberate omission.

This is usually where vendors reach for an obvious counterargument: "We're already using GPT or Claude inside our application." Why that claim alone proves nothing is exactly what the next section gets into.

The objection sounds reasonable enough: the company or vendor already built a custom GPT, configured a Claude-based assistant, or rolled out a chat widget on the intranet. Doesn't that prove they've got AI figured out? The blunt answer: no. Measured against the five criteria in this article, a typical custom GPT or chatbot wrapper usually fails every single one. There's no independent agent operation — the system only responds when a human asks something. There's no skill structure — the "configuration" is just a long system prompt and a handful of uploaded PDFs. And there's no MCP integration — the system has no awareness of business systems and can't change anything inside them.

Time for an unpopular take: most of the "AI projects" sold in 2024 and 2025 were prompt engineering — sometimes well-crafted, but not agentic systems. What got billed as a "AI agent" was, in the majority of cases, a configured language model with a polished front end. Gartner's figure of only roughly 130 genuine agentic vendors out of thousands of self-declared ones backs up this read, as does the forecast that more than 40 percent of these projects will be scrapped by the end of 2027. It wasn't until MCP saw broad adoption starting in 2025 that the technical groundwork existed for building real agents that actually make business sense. Anyone claiming today that they shipped "autonomous agents" back in 2024 should be prepared to explain, in detail, how they pulled that off without the infrastructure it required.

In fairness, there's a counterpoint worth making: a working chatbot isn't worthless. A well-maintained support assistant that handles routine questions and takes pressure off the service team can pay for itself within a few months. It just solves a different problem than an agent with skills and system access. The chatbot answers questions; the agent gets work done. If you're paying agent prices for a chatbot, you don't have an AI problem — you have a procurement problem. The custom-GPT objection becomes an issue the moment it's used as proof of agentic capability. It isn't. All it proves is that someone knows how to configure a language model — a skill that, by 2026, is about as rare as building a PowerPoint deck.

With all five terms clearly defined and this counterargument put to rest, the test is ready to be applied directly in vendor conversations.

The test works without any technical background because it doesn't hinge on correct answers — it hinges on consistent ones. A vendor who actually built what they're selling answers these questions fluently, specifically, and without contradicting themselves. A vendor selling slides starts stumbling by the third question, at the latest. Four checkpoints are enough to cover five terms, because the first checkpoint clears up two of them at once: Claude and Claude Code.

1. Nail down the product: "Which Claude product are you actually using — the model via API, Claude Code, or a custom application built on top of the model? And who built that application layer?" A credible vendor answers this in two sentences. If they flip between "model" and "application" without naming the difference, they either don't understand their own architecture — or don't want to reveal it.
2. Pressure-test the agent behavior: "How does your agent decide on the next step — and what happens, specifically, when an intermediate result is unusable?" The answer needs to describe a loop: check, evaluate, correct. If the vendor instead describes a fixed sequence ("then the result gets forwarded to X"), you're looking at a script, not an agent.
3. Check the Skill architecture: "Which Skills already exist, how are they versioned and tested — and what does it cost to add another one?" The pricing question is the litmus test here. With a real Skill architecture, adding a Skill is a small, predictable increment. If every new task requires spinning up a brand-new project with a full budget line, the "library" they're claiming doesn't exist.
4. Demand a live MCP demo: "Show us live how the agent accesses a system through MCP — ideally in your own environment, with a visible Skill call and a visible connection." A live demo where you can actually watch the tool call happen is worth more than any slide deck. Vendors with real integration are happy to show this off — it's their strongest selling point. Vendors without it offer a "pre-recorded demo video" or a follow-up call that never materializes.

The scoring logic is simple: evasive, inconsistent, or suspiciously vague answers on even one of the five terms is a reliable red flag for an overpriced pseudo-agent project. This isn't about putting vendors on the spot — it's about knowing, before you sign off on budget, which rung of the maturity ladder the proposal actually sits on. In the AI & Automation work we deliver ourselves, we ask these exact four questions in the first client conversation — before the client has to ask us. Vendors who volunteer these answers instead of waiting to be cornered have usually built what they're selling. Anything else is a good reason to end the meeting politely.

What actually shifts after running this test isn't just a mental checklist — it's the entire dynamic in the room. Once you can precisely separate these five terms, you're no longer negotiating over slides; you're negotiating over evidence. Vendors who avoid that shift are usually already answering the real question — whether they built an automation system or are selling a language model in a nice costume. That clarity is ultimately what determines whether a project is still running in 2027 or has landed in the 40-percent cohort Gartner expects to get shut down by then.

Maybe the most important takeaway here: the most common sales trick in the AI market isn't lying outright. It's the deliberate blurring between these five terms — letting model and application bleed together, letting script pass for agent, letting a folder of prompts pass for a Skill library. Precision, then, isn't an academic nice-to-have. It's the sharpest purchasing tool a decision-maker has.

The next move is straightforward: at your next vendor pitch, run through the five terms one by one, work through the four verification steps, and insist on a live demo with a visible Skill call and a visible MCP connection. Anyone who settles for a slide deck instead has already paid the price for the ambiguity — before a single dollar has changed hands.