Agent Experience Is the Product

A lot of AI product conversations still start with the model.

Which model is smarter? Which benchmark is higher? Which context window is larger? Which one codes better?

Those questions matter. A weak model can break the entire experience. If the system cannot reason, plan, use tools, or recover from mistakes, everything around it starts to collapse.

So when people say “the model is the product”, I get the point.

But as AI systems move from answering to acting, the product is no longer just the model behind the interface. It is the loop around it: intent, context, tools, permissions, action, review, correction, and trust.

That is why recent moves from Microsoft, Google, and Anthropic are interesting to me.

Microsoft reportedly moving teams from Claude Code toward GitHub Copilot CLI is one signal. Google transitioning Gemini CLI users toward Antigravity CLI is another. Anthropic shaping Claude around role-specific plugins and subagents points in the same direction.

Different companies. Similar direction.

The agent surface is becoming strategic.

And when users prefer one agent surface over another, they are not only comparing models. They are comparing experiences.

The Model Is the Engine, Not the Full Product

The model matters a lot. It defines the ceiling of what the product can do: how much context it can understand, how well it can plan, how confidently it can generate code, and how often it can recover without help.

So yes, the model is deeply part of the product.

But taken literally, “the model is the product” misses the part users actually live inside.

A model inside another surface is not the same product. The container matters. The defaults matter. The permission model matters. The context loading matters. The review flow matters. The way plans and diffs appear matters. The recovery path matters. The way the user feels while using it matters.

Maybe the better version is:

The model is the engine. The experience is the product.

This becomes obvious when the system is not just answering a question, but acting on your behalf.

A coding agent needs to plan work, edit files, run commands, interpret errors, ask for permission, recover from bad assumptions, and show what changed. That loop is not only a model problem. It is a product problem, a UX problem, and eventually a trust problem.

The more the system acts, the more the surrounding experience defines what the product actually feels like.

flowchart LR
  U[User Intent] --> C[Context]
  C --> M[Model]
  M --> P[Plan]
  P --> X{Permission Needed?}

  X -->|Yes| R[Request Approval]
  R --> P

  X -->|No| T[Tool Use]
  T --> E[Execution]
  E --> O[Visible Output]
  O --> V[Review]
  V --> F[Feedback]
  F --> C

  V -->|Looks Good| D[Trust]
  D --> U

The model is the engine, but the product lives in the surrounding loop: context, planning, permissions, tools, execution, review, feedback, and trust.

Agent Experience Is Bigger Than Developer Experience

This is easy to see in developer tools because coding agents are already changing how engineers work. But the point is not limited to software development.

Every product with agents will need to answer the same questions.

Can I delegate work without over-explaining? Can I see what the agent is doing without babysitting it? Can I interrupt it? Can I trust its actions? Can I recover when it goes wrong?

For developers, that might mean code edits, terminal commands, diffs, tests, and repository instructions.

For finance, it might mean analysis, approvals, source material, audit trails, and risk boundaries.

For HR, it might mean employee data, policy interpretation, permissions, and sensitive workflows.

For design, it might mean taste, iteration, brand rules, assets, and review loops.

That is why the “agent type” direction matters. A finance agent, a design agent, an HR agent, and an engineering agent should not feel like the same chatbot with different prompts. Anthropic’s knowledge work plugins are interesting because they package skills, connectors, commands, and subagents around specific job functions.

The model may be shared.

The experience should not be.

That is the product shift: as agents move into real workflows, UX is no longer only about making software easier to use. It is about making delegation feel safe, visible, reversible, and useful.

Adoption Is Not the Same as Preference

Companies can standardize tools. They can reduce vendors. They can pick one stack for security, cost, integration, and platform reasons.

Sometimes that is the right business decision.

But adoption and preference are not the same thing.

Usage can be mandated. Preference cannot.

Usage is a business metric. Preference is a product signal.

That distinction matters because agents live close to daily work. The best agent is not just the one your company approves. It is the one that makes you feel faster, safer, and more capable.

This is why these platform shifts are so sensitive. Moving users from Claude Code to Copilot CLI, or from Gemini CLI to Antigravity CLI, is not only a migration between tools. It is a migration between workflows, habits, trust models, and surfaces.

The market already shows this tension: Stack Overflow’s 2025 Developer Survey says more developers actively distrust the accuracy of AI tools than trust it, even as AI usage remains a major part of modern development workflows.

That gap is where preference starts to matter more than adoption.

It is not enough to make people use the agent. They need to understand it, trust it, and feel in control when it acts.

The Product Is the Loop Users Learn to Trust

In traditional software, the product surface was mostly the app. The user clicked through screens, the interface exposed features, and the workflow was mostly hardcoded.

In agentic software, the agent increasingly becomes the active layer between the user and the system. It chooses tools, calls APIs, reads files, edits state, creates plans, renders UI, summarizes context, and decides what to show next.

The product is no longer only the screens you designed.

The product is the loop.

flowchart LR
  A[User intent] --> B[Agent interpretation]
  B --> C[Tool use]
  C --> D[Visible action]
  D --> E[Review]
  E --> F[Trust or correction]
  F --> A

A company can say:

We need to own the agent surface.

But the user silently asks:

Does your surface make me better?

That is the only question that matters.

Owning the surface is not enough. You have to deserve it.

The winning agent will not just be smarter. It will feel better. It will make delegation feel natural, review feel safe, context feel manageable, mistakes feel recoverable, and power feel bounded.

Most importantly, it will make the user feel like they are still driving, even when the system is doing more of the work.

Agentic products are not won by one magical run.

They are won by repeated trust.

People already know when an agent feels better. They may not call it Agent Experience. They may not talk about interaction models, trust boundaries, surface ownership, or workflow composition.

They will just say:

This one works better for me.

That sentence is the product signal.

And for agentic software, it might be the most important signal there is.

Because Agent Experience is not a layer on top of the product.

Agent Experience is the Product.

LoFM.