| Route | Reliability | When it applies |
|---|---|---|
| Purpose-built API / tool | High | The system has an API and you can shape the tool around the business rules |
| Protocol integration (e.g. MCP) | High | The vendor or a community exposes a server |
| UI automation / browser agent | Low to moderate | No API exists and the process is unavoidable |
| Human in the loop | Highest | Irreversible, regulated, or rare enough not to be worth automating |
The ordering is not aesthetic. Each step down loses a guarantee: an API has a contract, a protocol has a schema, a UI has neither and can change overnight without notice.
The tempting mistake
UI automation demos brilliantly. An agent filling in a supplier portal looks like the future. In our own testing, read-only tasks held up and write tasks did not - the failure was not loud errors but occasional plausible-and-wrong entries with no signal that anything had gone wrong.
What the fourth row is for
Human-in-the-loop is not a fallback for weak automation. It is the correct design for actions that are irreversible, legally significant, or so rare that the failure cost dominates the labour saved. An agent that prepares the work and asks for a confirmation is usually the highest-value version of the system, not a compromised one.
The prediction worth making: as more vendors expose protocol servers, row three shrinks. It will not vanish - authorities and legacy portals move slowly - but the fraction of business software reachable through a contract rather than through pixels is growing.