Make the software you already run usable by agents.

The problem starts after the model makes a decision

An agent may be able to read a request, apply a policy, and determine the right next step. The deployment still stalls if that step exists only inside a desktop client, browser portal, internal application, virtual desktop, or other interface without an adequate action surface. A person then has to re-enter the decision into the system of record.

That handoff can be appropriate when human judgment is required. It is unnecessary friction when the person is only translating a known action into clicks. Graft focuses on this workflow-access gap. It does not assume that every legacy system should be replaced, or that every interface should be opened to an autonomous agent.

An interface-to-tool layer, governed around the action

Graft starts with a real workflow and the interface through which it is performed. The workflow is modeled as a contract: accepted inputs, relevant application states, allowed transitions, expected effects, exception paths, and evidence of completion. The resulting tool is intended to give an agent one explicit capability instead of unrestricted access to an application.

The source application remains the system of record. A tool should report success only when the intended business effect can be checked there. Moving a pointer, submitting a form, or reaching a confirmation screen is operational evidence, but it is not automatically proof that the record is correct.

The principles behind the product

• Use a supported API when it exposes the complete workflow with suitable controls. An interface-backed tool is for the gap that remains.
• Scope access to a business action, not an entire application. Read, create, update, approve, and cancel permissions should not be treated as interchangeable.
• Keep approvals and policy checks at the action boundary so they apply regardless of which agent requests the work.
• Return evidence from the source system, including identifiers, read-backs, status transitions, or other facts appropriate to the workflow.
• Treat interface drift as a change-management event. A changed screen, field, or application version may require isolation, testing, and recertification before writes resume.
• Describe limitations openly. Suitability depends on the application, delivery environment, authentication method, workflow, exception rate, and evidence available.

Start with a workflow, not a transformation program

A useful evaluation begins with one consequential but bounded workflow. The team should be able to identify its owner, inputs, decision points, write effects, approval rules, exception paths, and the system fact that proves completion. This creates a concrete basis for deciding whether an API, existing automation, human handoff, or interface-backed tool is the right solution.

Graft is not a claim that every workflow can or should be automated. It is a way to investigate whether a specific inaccessible action can become a governed tool without first replacing the system that contains it.

Frequently asked questions

Is Graft a general-purpose computer-use agent?

No. Graft is being built around repeatable, bounded actions with defined contracts and controls. Open-ended exploration may be useful during discovery, but recurring business operations need a narrower execution boundary.

Does Graft replace existing business software?

No. The product model preserves the existing application as the system of record and exposes a workflow-specific tool around it. Replacement may still be the right strategic decision for other reasons.

Which applications does Graft support?

Suitability is assessed at the workflow and environment level. Graft does not claim universal support for named applications, versions, authentication setups, or delivery environments.