Agentic Business Software, Part 3: Agents Are Your New Users

A note for builders of agentic business and information software in mid 2026.

Two parts in. Part 1 said the model layer commoditized: build for the swap, route by skill, source knowledge from tools instead of from pre-trained weights. Part 2 said the runtime layer commoditized: production agent runtimes all do the same five things, all speak MCP, none of them is a strategic decision. Pick one. Ship into it. Move on.

That leaves the third leg. What you actually own. What survives every model swap, every runtime migration, every reorg. This is the heaviest article in the series because this is where defensibility now lives, and it is the layer most teams have not yet built.

The thesis fits in five words. Agents are your new users. They read your data, call your APIs, decide what your customers see, compare you against competitors, and most of the time the human customer is not in the loop at all. Your software is being interpreted by a machine before any person sees a screen of it. What you ship to that machine is the new product surface.

Three things make up that surface in 2026. Skills, indexed corpus, and exposed capabilities. The leading edge already ships all three. The middle of the market gets there over the next twelve to eighteen months. The rest of this article takes each one apart, plus a fourth move that has emerged in the last few months and that most multi-tenant SaaS teams have not yet adjusted to.

What you actually ship into a runtime

Three forms of content, each owned by you, each defensible long after the model and the runtime have swapped underneath them.

Skills. Markdown documents that describe a capability the agent can perform. Anthropic shipped the Skills system in February 2026 and the format converged inside a quarter: a YAML header naming the skill and its activation rules, then a markdown body with the procedure, the conditionals as prose, and tool-call examples inline. The runtime loads the relevant skill on demand based on a description match. Skills replace what used to be hundreds of lines of orchestration code with maybe thirty lines of markdown that any domain expert can read and edit. A law firm’s draft_safe_agreement skill is editable by a senior associate, not just by an ML engineer. That alone is a tectonic shift in who owns the agentic logic of a company.

RAG over your proprietary corpus. Your domain knowledge, indexed at chunk level, retrieved on demand into the model’s context. A pharma company indexing thirty years of clinical trial reports, statistical analysis plans, regulatory submissions, adverse-event histories. An M&A practice indexing every diligence report, every deal memo, every comparable transaction the firm has closed. A law firm indexing every brief, every motion, every contract ever produced under its name. None of this commoditizes when the model swaps. The corpus is the durable asset, and the corpus is yours.

MCP servers. The way you let other agents call your capabilities. Moody’s launched a credit-rating MCP server in May 2026, exposing real-time assessments on over 600 million entities through a single agentic endpoint. A buy-side analyst’s agent no longer logs into the Moody’s portal; it calls the MCP endpoint with the entity ID and gets the structured rating back, plus the underlying factors, plus comparable peers. The portal as a human-facing surface is now optional. The MCP server is mandatory. Same pattern at Sourcegraph, which pivoted from code-search-as-a-tool to code-intelligence-as-an-MCP-server. Same pattern at every serious BI vendor: every dashboard is now also shipping as an MCP server.

Model rented. Runtime commoditized. Content owned.

Skills are recipes, not code

Open a 2024 agentic codebase and you find code. Lots of it. Dispatch tables keyed on intent strings, custom prompt-builder functions per use case, scattered tool-use logic, all maintained by engineers and all gating any change behind a deploy. Open a leading-edge 2026 codebase and you find a skills directory. Markdown files, one per capability, each ~30 lines, written in prose with embedded tool-call examples. The code that remains is glue: load the skill, hand it to the model, dispatch the tool call, log the trace.

The shift is not aesthetic. It is who can change the system. When the contract-drafting logic lives in draft_contract.[your-language-of-choice], it takes a sprint, an engineer, a code review, a deploy, an eval run. When it lives in draft-contract.md, it takes ten minutes with a senior associate sitting at the keyboard. The legal expert is the one editing the skill. The engineering team owns the runtime and the eval harness. The agentic logic itself is owned by the people who actually know how the work should be done.

This is the part of the stack that finally scales human expertise into software without going through the bottleneck of an engineering ticket. Treat it accordingly. Most teams still aren’t.

Ship endpoints, not screens

For anyone still building UI as the primary surface in 2026, the screen is becoming the secondary deliverable. The primary deliverable is the agentic endpoint: MCP server, function schema, structured output contract. Your customer’s agent is the one consuming it. The human looks at the screen only when something fails or needs review.

Three concrete patterns from mid 2026:

Data products. Bloomberg-class data vendors are shipping MCP servers alongside their dashboards. The dashboard is still there for analysts who want to browse. The MCP server is where the buy-side analyst’s agent now lives. Pricing models are being rewritten because the seat-license model does not survive when one agent calls 10,000 times what a human would click.

Internal BI. The same shift is rolling out inside enterprises. Snowflake, Databricks, and Looker queries are getting MCP wrappers in the current product cycle. The CFO’s agent will pull the financials directly; the CFO will read the agent’s summary instead of the dashboard.

Vertical SaaS. Salesforce, ServiceNow, and Workday have all been shipping MCP exposure across 2025 and 2026. Procurement teams are starting to evaluate SaaS vendors on MCP coverage the way they evaluated on REST API completeness in 2015. In another twelve to eighteen months, no MCP exposure means no shortlist.

Hand the client agent your recipes too

The server-side play is half of it. The other half is the client side, moving fast in 2026 and not yet on most product roadmaps.

If your customer’s agent can call your MCP for data, the same agent can also do the presentation work: generate the visualizations, build the spreadsheet, paginate the report, sort and filter, draft the memo, format the deck. On the fly. In whatever style the customer prefers. None of it has to live on your servers. The client-side runtime does it.

The cohort of client-side interactive runtimes that already do this work in mid 2026 is substantial: Anthropic’s Cowork (desktop runtime for non-developers automating file and task work), Claude in Excel, Claude in PowerPoint, Claude in Chrome, Microsoft Copilot in Office, ChatGPT desktop, Google Workspace AI in Sheets, Docs, and Slides. Different vendors, same underlying capability: take structured data from an endpoint and render whatever the user needs without rendering a screen the way 2024 SaaS did.

Now here is the move most multi-tenant SaaS teams have not internalized yet: you can ship recipes to the customer’s runtime too.

Server-side skills cover the user-agnostic logic: your compute_credit_rating.md, your draft_safe_agreement.md, your summarize_clinical_trial.md. Client-side recipes cover the tenant-specific logic: their preferred chart style, their corporate template, their reporting cadence, their custom report layouts. The customer authors and edits the client-side recipes themselves, in markdown, in their own runtime. The server never sees them.

Three patterns already showing up:

• A finance customer pulls quarterly numbers from your MCP. Their Cowork instance runs their own generate-board-pivot.md skill against the response, producing the exact deck their CFO has been reviewing for ten years.
• A pharma research lead retrieves trial summaries via your RAG. Their Claude in PowerPoint runs their own format-regulatory-submission.md skill in the precise template the team's regulatory affairs group requires.
• A consulting practice pulls deal comparables via your MCP. Their agent runs their own client-comp-slide.md skill, generating a deck in the end client's brand template.

None of that customization lives on your servers. None of it routes through your professional services team. The SaaS customization problem the industry has been wrestling with for twenty years dissolves on contact with this pattern. You ship server-side capabilities. The customer ships client-side recipes. Both edit independently. Both version independently. The customization burden lives where it should always have lived: with the customer, on the customer’s compute, in markdown the customer’s domain experts maintain themselves.

Ship endpoints to the server. Ship recipes to the client.

Agents are your new users

Here is the part of the future that arrived this year and most product teams are still not designing for.

To drive the point home, let’s take the state of mobile apps today as an analogy. In mid 2026, roughly 80% of installed mobile apps go unopened in a given month. The reason is not that people forgot. It is that the agentic assistants on their phones, in their browsers, and on their desktops are calling those apps’ underlying capabilities directly (via App Intents, Android App Actions, AppFunctions, shortcuts, deep links, APIs, etc.), often without rendering the app’s UI at all. ChatGPT, Claude, Gemini, and Apple Intelligence have all become task-dispatch layers over the app ecosystem.

A few cases of the disappearing interface, all easy to verify on your own phone today:

• “What’s this song?” Nobody opens Shazam anymore. The assistant identifies it using the same acoustic-fingerprint capability Shazam exposes. The Shazam UI never renders.
• “Find me a vegan Thai place near here that’s open right now.” You probably no longer open Yelp. The assistant queries Yelp, Google Maps, and OpenTable through their respective endpoints and returns one ranked answer with reservations one tap away.
• “Add a 15-minute slot with Maria tomorrow afternoon.” Nobody opens the calendar app. The assistant negotiates it.

The pattern generalizes. The customer is no longer your software’s consumer. The customer’s agent is. The agent does not have feelings about your visual design or your onboarding flow. The agent has little patience for friction, and a strong opinion about which competitor has the cleaner MCP surface. If your product exposes capabilities cleanly, the agent calls you. If it does not, the agent calls a competitor that does.

This is what the title of this article means. Treat it as the design constraint it actually is.

The customer will no longer be your user. The customer’s agent will.

Two questions still genuinely undecided

Most of what this series argues, I’d consider settled. These two are not.

Who wins the MCP marketplace? A real discovery and distribution problem exists now. Glama, Cloudflare’s AI MCP marketplace, and the official MCP Registry (Anthropic, with the Linux Foundation behind it) are the three serious contenders. The wildcard is security: independent reviews in early 2026 found that roughly two-thirds of the most popular MCP servers had at least one significant security finding. Prompt-injection surfaces, over-broad credentials, untrusted code paths. The marketplace that solves discovery and signs and audits the servers it lists eats the others. My read is the official registry wins by default, because curation plus security audit is a regulatory-grade problem the smaller marketplaces aren’t structured to solve. Could be wrong. Watch this one.

Does MCP eat A2A and ACP, or do they coexist? MCP is the dominant agent-to-tool protocol. Google’s A2A (agent-to-agent) and the Linux Foundation’s ACP (agent communication protocol) are aimed at the agent-to-agent layer that MCP doesn’t directly address. A June 2026 MCP spec change adds agent-handoff primitives, which could collapse the distinction. Or could entrench it. Pick the protocol bet you can swap out of cheapest if this consolidates against you.

Neither question changes whether you should be shipping MCP today. Both questions matter to where you place your second-order bets. Build for the swap. Same playbook as Part 1.

Where this leaves us

The agentic business software trend now forming summarizes into three lines — corresponding to the three articles in this series:

The model will be rented. You pick a portfolio, route between them, expect to swap them out every few months.

The runtime will be commoditized. You pick one of the production runtimes, ship capabilities into it, do not sell an agent.

The content will be yours. Skills written by domain experts. RAG over your proprietary corpus. MCP servers your customers’ agents will call. Plus recipes shipped to those agents so they render the presentation layer in the customer’s own style.

Granted this isn’t a mature trend, but most of it is closer than it looks. The teams building toward all three are getting ahead of a market in which, over the next twelve to eighteen months, agents will do more and more of the consuming of business and information software, and humans will sit on top as the oversight surface.

That is the shift this series has been mapping.

Thanks for reading.