The tool did have artificial intelligence. The arrow just pointed the wrong way.

The conversation at work was about as unremarkable as they come. Could the company's AI assistant be wired into a network infrastructure tool the team had already been using for years? It sounded like a Tuesday-afternoon request: two things that already existed, one question of fit. Yuri went to find out.

The tool did, in fact, have an artificial intelligence feature. The sales material said as much, plainly. The trouble was that nobody had asked the right question before promising the integration. The right question was never "does this tool have AI?" It was "which way does that AI point?"

Because the answer, once Yuri finally ran it down, turned the team's plan on its head: the arrow only pointed outward. The tool used AI to call an external model and have it explain the tool's own data, in plain language, for whoever was looking at the dashboard. What did not exist was the reverse path, a door through which an outside assistant could call into the tool and ask it for something. The integration the team had pictured, the company's assistant reaching into the network tool for information, was simply impossible. Not for lack of artificial intelligence. For lack of a door.

That alone would have been lesson enough for the week. But the vendor's material had a second trap in it. It advertised, in confident type, support for the technology of the moment, the kind of line any product manager loves at the top of a page. Read to the very last line, though, what the vendor meant by "support" was something considerably narrower than the opening paragraph implied. Anyone who stopped at page one walked away believing something the rest of the document quietly contradicted.

Which is the lesson Yuri brought home: in AI integration, the useful question is never whether artificial intelligence exists somewhere inside the product. It is who calls whom. And reading the documentation to the last page remains an unfair advantage, in the good sense of the phrase: almost nobody does it, so whoever does gets there first.

What is curious is that this confusion is not a one-off accident of a single tool. It is common enough that the industry has built a whole vocabulary just to sort it out. There is now an open standard, adopted across a number of technology companies, whose entire job is to spell out, explicitly, who initiates the call in a conversation between an AI assistant and an outside tool. In that design, it is the assistant, the side the person is actually operating, that decides to ask something of a tool, whether because of a direct request from the user or because of some automated process the assistant chose to run on its own. The tool answers. It does not initiate.

That standard exists because, before it, every pair of systems that needed to talk required a custom integration built from scratch, with nothing reusable. A shared standard promises to solve that problem once, instead of solving it again for every new pair of tools. It is a good idea. Good ideas, unfortunately, do not stop marketing from arriving before the implementation does.

There are already documented cases, from people who went and actually checked, of vendors announcing support for this standard when what really existed was a generic wrapper bolted onto an older feature, not a real implementation signed off by the manufacturer. And there are cases running the other way too: companies announcing "AI agents" or "agentic" products without that ever meaning they adopted the connection standard in question. Having an agent is not the same as having a named, documented door for that agent to walk through. It is exactly the kind of distinction that only surfaces for whoever reads to the end.

There is a second layer too, a more serious one, that only shows up once the arrow finally does point the right way. Recent surveys of these connections found that the large majority of them, between assistant and tool, run locally, on the developer's own machine, with full privileges and no credential isolation at all. No sandbox separating what the assistant can see from what it should not. And traditional security tools, built for a different world, simply do not register that traffic as anything worth a second look: they see an ordinary process, opened by a legitimate application, traveling over an encrypted connection to a domain with no bad reputation attached. Nothing there trips an alarm, because none of it was designed with an AI assistant deciding, on its own, to call something on somebody's behalf.

Put the two layers together and Yuri's lesson gets sharper than it looked at the start of the week. It is not enough to ask who calls whom. It is also worth asking what happens once that call is established and something goes wrong, or somebody who should not have access uses it anyway. An integration that fails for lack of a door is a design problem, solved by reading the documentation to the end. An integration that works with nobody having thought about who is watching that door is a different kind of problem, and a costlier one to discover afterward.

Neither question shows up on page one of the sales material. Both show up, when they show up at all, in the fine print that whoever bothered to read to the last page found waiting for them.