ZEVRYNTA Explains
Before an AI agent gets the keys: five questions a demo cannot answer
Intel's warehouse demonstration and IBM's agent-identity announcement point to a practical buying question: what can an agent do, under whose authority, and how can you stop it?
A successful demonstration shows that a task can work under the conditions chosen for the demonstration. It does not, by itself, establish how safely or economically the same system will operate in your business. That distinction matters when software moves from proposing an answer to taking an action.
On 28 October, Intel described a proof of concept with SAP connecting SAP Extended Warehouse Management to Intel-powered edge AI and robotics. According to Intel, warehouse requests become robot tasks and completion information returns to the business system. Intel reports operational improvements; ZEVRYNTA has not independently measured those results.
A separate IBM announcement on 27 October described agent discovery, identity, access controls and evaluation, including extending HashiCorp Vault controls to AI agents. These are IBM's product claims, not findings from a ZEVRYNTA test. The two announcements address different systems, but they expose a shared procurement problem: an agent's ability to act is only part of what a buyer needs to evaluate.
1. Define the action, not just the ambition. Ask the supplier to list exactly which systems the proposed agent can read and which it can change. Drafting a purchase order and submitting one are different permissions. A useful pilot specifies which actions require a person's confirmation and which are permitted without it.
2. Ask who can revoke authority. Request a demonstration in which access is withdrawn while a task is pending. The question is not whether the model promises to stop; it is whether the connected application refuses the action. Establish a named operational owner and an escalation route before granting production access.
3. Test the uninteresting failures. An unavailable database, duplicate request or delayed response can reveal more about an integration than a polished happy-path demo. Ask what happens to a half-finished task, whether it is retried, and how duplicate actions are prevented. For physical equipment, assess the separate equipment-specific safety controls with qualified operators; a software demonstration is not a safety certification.
4. Price a completed, acceptable task. Compare the full workflow cost, including human correction, integration and exception handling, rather than model-call price alone. Agree on a small representative task set and an acceptance rule before a pilot. Do not treat a vendor's survey, forecast or demonstration result as your own business case.
5. Require an exit path. Ask how you export task history, identify unfinished work and remove access when the pilot ends. A reversible pilot makes it easier to learn without making the supplier's preferred architecture an irreversible commitment.
The practical next step is a bounded pilot with explicit authority, failure cases, acceptance criteria and a stop procedure. These questions are an editorial evaluation checklist, not a ranking of Intel, SAP or IBM products. We have not tested the announced capabilities, verified a return on investment or received evidence that the illustrated event proves production readiness.