AI agents that operate systems without an API: what Strada's announcement shows

What was announced

According to the company, the logic is simple: if there is an API, the agent uses the API. If there is not, it does the work in the browser, and every step is logged. The feature lets users record a workflow once and replay it later, with no custom development needed for each portal.

In insurance, this means looking up policies, updating records or filing claims on insurer portals that only allow manual operation. The feature has been made available to all Strada customers.

Why this matters outside insurance

The lack of an API is one of the most frequent reasons automation projects stall halfway. An old DMS at a car dealership, an automaker's portal, a supplier's system or an ERP customized years ago: all are examples of systems where the information exists but is only accessible through the screen.

Until recently, the alternative was traditional robotic process automation (RPA), which follows rigid scripts and breaks with any layout change. Agents built on language models can interpret the screen and adapt to small variations, which makes the approach less fragile — though not immune to failure.

When browser automation makes sense

Operating a system through its interface should be treated as a solution for when there is no better alternative, not as the default.

• The system has no API and none is planned: this is the clearest case.
• Volume is significant, but not extreme: screen-based automation is slower than a direct integration and does not scale the same way.
• The process is stable: workflows that change every week require constant maintenance.
• The cost of a formal integration is disproportionate: when the vendor charges a lot or takes months to grant access.

The safeguards the approach requires

The announcement itself highlights operational issues that do not come up with an API integration. An agent that navigates a system needs a login, a password and an active session — and that changes the risk profile.

• Credentials: the agent should use its own user account, with minimal permissions, and never an employee's personal account.
• Logging every action: you need to know exactly what the agent clicked, filled in and submitted, for auditing and for investigating errors.
• System changes: a layout update can cause the agent to take the wrong action. Monitoring and alerts are mandatory.
• Irreversible actions: deletions, submissions and payments should require human confirmation until the workflow has a proven track record.

An API is still the preferred path

Whenever a formal integration is available, it is faster, more stable and easier to audit. Browser automation expands what can be automated, but it does not replace a sound integration architecture.

In practice, the most robust projects combine the two: APIs where they exist, and agents operating the interface only where there is no other option, always with logging and well-defined limits.

Frequently asked questions

What is the difference between this kind of agent and traditional RPA?

Traditional RPA follows a fixed script of clicks and breaks when the screen changes. An agent built on a language model interprets the content of the screen and can handle small variations. Even so, major changes to the system require the workflow to be reviewed.

Is it safe to give an AI agent access to a system?

It can be, as long as the access is treated like that of a new employee with limited duties: its own user account, minimal permissions, logging of every action and human approval for irreversible operations. Sharing an employee's password is not acceptable.

Is it better to automate a legacy system or migrate to a new one?

It depends on the time horizon. If a migration is planned soon, automating the screen can be a useful stopgap. If the system will stay in place for years, it is worth assessing whether a formal integration or a migration pays off in the long run.