There is an idea that, stated in its most extreme form, sounds almost absurd:

I do not want to use your product; I want my agent to be able to use it for me.

But the more we look at the current agent ecosystem, the less absurd it seems.

A comment in the discussion around WebMCP used Jira as an example. The point was not that Jira had stopped being useful. It was exactly the opposite: Jira could become even more important while the user opened its interface less often.

Why?

Because the agent can turn Jira into infrastructure.

Instead of doing this:

open Jira
   ↓
find project
   ↓
create issue
   ↓
fill fields
   ↓
assign priority
   ↓
link epic
   ↓
publish comment

the user could simply say:

"Turn the code-review findings into three issues,
prioritize them, link them to the epic, and assign them to the developer."

And underneath, something like this would happen:

User
   ↓
Agent
   ↓
MCP / API / WebMCP
   ↓
Jira

The user has not stopped using Jira in the economic or functional sense.

What they have stopped doing is manually operating the Jira interface.

That is an enormous difference.

The application is still there; who operates it changes

For decades, the dominant software model was relatively stable:

person
   ↓
graphical interface
   ↓
application
   ↓
backend

The frontend was the mandatory gateway.

If you wanted to create a ticket, you opened Jira.

If you wanted to review messages, you opened Slack.

If you wanted to manage payments, you opened Stripe.

If you wanted to modify a repository, you opened GitHub.

APIs existed, but they were primarily designed for integrations, scripts, and developers.

With agents capable of using tools, the topology starts to change:

                 ┌── GitHub
                 ├── Jira
User → Agent ────┼── Slack
                 ├── Stripe
                 └── other tools

Now the interface the user experiences can be a conversation, an IDE, voice, or even an automation running in the background.

Applications still provide the most valuable pieces:

  • data;
  • business rules;
  • permissions;
  • history;
  • identity;
  • storage;
  • workflows;
  • integration with other systems.

But their UI no longer has to be the primary interaction point.

In that sense, the application begins to look like a specialized backend for agents.

The Jira example is no longer merely theoretical

Atlassian now offers the generally available Rovo MCP Server, allowing external AI clients to work with Jira and Confluence through Model Context Protocol.

The company itself frames the idea in terms very close to this paradigm shift: reducing context switching and bringing Atlassian work into the environment where the user is already working.

That makes flows like this possible:

Codex reviews a PR
        ↓
finds three problems
        ↓
queries the epic in Jira
        ↓
creates three issues
        ↓
links repository evidence
        ↓
assigns priority
        ↓
continues working

The developer may end up using Jira much more intensively than before.

But perhaps they never opened jira.com even once.

That is the paradox.

Product usage rises while interface usage falls.

From “time spent in app” to “capabilities consumed”

This shift can be uncomfortable for many SaaS companies because for years a large part of product success was measured using metrics such as:

DAU
MAU
time in app
sessions per user
screens visited
clicks

But those metrics begin with an assumption:

the human directly operates the application.

In an agent-first world, more important metrics may look different:

actions completed
capabilities consumed
successful tool calls
workflows finished
value produced

A user could go from opening Jira twenty times a day to opening it twice a week while simultaneously processing five times as much work through Jira.

That forces us to separate two things that used to be highly correlated:

product usage ≠ interface usage

And it will probably change pricing, analytics, and growth as well.

Your agent can become the primary interface

This may be the deepest conceptual change.

Today we think of our tools as destinations:

"I go to GitHub"
"I go to Jira"
"I go to Slack"
"I go to Stripe"

In a truly agent-first environment, the user can think differently:

"Agent, solve this."

Then the agent decides which systems it needs.

For example:

"Investigate why the deployment failed,
open the necessary issues,
notify the team, and prepare the rollback."

The agent could then use:

GitHub → inspect commit and CI
Jira   → create incident issue
Slack  → publish summary
Cloud  → query deployment status

The person stops functioning as the human integration bus between applications.

That matters because a huge amount of digital work today consists precisely of manually transporting context:

copy from A
paste into B
interpret B
return to A
open C
update D

Agents are especially valuable when they can eliminate that layer of mechanical coordination.

“Bring your own agent” changes the relationship with SaaS

A second strong idea appears here.

Many companies are building their own agent inside their product:

Product A → Agent A
Product B → Agent B
Product C → Agent C

But the user ends up with a new problem: now they have to manage ten different agents, each with its own memory, interface, permissions, and context.

The alternative is almost the reverse:

                 ┌── Product A
                 ├── Product B
My agent ────────┼── Product C
                 └── Product D

That is the bring your own agent model.

The user chooses the agent that already knows their context and preferences —ChatGPT, Claude, Codex, Cursor, or another— while products compete to expose high-quality capabilities to it.

That does not mean embedded agents disappear.

They can remain excellent for onboarding, support, and users who do not want to configure anything.

But they stop being the only channel.

A good agent-first product could simultaneously offer:

human UI
+ built-in agent
+ API
+ MCP
+ WebMCP
+ handoff to external agents

The question stops being only:

how good is my interface?

And begins to include:

how easy is it for an external agent to discover and use my capabilities?

WebMCP pushes this idea into the web page itself

In our previous analysis of WebMCP we saw a particularly interesting piece of this future.

WebMCP proposes that a page expose structured tools directly to browser agents.

Instead of forcing the agent to look at the screen and infer:

"that blue rectangle is probably the Create ticket button"

the page could publish something conceptually like:

create_issue({
  title,
  description,
  priority,
  assignee
})

Chrome describes WebMCP precisely as a way for sites to actively participate in agent interactions through structured tools, reducing the ambiguity of operating an interface through clicks and text.

That changes the role of the frontend.

Before, it was exclusively the visual representation of the product.

Now it can also become a semantic capability surface for agents.

MCP and WebMCP do not do exactly the same thing

It is worth separating the two layers.

With MCP we can have something like:

Agent
   ↓
MCP client
   ↓
MCP server
   ↓
Jira / GitHub / filesystem / database

With WebMCP:

Browser Agent
   ↓
Browser
   ↓
WebMCP tools
   ↓
Web application and current session

Chrome’s documentation emphasizes that WebMCP and MCP are complementary, not substitutes.

That enables an interesting architecture:

                 ┌── MCP → backend and integrations
Agent ───────────┤
                 └── WebMCP → capabilities tied to web session

For the user, the distinction may eventually be invisible.

They simply request a task.

The agent chooses the most reliable channel.

The UI does not disappear

It is tempting to take the idea too far and conclude that graphical interfaces will disappear.

Probably not.

There are many situations where a UI remains better:

  • exploring visual information;
  • comparing options;
  • discovering new capabilities;
  • reviewing results;
  • understanding complex states;
  • confirming irreversible actions;
  • correcting agent decisions.

A more plausible architecture is hybrid:

Agent does the mechanical work
            ↓
UI shows state and result
            ↓
Human reviews / confirms when it matters

For example:

Agent prepares a purchase
        ↓
UI shows price, product, and address
        ↓
User confirms
        ↓
System executes payment

The interface stops being a requirement for every operation, but remains a powerful supervision surface.

The real moat may move

If users interact less and less with the UI, a strategic question appears immediately:

what differentiates a product when an agent sits in the middle?

Some traditional advantages may lose relative weight:

beautiful navigation
microinteractions
memorable menus

While others may gain enormous importance:

data quality
action reliability
latency
clear permissions
stable schemas
authentication
observability
audit logs
reversibility
price

For an agent, a tool that works 99.99% of the time may be more valuable than a spectacular interface.

That could create a new product-design discipline:

Agent Experience, or AX.

In the same way that we spent years optimizing Developer Experience for APIs and SDKs, we will now have to optimize the experience agents have when discovering and executing capabilities.

Pricing can change too

Per-seat pricing was designed around humans.

But imagine a company with:

20 employees
100 specialized agents
1,000,000 tool calls per month

What exactly is a “user” in that system?

We will probably see new combinations:

human seats
+ agent consumption
+ action volume
+ per-tool limits
+ reserved capacity

This begins to look less like selling access to an application and more like selling access to capability infrastructure.

And that transition directly affects the SaaS business model.

Security becomes part of the product

Allowing external agents to operate real systems is not only a connectivity problem.

It is an authority problem.

If an agent discovers tools such as:

create_issue
send_message
approve_invoice
refund_payment
delete_project

we need concrete answers to questions such as:

who authorized the agent?
what scopes does it have?
which operations require confirmation?
what limits exist?
how is each action audited?
how is access revoked?
what can be undone?

That is why agent-first infrastructure will not simply be “add an endpoint for LLMs.”

It will need serious permission, identity, logging, and human-in-the-loop models.

Companies that solve this layer well will have an important advantage.

The tweet that crystallizes the idea

The discussion that inspired this analysis is condensed in this tweet by Dillon Mulroy.

The thesis can be summarized like this:

I do not want to be forced to use every product’s agent; I want my own agents to be enabled to use those products efficiently.

It is a small difference in wording and a huge difference in architecture.

The first model tries to bring the user into the provider’s agent.

The second tries to bring the provider’s capabilities into the user’s agent.

Model A
User → product's agent → product

Model B
User → their agent → many products

If the second model gains ground, competition between applications changes.

It is no longer enough to be an attractive destination.

You also need to be a good component inside another agent’s workflow.

From applications to cognitive infrastructure

The web and SaaS grew around interfaces designed for humans.

Agents do not eliminate those interfaces, but they add another abstraction layer.

We can view it as an evolution:

Era 1
Human → UI → application

Era 2
Human → scripts / APIs → application

Era 3
Human → agent → tools → applications

In the third era, the agent becomes the coordinator.

GitHub can become the backend for code.

Jira, the backend for issues.

Slack, the backend for communication.

Stripe, the backend for payments.

And a huge number of applications may begin competing less to “be the place where you work” and more to be the infrastructure your agent chooses when it needs to do something.

That is the paradigm shift.

We do not necessarily stop using software.

The opposite may happen.

We use far more software, but see less and less of it.