The workflow exists. The agent has no way in.

Consider an agent working through an invoice exception. It reads the invoice, checks the purchasing policy, finds the matching order, and determines the correct next step. Completing that step requires updating a finance application through a virtual desktop. The deployment exposes neither an adequate API nor a permitted computer-use path for that action.

The reasoning worked. The use case was approved. But the deployment provides no way for the agent to complete the business action.

This is not a lower success rate. It is a hard stop between a correct decision and the business system where that decision must be executed or recorded. We call it the workflow access gap.

The blocker is missing access, not weak execution

At this stage, the deployment has no path to invoke the business action at all: no adequate API, no prepared tool, and no permitted interactive route. Questions about retries, verification, and reliability come later. First, the agent needs a way to reach the action.

The software does not have to be old. The same gap can appear in a modern internal portal, a vendor application, a custom desktop tool, a mainframe session, or a browser workflow available only through a virtual desktop. What matters is not the age of the system. It is whether the required business action is exposed in a form the agent can use.

Why access becomes the bottleneck

Without an action surface, the agent remains an advisor. It can summarize a case, recommend an update, and prepare the values. A person still has to sign in, find the record, re-enter the data, handle the interface, and report the result.

That human handoff may be reasonable when judgment or approval is required. It is a deployment blocker when the person is present only because the software has no usable machine boundary. The organization has automated the analysis while leaving the operational step untouched.

The consequence is structural. Each inaccessible workflow creates an integration decision or a continuing human handoff. A demonstration that stops before the source-system action has not automated the operational step. A better model does not create a missing access path inside an ERP or desktop application.

An API closes the gap—when it exposes the workflow

A supported API is usually the preferred path. If it exposes the complete action, provides suitable authentication and permissions, and represents the same operational path as the interface, the access problem may already be solved.

The gap remains when no API exists, when it is read-only, when the required approval or side effect exists only in the interface, or when the organization cannot use the necessary endpoint. An application can have an API and still leave one important workflow inaccessible.

The question is therefore specific: does the available API expose the action this agent actually needs?

RPA and computer use are useful—but they answer different questions

RPA can be effective for deterministic, known interface paths. For an agent deployment, a team still has to decide how that automation handles application drift, exceptions, permissions, retries, and reuse across agent systems. In some workflows, the existing RPA asset is the right foundation. In others, it remains a separate automation that was not designed as a callable, governed agent tool.

Computer use can explore unfamiliar interfaces and handle variable tasks without a prepared integration. That flexibility is valuable. A repeated business action raises a different question: should the agent rediscover the workflow during every run, or should the known action become an explicit capability with fixed boundaries?

Neither approach is categorically right or wrong. The choice depends on the variability of the work, the consequence of an error, the controls the organization needs, and how often the action will run.

System replacement solves a larger problem

Modernization may be the correct long-term decision. But an agent use case may need one bounded action, while replacing the application touches data migration, reporting, controls, training, and many unrelated workflows.

Those are different project scopes. A company can retain the system of record while creating a narrower access layer around selected actions. This does not eliminate integration work, but it allows the team to evaluate agent access without making application replacement a prerequisite.

Where Graft fits

Graft is being built for workflows that lack an adequate agent-facing action surface. Its product model starts with the real interface workflow and turns a bounded action into a stable, permissioned tool an agent can call. The underlying application continues to own the record.

This is narrower than replacing the application and more explicit than asking the agent to navigate from scratch on every run. It is also workflow-specific. Suitability depends on the application, version, authentication method, interface, action, and deployment requirements.

Graft is currently in private beta. The first useful conversation is not “Can you integrate our entire software estate?” It is “Which important workflow is blocked because the agent has no dependable way into the system?”

Diagnose the blocked workflow first

Before evaluating model upgrades, reliability targets, or rollout scale, verify that the deployment has a permitted path to perform the required business action. If it does not, the project has a workflow access problem to solve first.

Bring us one important workflow your agent cannot currently reach.