Legacy portals are no longer a reason to delay AI automation

One of the easiest ways for a workflow to dodge automation used to be this:

"Part of the process lives in a portal."

That single sentence blocked a lot of otherwise obvious ROI.

The team might have had a CRM, ERP, shared inbox, and internal database wired up reasonably well. But one critical step still depended on a human opening a browser tab, checking a third-party system, downloading a document, copying values into another system, and nudging the next person in line.

That is still not ideal.

But it is much less disqualifying than it was even a year ago.

What changed

Three market shifts matter here.

First, the models got better at multi-step operational work. On December 17, 2025, OpenAI said enterprise usage was deepening into repeatable, multi-step workflows, with average reasoning token consumption per organization up roughly 320x year over year. That matters because portal-heavy workflows are rarely one-shot tasks. They require state, branching, validation, and judgment about when to escalate.

Second, connected tool access is becoming more standardized. Anthropic introduced MCP on November 25, 2024, then said on December 9, 2025 that the ecosystem had grown to more than 10,000 active public MCP servers and had been adopted across major AI products. Buyers should pay attention to that because integration friction has historically been one of the main reasons AI projects stalled after the demo.

Third, browser-level action is now part of the serious conversation. OpenAI's computer use tooling makes it possible to build agents that can click, type, scroll, and operate inside browser environments. That does not mean every workflow should be driven through the UI. It means workflows that include a few unavoidable browser steps are now much more practical to automate inside a controlled system.

What this means for buyers

The practical implication is simple:

"We have too many portals" is getting weaker as a reason to wait.

That does not mean the old engineering rules disappeared.

API-first is still the better operating model when it is available. It is more stable, more auditable, and easier to maintain. But many real businesses do not get to choose between a perfect API-based workflow and a messy one. They choose between:

• leaving the work manual
• automating the stable system-to-system pieces now
• containing the browser-only steps behind guardrails

That middle option is increasingly viable.

For a lot of teams, that is enough to move a workflow from "too messy for automation" to "worth shipping."

The right way to use this capability

The mistake would be treating browser automation like magic.

Portal-heavy workflows should still be designed as bounded systems, not autonomous free-for-alls.

The strongest pattern is usually:

1. Use direct integrations and APIs wherever they exist.
2. Use models to interpret messy inputs such as emails, PDFs, screenshots, and forms.
3. Use browser actions only for the last-mile steps that cannot be handled another way.
4. Put approvals, confidence thresholds, and escalation paths around any high-risk action.
5. Monitor exceptions like an operations system, not a one-time bot setup.

That is a very different posture than the old RPA promise of "record a workflow and hope the screen does not change."

Which workflows are newly worth revisiting

This is especially relevant in workflows where the business pain is already obvious and one external portal keeps the whole process manual.

Examples:

• insurance verification across payer portals
• claims or case status checks that start in email and end in a portal
• customer onboarding workflows that require document pulls from third-party systems
• finance operations that mix inbox intake, internal approvals, and vendor portals
• logistics and operations queues that still depend on human status lookups

These are not glamorous use cases. That is exactly why they matter.

If one human is spending all day being the bridge between systems, there is usually margin hiding in the gap.

The new buying question

A year ago, a fair question was:

"Can AI handle this messy workflow at all?"

In 2026, the better question is:

"Which parts of this workflow should be API-first, which parts should be model-assisted, and which parts need bounded browser action?"

That framing is more useful because it reflects how real systems get deployed.

You do not need perfect conditions to get value. You need:

• a clear unit of work
• a measurable definition of done
• a contained risk model
• someone who owns the workflow after launch

If you have those four things, many portal-heavy workflows are back on the table.

What authoritative buyers should ask vendors now

If a vendor says they can automate a cross-system workflow that includes legacy tools or portals, ask:

• Where are you using direct integrations versus browser actions?
• What happens when the portal layout changes?
• What requires human approval?
• How do you detect drift or repeated failures?
• Who owns maintenance after launch?
• How is the work priced once the workflow is live?

Those questions separate a durable operating model from a flashy demo.

The trend worth paying attention to is not just that models are smarter.

It is that the stack around them is finally making ugly operational environments more automatable than they used to be.

That is very good news for buyers whose real bottleneck is not "writing faster."

It is getting work through systems that were never designed to cooperate.

Sources

• OpenAI, "The state of enterprise AI" (December 17, 2025)
• Anthropic, "Introducing the Model Context Protocol" (November 25, 2024)
• Anthropic, "Donating the Model Context Protocol and establishing the Agentic AI Foundation" (December 9, 2025)
• OpenAI API docs, "Computer use"

If one portal or external system is the reason your workflow still runs manually, run the calculator or book a workflow audit.