What both kinds of automation depend on
Most of the writing about agents in August treated them as a new category of software. The incident write-ups from the same month describe something more familiar. A Comet browser session talked into handing over a one-time password, and a four-year-old UiPath robot typing into the wrong field after a vendor release, come back to the same dependency, and we think the industry is filing them under separate headings when it should not.
A UiPath robot that has run supplier onboarding for four years and an LLM agent wired up last month get filed as different categories of software, and they break for the same reason. Both reach into a surface owned by somebody else, read what is there at that moment, and act on it without a published contract covering the format of what they read. The robot reads a rendered application window. The agent reads page text, tool output or a document.
MIT's Project NANDA report on enterprise generative AI, covered on 19 August 2025, put the share of organisations seeing no business return at 95 per cent, and attributed the failures to brittle workflows, weak contextual learning, and misalignment with day-to-day operations. That figure reached us through the coverage rather than the report, so we treat it as indicative and would not put it in a business case. The brittleness is the part we act on, because it occurs at the join between the automation and the systems around it, in the selectors, file drops and page reads that connect one system to another.
We apply the same distinction when reading a legacy estate. Each workflow is sorted by what it depends on: a documented endpoint whose response can be validated, or the position of a control on a screen, the title of a window, and the column a value occupied when the process was recorded. The second group is reviewed first, because a change made outside the automation affects it without producing any error.
Brittle boundaries in an RPA estate
In UiPath, a selector is an XML fragment identifying a UI element by attributes such as automationid, name, cls and idx. The attribute we look at first is idx, the ordinal position of a matching element among its siblings, which recorded selectors can include. Add a field, reorder a grid, or let the vendor ship a build with a different control hierarchy, and idx points somewhere else. The selector still matches an element, that element is the wrong one, and the robot types into it and carries on.
Power Automate Desktop carries the same dependency in its UI automation actions, which record element paths against a running window. The pattern repeats in Excel macros addressing cells by position, Citrix sessions driven by image matching, and any step keyed on a window title. A vendor withdrawing a feature does the same damage. Microsoft deprecated the format data by examples feature in the Power Automate classic designer in the first week of August 2025, and Cards for Power Apps was deprecated and no longer supported from 29 August 2025, so cards built and shared in Microsoft Teams stopped functioning.
When we document an estate we list these couplings per process: which selectors are positional, which steps read a screen, which depend on a file arriving in a folder, and which call an API. The migration order comes off that list, starting with the processes carrying the most positional and screen-reading steps.
Brittle boundaries for an AI agent
Brave's security team published research on 20 August 2025 into Perplexity's Comet browser, and the sequence is worth following step by step, because every stage of it is something an RPA estate would recognise. Asked to summarise a page, Comet passed the page content to the model without separating the user's request from the untrusted page text. Instructions hidden behind a spoiler tag in a Reddit comment were executed by the agent. It opened the user's Perplexity account page and read the email address, navigated to a lookalike domain and signed in with that address to trigger a one-time password, read the password in Gmail where the user was already signed in, and posted both the address and the password as a reply to the original Reddit comment.
Anthropic released a Claude extension for Chrome as a limited research preview on 25 August 2025 and published its own red-team numbers, which we would rather have than nothing. Browser use without their mitigations showed a 23.6 per cent attack success rate when deliberately targeted, reduced to 11.2 per cent with mitigations in autonomous mode. On a challenge set of four browser-specific attack types the mitigations reduced attack success from 35.7 per cent to zero. Those figures come from their own testing, so what they show is how far the mitigations moved the result, and they carry no information about the rate an ordinary deployment would see. The attack surface they describe includes hidden form fields in a page's DOM that are invisible to a human reader, and injections carried in URL text and tab titles that only an agent would see.
Simon Willison wrote on 25 August 2025 that trusted instructions and untrusted content are concatenated into the same stream of tokens, which makes separation inside the model hard to enforce. He expects the concept of an agentic browser extension to be fatally flawed, and records that Perplexity's attempted fixes were bypassed. Our reading is that the agent occupies the same structural position as the UiPath selector, reading a surface it does not own, and that surface changes when a vendor redesigns a page or when someone adds hostile text to it.
The model itself is a dependency of the same shape, and August made that point without much subtlety. GPT-5 shipped on 7 August 2025, and several older models including GPT-4o, GPT-4.1 and GPT-4.5 were retired from consumer ChatGPT with no deprecation period. Willison recorded the next day that Sam Altman had said within hours that GPT-4o would be brought back for paid users, and his update of 12 August records it back in the model picker for all paid users by default. The change affected consumer ChatGPT only and the API kept older models under its published deprecation policies, which is one reason we pin a dated model snapshot in code and would not run a production process against a consumer product.
Silent degradation in both systems
Most software failures announce themselves through a mechanism the caller can check, such as the status code returned by a failed HTTP call or the exception raised by a failed database write. An RPA robot clicking the wrong element produces no equivalent signal. The click lands somewhere, the next activity runs, the workflow completes, and Orchestrator logs a successful job. The robot's success criterion is that each activity executed, and whether the right record was updated is not something it checks.
An LLM agent gives even less warning, because its output is well formed whether or not it is correct. Give it a page with a changed layout, a PDF that scanned badly, or a supplier email in a format it has not seen, and it returns fluent text in the expected structure, with no parse error to catch. The classification is wrong at a low rate across thousands of runs, which shows up only if outputs are sampled and checked against the source records. Without that sampling, a reported success rate only tells you that the runs finished.
The MIT coverage records a related learning gap, where most generative AI systems do not retain feedback, adapt to context, or improve over time. A system that misreads a new document format keeps misreading it on every subsequent run until somebody samples the output and finds the pattern.
Which boundaries we trust
A durable boundary has a published contract, a version, and a defined error condition. An API with an OpenAPI schema and a published deprecation policy provides all three. A rendered application screen carries no version number and no error condition, and its layout is whatever the vendor shipped in the last release. When we modernise a workflow the first question we ask of each step is whether the underlying system exposes an endpoint for what the robot did through the UI, and we check the vendor's API documentation for every step before accepting that it does not.
Where a step needs reading, classifying or interpreting, that step goes to the model and the rest of the workflow stays in ordinary code. The model returns structured output against a JSON schema, and Python validates the result: mandatory fields per record type, format checks on identifiers, cross-field consistency, date ranges, and a confidence threshold per field. Anything failing validation stops and goes to a person. Text the model read from an email, document or web page is treated as data, and instructions found in that text never trigger a tool call. After the month Brave and Willison have just documented, we would treat that last rule as the minimum any agent deployment has to meet.
The remaining piece is instrumentation. Every run records what it read, what it decided and what it wrote, so a wrong outcome traces back to a specific input. Assertions check business outcomes: the invoice total in the target system matches the source document, the record count out equals the count in, and the same message ID cannot create two records. Outbound work such as an email to a supplier or a payment record waits for a person to approve it before it leaves the system.
The licence bill for an estate that has been sitting untouched for a few years is the next thing worth pulling apart. A clean answer depends on knowing which processes still run and how often, and that is rarely written down anywhere.