The Tool Worked. The Agent Couldn't Use It.

A successful integration test establishes access for the executor that ran it; accepting a workflow requires evidence from its intended executor through the permitted route.

Your team delivers an AI integration. The developer runs it, gets a response, and marks the work complete. On Monday, the person responsible for the workflow asks the agent to use it. The agent cannot reach the tool.

The operations lead now owns a capability the team expected to have and still cannot use. Someone has to stop their work, reconstruct the developer's setup, and decide whether the missing access is a configuration problem or a boundary that should stay closed. If a customer is waiting on the result, the handoff has become their delay too.

That customer consequence is hypothetical. The access failure came from my own operation. We had a working tool, a successful host test, and an agent that could not run the same command from its own environment.

The host test answered a narrower question than the handoff required.

The installer and the worker had different access

The integration connected a local AI assistant to an existing task relay. A small command-line adapter submitted an explicitly requested task and collected the response. The command lived in Linux under Windows Subsystem for Linux. The agent expected to use it was running through a Windows PowerShell executor with its own restrictions.

The adapter worked from the environment used to install and test it. That established something useful: the command was present and the tested route could run it. It did not establish that the consuming agent could read the files, invoke Linux, or reach the command through an approved interface.

We added a narrow Windows launcher for the adapter. It fixed the distribution, Linux user, interpreter, and command rather than exposing a general shell. A help check from the Windows host succeeded. From the agent's restricted executor, the reported error was Wsl/Service/E_ACCESSDENIED. Adapter help never appeared.

So the second green check had the same limit as the first. We had proved another route from an environment we controlled. The intended worker still lacked a verified route.

The recovery needed a separately approved invocation from that worker. A reported help check then succeeded through the approved route. Later, a retained consumer check reported successful collection from the agent's native Linux executor, with the request and returned value compared against the existing local response. Those observations belong to their respective environments. A later success does not make the earlier host test sufficient.

A tool name is only the start of the handoff

When you ask whether an agent has a tool, the answer needs an actor and an operation. Can this worker, under this identity, perform this permitted action from the environment where the work will run?

You can install the same command on a machine and get different answers from an interactive terminal, a restricted desktop agent, a scheduled job, and a service account. They can differ in visible files, executable paths, network access, credentials, and approval requirements. Sharing a physical machine does not make their access equivalent.

An operations leader should not need to diagnose each of those differences personally. But someone has to own acceptance across them. If engineering hands over a successful terminal session and operations accepts a working business process, the two teams have agreed to different deliverables.

Put acceptance in the worker's environment

For one AI workflow, name the executor that will do the work. Be specific enough to distinguish a developer's terminal from the agent's actual runtime and account. Then name the allowed operation and the result someone will inspect.

For our adapter, displaying command help answered an access question. It did not establish that a task could be submitted, that the response would arrive, or that the response belonged to the request. Each of those needed its own evidence and the appropriate authority to run the check.

For a hypothetical invoice workflow, the equivalent distinction is between opening the invoice system and creating the intended draft under the correct business account. If the workflow stops at a draft for a person to approve, acceptance should stop there too. A developer's ability to send a live invoice supplies neither permission nor a requirement for the agent to do so.

Start with the least consequential check that answers the open question. Reading help can establish that a command starts. A permitted test record can establish a particular write path. A retained request identifier and matching result can establish the observed round trip. Keep the claim as narrow as the observation.

If you cannot run the required check without new authority, record that boundary explicitly. The work can be installed while acceptance remains open. That gives the workflow owner an accurate decision instead of a green status that conceals unfinished delivery.

A denial deserves a decision

An access failure creates pressure to make the demonstration work. Someone suggests a broader account, a copied credential, or a general execution bridge. The missing capability can quietly become permission to expand what the agent may do.

Treat the denial as evidence about the current route. First determine whether the intended operation belongs within the worker's authority. Then identify the smallest approved interface that supports it. If the owner has not approved that access, keep the operation blocked and make the requested decision precise.

Our launcher was deliberately narrow. That reduced what it exposed, but it did not make the surrounding executor's restrictions disappear. Fixing the command's interface and authorizing the caller to invoke it were separate concerns.

Engineers should preserve that distinction in the result they return. A permission denial should retain its cause and identify the blocked step. If an agent silently tries a more powerful route, the eventual success can conceal a change in authority that the workflow owner never accepted.

Fail-closed behavior also needs an owner for the next move. Name who can approve the missing access, choose another permitted route, or decide the workflow should remain manual. Otherwise a correct refusal leaves the business waiting without a person responsible for resolving it.

Follow the result back to the request

Reaching the tool still leaves the result to verify. An accepted submission, an available response file, and a correctly interpreted result answer different questions. The worker needs the answer in a form it can use and associate with the original request.

The adapter retained a request identifier and caller attribution. For its bounded live check, the response had to carry the matching identity and expected value. Caller attribution helped connect the records; it was not authentication. A successful process exit alone was insufficient.

We also encountered a response the transport had returned but the adapter had not recognized. The repair was to correct the parser and collect the existing response. Sending the task again would have tested another action while leaving the original result unresolved.

That recovery detail matters to whoever operates the workflow after delivery. They need to know where to look when the agent has no usable answer, how to distinguish an access failure from an unresolved submission, and when a retry could create a second action. The integration handoff should include that path alongside the successful one.

This evidence establishes specific observed invocations. It does not certify every operation, future account change, or surrounding workflow. Keep the records identifiable so a later operator can see what was actually tested.

Try the handoff you expect someone else to use

Choose one AI capability your team already considers delivered. Identify its intended worker and one harmless operation within that worker's existing authority. Ask for the check from that environment, without borrowing the developer's account or adding access to get through it.

Follow the result to the place the next person uses it. If the check stops, identify the exact boundary and who owns the next decision. If it succeeds, record which operation and route succeeded. One observation establishes that path; it does not clear every path the agent might later need.

Then look at the delivery record. Does it name the actual executor, the permitted action, the result that was inspected, and the person responsible when it fails? Those details let operations distinguish an installed component from a workflow they can depend on.

I want the acceptance check to follow the person or agent expected to do the work. That is where the promise of the integration gets tested, and where its limitations become useful information.

If your team has an AI integration caught between a successful demo and daily use, the Readiness Scan my agency offers maps one workflow, its failure modes, and who owns its handoffs. Work with my agency on one workflow.