Apps Become Verbs: The Agent App Store Moment Arrives

The week software turned into verbs

In the first week of October 2025, a series of announcements crystallized a shift that has been building for years. Traditional software thinks in pages, menus, and installs. Agentic software thinks in intents, plans, and proofs. The center of gravity is moving from where apps sit on a home screen to what capabilities can be called in sequence to deliver a result.

One update in particular signaled how far this has come. Google introduced a dedicated Computer Use model that allows agents to operate familiar graphical interfaces with clicks and keystrokes under tight controls. The goal is simple. If a system does not yet have a clean interface to call, agents can still execute tasks in a way that is auditable and reproducible. Read more in the official Gemini 2.5 Computer Use model explainer.

At the same time, the leading chat platforms are formalizing how third parties build chat-native capabilities and how those capabilities are discovered. The result is a new distribution surface. Instead of chasing installs, vendors compete to be selected by an intent broker at the exact moment a plan runs.

What changed, exactly

Three converging moves define the inflection point and explain why software is starting to feel like verbs.

Agent builders moved from bespoke scripts to production toolkits. These toolkits package planning, tool use, error recovery, and evaluation so teams can build agents that act across long horizons, not just draft content.
Chat-native apps entered the mainstream. Running inside the chat surface, they expose capabilities through structured contracts and share a directory where search and curation help match intent to the right tool.
Computer use expanded agent reach. By allowing controlled interaction with standard interfaces, platforms raise the ceiling on what agents can accomplish today while vendors complete cleaner interfaces over time.

Seen together, these steps point to a common architecture. The chat surface becomes the operating system for intent. Apps become verbs that can be invoked in sequence. And the platform mediates which verbs are fast, safe, and reliable for a given request.

From icons to intent brokers

For more than a decade we learned to navigate by icons. Gmail for mail. Uber for rides. Excel for spreadsheets. In the agent era, the primary unit is not an icon. It is an intent: plan my offsite, close my books, draft a policy, generate a forecast, prepare a school lunch plan for two kids with nut allergies.

An intent broker sits between the user and the world of software. It interprets the request, selects a set of verbs, arranges them into a plan, executes step by step, and returns a result with evidence. That broker might be a consumer chat assistant, an enterprise gateway, or a private orchestrator that fronts both. What matters is what it optimizes for: success rate, cost, time to completion, and compliance with policy.

This logic is explored in our own thinking on the constitution of agentic AI, where permissions and policy need to be explicit elements of planning rather than afterthoughts.

Verbs, not pages

Designers once laid out screens, menus, and modal flows. In a verb economy, the job shifts to defining capabilities with crisp contracts. A verb has four parts:

Natural language description. It should map clearly to a user goal. Example: reconcile bank transactions in QuickBooks for the last seven days.
Input and output schema. Inputs might include account identifiers and date ranges. Outputs should include a structured receipt that proves what happened, with timestamps and affected records.
Capability boundary. Each verb should request only the permissions it needs and state limits. Example: read-only access to statements and the ability to mark transactions as reviewed. No vendor edits.
Cost and reliability profile. The platform needs to know expected latency, failure modes, and per-call pricing so it can plan, monitor, and budget as a plan runs.

When teams design with verbs, the interface becomes a thin, adaptive layer. The user asks. The broker proposes a plan. The plan references a chain of verbs, each with guardrails, costs, and receipts. The output is a result plus a trail of evidence the user and auditor can understand.

Distribution flips at run time

This is where power moves. Traditional app stores mediated discovery at install time, took a transaction cut, and enforced content rules. Intent brokers mediate selection at run time, decide which verbs are eligible for a given plan, and gather telemetry about outcomes.

Discovery shifts from browsing categories to matching capability profiles to user intents. A vendor wins not by buying placements in a store, but by proving its verb solves a task faster, cheaper, and more reliably for the relevant segment.
Ranking becomes contextual and dynamic. A scheduling verb that succeeds 99.9 percent of the time for mid-market teams with distributed time zones will be preferred for that cohort and bypassed for edge cases where it struggles.
Platform leverage increases because the broker sees outcomes across vendors. It can improve planners, deepen guardrails, and raise certification thresholds based on real execution data.

If you are a software vendor, your distribution strategy must adapt. Negotiate to be a default verb for specific intents. Publish your evidence. Price to win in mixed plans where your capability is one step among several.

Monetization moves to pay per capability

The subscription boom rewarded retention and feature breadth. In a verb economy, value concentrates in the moment of help. When a plan uses four verbs from different vendors to complete a task, few users will tolerate four subscriptions. Pay per capability aligns incentives for all sides.

Vendors can meter invocations at the verb level. A procurement check might cost a fraction of a dollar, while placing an order has a higher fee tied to risk and reconciliation.
Platforms can clear payments inside the chat surface. Users authorize a capped spend for a plan at the start and reconcile at the end with itemized receipts.
Enterprises can bundle across verbs. A company might prepay for unlimited calls to internal compliance verbs while buying a pool for travel booking and reimbursements.

Expect pricing to converge on a small set of clear units tied to time and risk. For a deeper view of how time affects cost and value in planning, see our analysis of the pricing frontier for thinking time.

New proofs for a verb economy

Trust needs evidence. Three kinds of proof will decide which verbs the broker chooses.

Execution receipts. Every verb should emit a signed receipt summarizing what it did, when, on whose behalf, and with what result. For data reads, include a digest of sources and a hash of returned documents. For writes, include changed record identifiers and a reversible patch. Receipts should be compact, verifiable by the broker, and shareable with the user.
Reversible permissions. Users should be able to grant a capability once for this plan only, or for a time window, or for a number of invocations, then revoke it without hunting across settings. Tokens should be scoped to verbs, not monolithic apps. The broker should surface a clear map of what is still authorized.
Evaluation as ranking signal. Static leaderboards will follow real end-to-end evaluations. Platforms will run standard suites and publish scores such as success under ambiguity, recovery after tool error, time to completion, and cost per outcome. Vendors will tune designs to climb these charts, and the best will share public evals to build trust.

These ideas connect to our work on the causality ledger for receipts, which argues that post-incident evidence must teach systems why a result happened, not just that it happened.

Computer use raises the ceiling and the stakes

The Computer Use model that Google released makes a practical trade. Many business critical applications still lack clean programmatic interfaces. By teaching agents to manipulate the screen under strict controls, platforms expand reach into back offices and legacy tools without waiting for every vendor to ship new interfaces.

More capability brings more responsibility. A computer use step needs stronger proofs.

Preview before action. The agent should present a proposed click path and a summary of intended changes before it acts. After completion, it should attach a before and after snapshot with redacted sensitive data.
Narrow permission windows. Approving a click sequence for one invoice should not implicitly approve similar sequences for all vendors. The broker should bind permission to the specific plan, scope, and time.
Built-in recovery. If a layout changes mid flow or a latency spike causes a timeout, the agent should stop, explain, and request permission to adapt. Silent retries should be capped with clear budget limits.

These expectations will harden into platform rules. Vendors that implement them first will become the default for sensitive verbs such as finance, healthcare intake, and human resources onboarding.

The coming battles: trust layers and ranking signals

If intent is the new front door, trust is the new key. Expect rapid investment across three layers.

Platform trust layer. Providers will invest in policy engines that check plans before they run, during execution, and after completion. They will enforce budget limits, require receipts, and block unsafe combinations of verbs. Over time, they will expose trust configuration to enterprise administrators.
Vendor trust layer. Software companies will ship capability manifests that declare inputs, outputs, side effects, and proofs. They will publish evaluation results and sign receipts with customer scoped keys. Some will build internal brokers so employees can compose verbs inside the firewall and route through a public broker only when needed.
Auditor trust layer. Third parties will certify high stakes verbs. Think auditors that re-run vendor verbs on known datasets or sandboxed accounts and publish reproducible results. For regulated workflows, this will become a procurement requirement.

Ranking signals will evolve accordingly. Early planners will prioritize success rate, cost, and latency. Soon they will add context-aware metrics such as reliability by industry, sensitivity of data touched, and user satisfaction signals like plan acceptance and refund rates.

What builders should do now

Move from pages to verbs. Treat each core feature as a capability with a clear contract, price, and proof. Here is a focused checklist.

Name your verbs. Write short, clear intent statements. Example: generate a quarterly pipeline forecast from Salesforce data, filter by region, and export to Google Sheets.
Define inputs and outputs. Use a strict schema. Include a receipt object with a summary, timestamps, source identifiers, and reversal steps when possible.
Scope permissions tightly. Ask for the minimum you need. Prefer plan-scoped or time-bound tokens. Support one-click revocation and explain the blast radius of each permission.
Price per capability. Publish a table of per-call costs and free tiers. Offer a cap per plan to avoid runaway spend. Offer credits for retries when failures are on your side.
Instrument evaluations. Ship a small public evaluation suite that the platform can run. Include success under ambiguity, recovery after tool errors, and time to completion. If you operate in a regulated domain, add compliance checks.
Prepare for computer use. If your app lacks clean interfaces, stabilize layouts, add accessible labels, and publish a sandbox mode so agents can practice safely. If you do expose interfaces, document them with capability manifests and examples.
Emit receipts everywhere. For reads, include source hashes and row counts. For writes, include record identifiers and reversible patches. Store receipts so users can review and share them. Make them machine readable so planners can learn.
Design a trust view. Give users and administrators a single pane that lists active permissions, recent plans that touched your verbs, and any anomalies. Offer a red button that revokes everything from your side in a single click.
Work your distribution. Negotiate with platforms to become a default for specific intents. Publish performance data. Seek featured placement for the subset of tasks where you are best in class rather than chasing generic categories.

Sector playbooks

Commerce. Convert catalog, availability, pricing, checkout, and returns into verbs. Support instant, capped authorization inside plans. Provide receipts that summarize item, price, tax, shipping, and a reversible order token.
Finance. Focus on provable correctness. Every reconciliation, accrual, or transfer verb should emit a hash chain of steps. Offer a safe mode that runs end to end with simulated writes before any real funds move.
Human resources. Make permissions narrow and time bound. Hiring and onboarding verbs should expose what personal data will be touched and for how long. Provide receipts that an employee can export during offboarding.
Support and operations. Design verbs that can be composed. A triage verb that classifies tickets by intent, a reply verb that drafts a resolution, a follow-up verb that schedules a check-in. Each verb small, measurable, and priced.

A near-term forecast

Over the next quarter, expect chat directories to expand and enterprise catalogs to follow. Early revenue experiments will pay vendors per capability call. Planners will incorporate evaluation results directly into ranking. Vendors will add receipt schemas to their roadmaps. Computer use flows will gather momentum, first in back-office tasks where interfaces are stable and then in front-office apps as proofs improve.

Two tensions will surface. The first is control. Enterprises will want to pin specific verbs as defaults and to freeze planner versions for compliance. The second is visibility. Users will demand a clear explanation of what happened when a plan goes wrong, along with a fast path to revoke permissions and roll back effects.

Conclusion: design for verbs, receipts, and reversibility

The platform race is underway. The most important change is not a new icon grid. It is a broker that hears what you want, chooses the best verbs, proves what happened, and lets you take permissions back as easily as you gave them.

If you are building today, act on three principles. Design for verbs with crisp contracts instead of pages with nested menus. Ship receipts that prove work, not just notifications that claim success. Make every permission reversible by default. Do this well and your capability will be the one a planner calls first when a user simply asks to get it done.