When an app has no API: should an agent operate its interface?

Retrospective · week of 28 September 2026

Your team copies information into an older application every week. There is no obvious connector to link it to the rest of your tools. The temptation is straightforward: ask an agent to click through the screens instead of a person. Before choosing that approach, establish what the process actually requires and how its result can be verified.

Another option, not a universal shortcut

On 29 September, OpenAI added a hosted browser to the Agents API, with access approvals managed by the application. Source: official changelog.

This is a reason to revisit certain interface-based tasks, not to assume they will work in your application. The approach below is a scoping method, not a compatibility guarantee or a recommendation to bypass a provider's restrictions. An interface that an employee can access does not automatically permit every form of automated use.

Examine four routes, in order

First, check whether a documented API or official connector supports the specific action. “Connected” may mean read-only access; it does not establish that changes are possible. Ask exactly which fields and operations are supported, rather than relying on a general integration claim.

Second, investigate structured exports and imports. For a weekly update, a controlled file may be easier to supervise than a sequence of clicks. You still need to examine duplicate handling, format errors and the report produced after an import. Someone must be able to distinguish accepted rows from rejected ones.

Third, test the interface, strictly within the authorized scope. Identify the screens, confirmations and evidence expected after each operation. A dialog disappearing is not, on its own, proof that a record was saved successfully.

Fourth, retain a manual step. If volumes are low or errors have significant consequences, preparing the information for a person may be a better first project than automating the entire sequence. Partial automation can still address the most repetitive part of the work.

Illustrative example: updating an internal reference

Imagine a fictional application without a suitable API. The task is to copy a case reference into an already identified record. The test starts with fictional data, a single record and an easily recognizable value. It checks the record identifier before entering anything, then reads the record again after saving.

The scenario must also cover a missing record, two similar search results and an expired session. In these cases, the agent stops and provides useful context for a person. It does not guess or try to evade authentication. This example describes a demonstration protocol, not an integration SWM has already delivered.

Define stopping conditions before starting

List the changes that require intervention: an unexpected screen, additional permissions, a warning, uncertain record identity or missing confirmation. Also specify which steps remain exclusively human, including consequential approvals that have not been authorized.

Keep a proportionate operational record without unnecessarily storing the information displayed. After an interruption, recovery should start by checking the actual state. Repeating an entry because the system does not know whether it succeeded can turn a technical interruption into a business error.

Measure work removed and work displaced

Assess supervision time, blocked attempts and ease of correction, not just clicks saved. Assign someone to review the test when the application changes. If nobody can maintain the scenario, reconsider its scope.

An automation project should therefore begin with a verifiable method. AI consulting helps frame that decision before committing to a fragile integration.

Let's examine your business software's options before choosing an automation method.