There are two ways to let an AI agent operate the software your business already runs. It can drive the screens a human would drive, or it can call the operations underneath them. We only build the second one, and the reason has less to do with elegance than with what happens on a Tuesday eight months in.
Screen-driving optimizes for the demo
Pointing an agent at a browser is genuinely the fastest path to something impressive. No integration work, no API access request, no coordination with the vendor. It works on systems that have no API at all. For a two-week proof of concept it is hard to beat.
Then the vendor ships a redesign. A button moves, a modal gains a step, a table becomes a virtualized list, and the automation that worked silently stops working. Worse, it keeps going and does the wrong thing. You are now on a maintenance treadmill whose cadence is set by someone else's release schedule.
The governance problem is worse than the brittleness
Brittleness is expensive. The governance failure is disqualifying.
When an agent drives a screen, the finest-grained permission you can express is "this login can access this application." You cannot say this agent may update a visit note but may not delete one, because the system on the other side has no idea it is talking to an agent. It sees a session.
The audit trail has the same ceiling. You can record what was clicked. You cannot record what was intended, which inputs were validated, what the agent considered and rejected, or what it cost. When an auditor asks why a record changed, "here is a screen recording" is not an answer.
Tools are typed, scoped, and reviewable
A tool is a named operation with a declared input schema, a declared output, and an owner. Scheduling a visit takes a patient, a clinician, and a window. It validates before it acts. It is classified into a risk tier. It is visible to exactly the agents whose scope includes it, and invisible to every other one.
That shape buys you things a screen never can:
- Permissions that mean something. Access is granted per operation, not per application. An agent that can read cannot write by accident.
- Stability across redesigns. The UI is one consumer of the operation. The agent is another. Moving a button does not break anything.
- Audit that answers questions. Every call is recorded with its inputs, its outputs, its outcome, and its cost. "Why did the agent do that" has an answer you can read.
- Approvals with evidence. Because the system knows what is being proposed and why, it can show a reviewer the case rather than a bare confirmation dialog.
No rip-and-replace
The obvious objection is that this requires your systems to have good APIs, and most do not. In practice that has not been the blocker. Wrapping existing APIs, databases, and integrations in a governed tool catalog is the work, and it takes weeks rather than quarters, because we are not rebuilding your systems. We are giving them a governed front door that agents and humans both go through.
The screens stay exactly where they are. Your staff keep using them. The agents just stop pretending to be your staff.