Applications as capabilities
A person receives an invitation to a conference in New York and decides to attend.
The decision reaches across several applications. A calendar holds the conference dates. An airline sells the flight. A hotel provides accommodation. A bank supplies funds and foreign-exchange information. An employer defines travel policy and reimbursement rules. A mapping service estimates travel time. A weather service informs what to pack.
Today, the person commonly visits each product in turn. They translate one goal into a sequence of application-specific tasks: check the calendar, search for flights, compare hotels, read the travel policy, inspect the account balance, and create an expense request. Each application provides a complete interface organized around its own objects and commercial boundaries.
An intent-driven assistant can begin from the whole goal:
Arrange my trip to the New York conference.
Keep the total within company policy and avoid overnight flights.
The resulting interaction may contain a calendar conflict, flight and hotel options, a policy explanation, a budget, and an approval action in one workspace. Each piece comes from a different service. The assistant supplies the task model that connects them.
Runtime composition therefore reaches beyond the shape of a screen. It can change the boundary within which a screen is formed.
application era: one product assembles its capabilities into its interface
intent era: one interface assembles capabilities from several products around a goal
The application remains useful as a product, a trusted destination, and an operational boundary. At the same time, parts of it become available as capabilities inside interactions authored elsewhere.
The application as a container #
An application usually combines several layers:
domain data
business rules
authorized actions
navigation and workflows
visual identity
customer relationship
These layers arrive as one product experience. A banking application stores financial records, enforces permissions, prepares payments, explains transactions, and presents each function through the bank's navigation and screens. The interface gives the capabilities a coherent home.
The container also defines the user's route into the service. To use a bank capability, the person opens the banking application. To change a meeting, they open the calendar. To buy a flight, they visit an airline or travel marketplace. Deep links, widgets, browser extensions, and embedded checkout shorten those routes while preserving the application as the main unit of experience.
This arrangement aligns the interaction boundary with the product boundary:
organization → application → interface → user
The organization decides which capabilities sit together, how they are named, which deserve prominence, and which sequence the user follows. Its application becomes both the place where work happens and the catalogue of what the organization can provide.
Intent-first interaction introduces a second route. The user can begin with a goal that crosses products, and a composition layer can locate the relevant capabilities. The interface boundary then follows the task.
The capability beneath the screen #
Every application already contains capabilities beneath its interface. A calendar can find available times, create an event, invite attendees, and move a meeting. A bank can retrieve balances, explain fees, prepare transfers, and dispute transactions. An airline can search schedules, price an itinerary, reserve a seat, and issue a ticket.
APIs expose some of these operations to other software. Their contracts commonly describe technical resources and commands:
GET /accounts
GET /flights?origin=SYD&destination=NYC
POST /calendar/events
POST /expense-claims
A runtime composer needs richer knowledge. It must understand the purpose of an operation, the evidence it requires, the commitments it creates, the permissions it depends on, and the interaction required around it.
The capability therefore includes more than an endpoint:
| Capability property | Example |
|---|---|
| Purpose | Reserve a particular flight at a quoted price |
| Required inputs | Passenger, itinerary, fare, payment method |
| Produced result | Confirmed booking and ticket reference |
| Preconditions | Valid quote, available seat, authenticated traveller |
| Consequences | Charge, cancellation conditions, loyalty effects |
| Interaction needs | Fare comparison, traveller review, explicit purchase confirmation |
| Evidence | Airline quote, policy version, booking record |
| Lifetime | Quote expires at a stated time |
This description makes the capability usable inside a generated interaction. The assistant can present the right information, collect missing inputs, respect the validity period, and connect the result to the larger travel task.
The product team remains responsible for the capability's truth and behavior. The composition layer determines where the capability belongs in the current situation.
The assistant as the composition layer #
A personal assistant occupies a different position from an application. It can maintain context across goals, products, and time. It may know that the conference is related to a project, that the traveller prefers an aisle seat, that the employer requires approval above a threshold, and that a family commitment makes one return flight unsuitable.
That context lets the assistant organize capabilities around the user's situation:
goal and preferences
+
calendar and commitments
+
available service capabilities
+
permissions, policies, and budget
↓
travel workspace
The workspace can evolve as the task develops. Early on, it may compare dates and approximate costs. After approval, it may present live flight and hotel options. At purchase, it may assemble reviewed booking controls from the providers. During the trip, the same artifact may become an itinerary with disruption alerts, maps, and expense capture.
The organizing object is the trip. Each application contributes part of its capability set to that object.
This structure gives the assistant a role similar to an operating environment for services. Applications once gathered functions behind icons and windows. An assistant can gather remote capabilities behind an active task. Its interface becomes the place where services meet each other and where their combined consequences become visible to the user.
Contracts for composition #
Technical interoperability gives a composer access to an operation. Interaction interoperability makes that operation understandable and safe inside a shared surface.
A useful capability contract may need to express several kinds of information:
- semantic identity: what the capability does in domain terms;
- authority: which service owns the data, calculation, or action;
- input and output schemas: the values the capability consumes and produces;
- policy: eligibility, permissions, geographic limits, and required disclosures;
- interaction requirements: review fields, confirmations, warnings, and recovery paths;
- temporal behavior: expiry, delay, pending states, and cancellation windows;
- provenance: the records and versions supporting the result;
- presentation resources: approved terminology, brand identity, and provider-specific controls.
These contracts allow several providers to participate in one interface while retaining clear responsibility. A hotel can define the cancellation terms that accompany its room. An employer can define the policy rule and approval step. A bank can define the authentication required for payment. The assistant can arrange them into a coherent decision.
provider defines the capability and its obligations
composer places it within the task
renderer preserves its interaction requirements
user reviews the combined outcome
Standards can help services describe common concepts such as money, identity, time, location, consent, and authorization. Domain-specific agreements will still carry much of the meaning. A medical referral, a securities trade, and a restaurant booking each create different commitments, even when their technical invocation looks similar.
The richer contract turns an API operation into a participant in an interface.
Identity travels through the task #
Cross-application composition brings several identities into one interaction. The assistant acts for a person. The person may also act as an employee, account holder, patient, parent, administrator, or purchasing delegate. Each provider recognizes a particular identity and grants it a particular scope of action.
The composition layer must carry that authority precisely. A travel assistant may read a work calendar, view a company policy, search public flights, access a loyalty account, and prepare a card payment. Each capability receives the identity and permission appropriate to its role in the task.
user goal
↓
delegated authority for this task
↓
provider-specific permission and policy checks
↓
prepared actions
↓
user or organizational approval
Delegation becomes a visible part of the interface. The user should see which service will receive information, which account will fund a purchase, whose policy applies, and which actions the assistant is authorized to prepare or complete. Permission can be narrow in capability, data, duration, and amount.
A request such as “handle my travel” contains many possible grants of authority. One person may allow the assistant to search and compare. Another may allow it to reserve refundable options. A company may allow bookings inside policy and route exceptions to a manager. The interface translates broad intent into explicit operational boundaries.
This precision protects both the user and the providers. It also lets the assistant make useful progress before reaching an approval boundary.
Several interests share one surface #
An application can arrange its interface around a mixture of user goals and product goals. An airline may promote a higher fare, a hotel may prefer a prepaid rate, a bank may highlight its own travel card, and an employer may favor contracted suppliers. When one assistant composes all of them, those interests meet inside the same workspace.
The composer therefore performs more than layout. It arbitrates attention.
Which flight appears first? Which providers enter the comparison? How are sponsored results identified? Does the workspace optimize price, convenience, flexibility, loyalty rewards, employer policy, environmental impact, or the assistant provider's commercial relationships?
The answers shape the user's decision while appearing as a personalized response. A situational interface can feel uniquely helpful, which gives its selection and framing considerable influence.
Trust requires visible principles for that arbitration:
- the user's stated criteria guide ranking;
- commercial influence is identified at the point of recommendation;
- material alternatives remain available for comparison;
- provider claims retain their source and effective date;
- estimates remain distinguishable from guaranteed terms;
- the user can change the criteria and observe the result;
- consequential choices receive a review based on authoritative provider data.
The assistant's position resembles a marketplace, adviser, browser, and operating system at once. Governance for that position becomes part of interface design.
Who owns the experience #
When a capability appears inside another product's interface, authorship divides across several parties. The provider owns the underlying service and its commitments. The assistant owns the task-level composition. The renderer owns common interaction behavior. The user supplies the goal, preferences, corrections, and approvals.
Brand becomes functional in this arrangement. It tells the user which organization stands behind a value or action. A balance should remain identifiable as a bank's record. A fare should remain identifiable as an airline's offer. An approval should remain identifiable as an employer's decision. Visual identity, naming, signatures, and provenance help preserve those boundaries within a unified surface.
Support follows the same lines. A user needs a clear route for questions about the assistant's interpretation, a provider's data, a failed action, or a disputed outcome. The interface can carry responsibility metadata alongside each artifact:
composed by: personal assistant
flight offer from: airline
policy evaluated by: employer travel service
payment prepared by: bank
approval recorded by: expense platform
This trace turns a seamless experience into an accountable one. Seamlessness describes the user's continuity across services. Accountability preserves the seams that identify authority, obligation, and recourse.
Products in a capability market #
As assistants become important routes to software, product strategy changes. A service can compete through the quality of both its direct application and its exposed capabilities.
The direct application remains valuable for discovery, deep specialist work, relationship building, support, and stable workflows. Capabilities extend the service into goals that begin elsewhere. A calendar gains value when scheduling appears inside recruiting, travel, healthcare, and project work. A bank gains value when payments, identity, affordability, and transaction evidence can participate safely in broader tasks.
This creates a new product surface:
quality of direct experience
+
quality of capability contracts
+
reliability inside external compositions
+
trust carried across those compositions
Providers may design capabilities with the same care once reserved for screens. They will consider how an operation is discovered by assistants, how its value is explained, how it compares with alternatives, how consent is obtained, how errors recover, and how the provider remains recognizable.
Metrics also shift. Page visits and time inside an application capture only the direct channel. A capability may create value through successful outcomes inside another interface. The provider may care about selection, completion, correction, cancellation, dispute, and long-term trust across many composition environments.
The application becomes one expression of the product. Its capabilities become another.
A layered future #
Software is likely to support several forms at once:
| Form | Primary value |
|---|---|
| Stable application | Familiar navigation, deep workflows, direct provider relationship |
| Embedded capability | A focused action inside a partner's context |
| Assistant-composed workspace | Coordination around a goal that crosses services |
| Saved situational artifact | Continuity for a task that persists over time |
A payroll specialist may spend hours in a dedicated application. A manager may approve one payroll action inside a broader operational workspace. An employee may ask an assistant to explain a payment using capabilities from payroll, banking, and human resources. Each form serves a different relationship between expertise, frequency, and task scope.
The shift concerns the default unit of composition. Product teams have traditionally composed capabilities into applications. An intent-driven layer can compose applications' capabilities into situations.
capabilities → application → user chooses a path
capabilities from many providers → task model → situational interface
Applications continue to provide stable homes, trusted fallbacks, and complete expressions of a service. Their boundaries become permeable to authorized composition. A user can enter through the product or through the goal.
The interface follows the goal #
The web connected documents across organizational boundaries while leaving each document at its own address. APIs connected software systems while leaving each application in charge of its interface. Intent-driven composition can connect the interfaces themselves.
A trip, a home purchase, a medical recovery, a new employee's arrival, or a small business's month-end close each crosses many products. Today, the user carries context among them. They copy values, reconcile terminology, remember constraints, and assemble the final picture in their own mind.
A composition layer can carry that context through the task. Providers contribute authoritative data and actions. The runtime gives those capabilities a temporary shared structure. The user sees one working artifact organized around the outcome.
This changes the meaning of an application boundary. It becomes a boundary of authority, operation, and responsibility while the visible interaction can span several such boundaries.
Once interfaces form across providers, personalization also gains a wider reach. Two people can pursue the same goal through different services, permissions, policies, representations, and recommendations. They may use the same underlying system while inhabiting substantially different versions of it.