Give AI agents a controlled path into software the business still depends on.

The access gap is workflow-specific

A system may provide reporting endpoints but no supported write operation for the task an agent needs. A desktop client may sit behind a virtual environment. A custom internal tool may encode years of process knowledge without any integration boundary. In each case, the right question is not “Does this application have an API?” It is “Can the deployment invoke this exact business action with the required identity, controls, and evidence?”

Graft addresses the remaining gap by turning a known interface workflow into a narrow tool contract. The agent supplies typed business inputs; the adapter performs the permitted path; policy governs whether the action may proceed; verification checks the resulting state.

What a production-shaped action needs

• A precise operation, such as retrieving one record, updating approved fields, or creating a transaction from validated inputs.
• Preconditions that distinguish a safe run from an invalid request, including current record state and required reference data.
• An identity and authorization model that does not turn application access into a shared, unrestricted capability.
• Approval rules for sensitive fields, values, statuses, or other business conditions.
• Known error categories so the calling agent can distinguish invalid input, denied policy, application unavailability, interface drift, and uncertain completion.
• Evidence tied to the business effect: a record identifier, field read-back, status transition, or another source-system fact.

Good fit and poor fit

A strong candidate is frequent enough to matter, stable enough to model, and understood by a process owner. It has a clear start, a bounded set of effects, recognizable exceptions, and a way to verify the result. The interface may be inconvenient, but the underlying business process is not mysterious.

A weak candidate is exploratory work with no repeatable path, a workflow whose rules are disputed, or an action that cannot be verified after submission. Work that already has a complete, supported API is usually better integrated through that API. A high-risk action with no acceptable approval or rollback model may need to remain human-operated.

Evaluate the real browser, desktop, or virtual environment

A browser application, installed desktop client, remote desktop, and virtual application session can present similar screens while imposing different constraints. Session lifecycle, focus, scaling, accessibility metadata, network boundaries, clipboard policy, timeouts, and authentication all affect whether an action is suitable for a private-beta evaluation.

The workflow brief should identify the supported application version, delivery environment, role, locale, session controls, interruptions, and approval path. A successful run in one environment is not evidence of support in another, so affected actions must be retested when those assumptions change.

Preserve the system, narrow the change

Modernization and replacement programs solve broader problems, but they are not prerequisites for testing whether an agent can remove one operational handoff. An interface-backed tool can isolate the experiment to a workflow while the existing application continues to enforce its own record model and business rules.

This narrower scope also makes evaluation more honest. The team can test the supported application version, role, path, data conditions, failure modes, and evidence requirements rather than relying on a broad claim of compatibility.

Evidence for an operational decision

Before rollout, a buyer should ask for a workflow-level test plan. It should cover representative successful cases, invalid inputs, permission denials, duplicate requests, partial completion, application downtime, interface changes, and exception routing. Results should identify the exact environment and version tested.

The goal is not to prove that an agent can complete one happy path. It is to establish the boundary within which the action can be operated, monitored, and stopped safely.

Frequently asked questions

Does the software have to be old?

No. The same access gap appears in modern internal portals, custom applications, desktop clients, and browser workflows. The decisive factor is whether the required action has a suitable machine-facing boundary.

Can an agent receive access to the whole application?

That is not the intended model. Graft is designed around workflow-specific tools with explicit inputs and permissions, reducing the capability exposed to the calling agent.

What happens when the interface changes?

The affected action should fail closed when its assumptions no longer hold, then be tested against the changed environment before write access resumes. The exact mechanism depends on the deployment.

Is every interface workflow automatable?

No. Authentication, delivery environment, technical controls, variability, risk, and the availability of trustworthy evidence can make a workflow unsuitable. Assessment is specific to the action and environment.