An agent can read a policy, compare an invoice, decide what should happen next, and explain its reasoning. Then it reaches the point where work becomes real: update the record in an old ERP, open a ticket in an internal desktop tool, or submit a change through a portal with no useful API. That is where a capable agent often stops.

This gap can look like a model problem. In the workflows Graft targets, the missing piece can instead be an action surface with clear inputs, narrow permissions, known failure states, and source-system verification.

Business workflows do not arrive as clean APIs

A company may run on a mix of software generations. There may be a modern API beside a twenty-year-old desktop client, a mainframe session behind a virtual desktop, and an internal web tool that only three people understand. Even when an API exists, it may expose data without exposing the full workflow. The employee still has to move through screens, apply rules, collect an approval, and check that the system accepted the change.

These systems may encode years of operating logic, controls, training, and reporting. Replacing one can be a much larger project than exposing a bounded workflow.

The practical question

How do you make one valuable workflow usable by an agent without turning the source system into a renovation project?

The interface contains more information than it appears to

The interface exposes required fields, allowed transitions, application state, error conditions, and the confirmation returned after an action.

That makes the interface a useful place to begin. But beginning with the interface does not mean asking an agent to rediscover the workflow from scratch every time. Repeated screen navigation leaves too much open at execution time: which control to choose, whether the page finished loading, whether a warning changed, and whether the final state means what the agent thinks it means.

A demonstration can tolerate that uncertainty. An operating workflow cannot. The behavior has to move out of the prompt and into a contract.

Turn the workflow into an explicit action

A contract gives the agent a bounded task. Instead of “open the application and work out how to create this order,” the agent calls an action with typed inputs. The action knows the permitted path through the interface, the conditions that must hold, the effects it is allowed to produce, and the evidence expected at the end.

Graft is being built around this model: observe the real workflow, model its states and side effects, compile a policy-bounded action, and verify the result against the source system. The goal is to publish that action as a stable tool an agent can call.

  1. Observe

    Map the real screens, inputs, states, and exceptions.

  2. Model

    Describe what the workflow can do and under which conditions.

  3. Compile

    Create a typed action with permissions and known failure behavior.

  4. Verify

    Check the intended effect in the system that owns the record.

  5. Connect

    Give the agent a stable tool instead of a new navigation problem.

Why not start by replacing the system?

Sometimes replacement is the right decision. It is rarely the smallest path to proving an agent can improve a specific workflow. A company should not have to migrate an ERP, rebuild an internal application, or wait for a broad modernization program before testing whether an agent can remove a painful operational step.

Graft is based on a narrower bet: preserve the system of record and create a dependable boundary around the work an agent needs to do. The source application continues to own its data and rules. The agent gets a controlled action rather than direct, open-ended access.

Start with one bounded workflow

A strong first workflow is specific enough to inspect and important enough to matter. It has a clear beginning, a clear business effect, and someone who can explain what success and failure look like. It is painful today because the software is hard to integrate—not because nobody understands the process.

A useful first-workflow brief
  • What outcome should the agent produce?
  • Which application and screens are involved?
  • Why is the available API insufficient or unavailable?
  • Who may approve or initiate the action?
  • What source-system evidence proves success?
  • What should happen if the interface or application version changes?

Why we are building Graft

New model capabilities do not automatically make a company’s existing software agent-ready. Important workflows may remain behind interfaces in systems that are costly or risky to replace.

We are building Graft to provide bounded actions through those interfaces—not unrestricted screen control or brittle coordinate sequences. Each action should carry the workflow’s rules, enforce its permissions, and return evidence from the source system.

A practical path to a useful agent may begin with one workflow it cannot reach today.