AI Clients as First-Class Interfaces: A New Pattern for Software Access
Why browser manipulation should remain a compatibility fallback, and how software can expose governed capabilities and system-authored presentation directly to user-chosen AI clients.
Series: AI × Observability (7 articles)
- 2AI Clients as First-Class Interfaces: A New Pattern for Software Access This article
This article proposes a pattern in which user-chosen AI clients access governed system capabilities and system-authored presentation directly, while browser manipulation remains a compatibility fallback.
When an AI assistant needs to use software today, we often make it pretend to be a person. It opens a browser, waits for the interface to settle, searches for the right control, clicks it, and reconstructs system state from pixels or the DOM.
This is a remarkable compatibility technique — and a fragile primary contract between AI and software.
Browser agents will continue to improve, and browser manipulation will remain indispensable for legacy systems, third-party software, and anything we cannot change. But for software we can change, we should offer something more intentional.
When we cannot change the software, manipulate its interface. When we can change it, expose its capabilities directly.
This article proposes an emerging design pattern: make a user's preferred AI client—desktop application, terminal agent, IDE, or a supported mobile host— a first-class interface to software. The software exposes authorized domain capabilities and system-authored presentation. The enterprise governs inference. The AI client composes the systems, context, tools, and compute available to that user.
This is not simply “add MCP.” It is a different way to divide responsibility between systems, models, clients, and people.
The browser is a compatibility layer, not the primary AI contract
A browser interface is optimized for a person who can see layout, infer context, recover from small changes, and judge whether an action looks safe. An agent must reconstruct all of that through accessibility trees, DOM structure, screenshots, timing, and model inference.
That creates four recurring problems.
1. Authority is often too broad. A browser session can expose an agent to much of the user's active web authority. It is harder to grant the agent one narrow, auditable capability than it is to hand it the whole page and ask it to behave carefully.
2. The interaction is structurally unstable. A delayed component, an experiment, a responsive layout, a renamed label, or a modal can change the sequence. The business capability may be unchanged while the automation breaks.
3. The execution depends on browser state. Cookies, extensions, open tabs, local profiles, network routes, and device state become undeclared dependencies of the integration.
4. Meaning is lost and then reconstructed. The system may know that a value is a p99 latency measured over a particular window and scope. The agent sees a number at a position on a page and has to recover that meaning. This inversion adds latency and uncertainty without adding domain value when direct semantics are available.
None of these observations make browser automation useless. They explain why it should be a broad compatibility fallback, not the best contract a system intentionally offers to AI.
What is an AI-native interface?
If browser operation is the compatibility path, what should the intentional path look like?
An AI-native interface serves two consumers with different needs:
- The model needs bounded semantic evidence: the facts, relationships, provenance, uncertainty, and identifiers required to analyze a situation and decide what to do next.
- The person needs stable presentation: charts, tables, topology, forms, previews, and interaction patterns that are fast, predictable, accessible, and faithful to the system's domain.
Those consumers are related, but their responsibilities should remain distinct—even when both consume the same bounded result.
AI-native does not mean model-mediated at every step.
A model may choose a capability, interpret its evidence, correlate it with other sources, and explain a finding. That does not mean every row, time-series point, image, or rendering instruction must enter the model's context. A good AI-native interface deliberately decides what the model should see, what the human should see, and how follow-up interactions obtain fresh data under explicit authorization.
From the user's perspective, the change is simple but important. Instead of opening each product and then finding its embedded assistant, the user can begin in the AI environment where the work is already happening. The system appears there as an intentional, authorized capability—not as a web page waiting to be operated by a robot.
More than an API, and more than MCP
An API is necessary, but an ordinary endpoint is not automatically an AI-native interface. A useful capability contract needs to express more than request and response fields:
- what the capability means in the system's domain;
- who may invoke it and within what scope;
- whether it reads, proposes, or changes state;
- what evidence a model needs in order to reason correctly;
- what presentation a person needs to understand and interact with the result;
- what provenance, capture time, schema version, truncation, and degradation state accompany the result;
- and which follow-up interactions are safe and explicitly declared.
This is not merely wrapping every existing API in a tool. A raw API often exposes storage or transport shapes. A capability contract exposes an action meaningful to operators and the evidence required to use it responsibly.
Model Context Protocol is an important mechanism for implementing this pattern today. Its client-host-server architecture gives the host responsibility for model integration, context aggregation, consent, and isolated server connections, while servers provide focused, composable capabilities.
MCP Apps adds another essential primitive: a tool can point to a
ui:// resource that an enabled host renders as an interactive, sandboxed interface. This allows a system to bring its own domain presentation into the AI experience instead of asking every client—or every model—to invent one.But the design pattern is larger than MCP. It is about the product boundary: an AI client is a supported entrance; systems remain authorities for their capabilities; reasoning and presentation are separate projections; and enterprise policy governs which intelligence may process the evidence. If another protocol can preserve those properties, it can implement the same pattern.
Is this actually new?
Not every ingredient is new. Headless architecture separated channels from backends. MVC separated data, behavior, and presentation. APIs, plugin systems, server-driven UI, local execution, and enterprise gateways are all established ideas.
What is emerging is their synthesis around a user-chosen AI client: the client owns conversation and cross-system orchestration; independent systems expose and authorize what they know; the enterprise governs inference separately from system access; the managed endpoint contributes local context, tools, and compute; and systems ship domain presentation alongside model-facing evidence.
The official MCP Apps announcement formalizes an important part of this direction, but not the complete architecture proposed here, which is not yet a mature, universally named pattern.
So we are not claiming to have invented its primitives. We are proposing a concrete architectural formulation for putting them together: AI Clients as First-Class Interfaces.
The system-neutral architecture
Figure 1: Centralize inference governance, federate system capabilities, and compose work at the user edge. The snapshot path is a stability practice for dynamic results, not a requirement for inherently stable or immutable data.
The architecture has three clear responsibility boundaries.
Systems govern capabilities
Each system remains the source of truth for its own data and operations. It defines capability semantics and domain presentation, authenticates the user, evaluates current authorization, applies resource and tenant boundaries, and records an audit trail. The host governs how system-provided presentation executes. Access to System A must not silently grant access to System B, and an AI client's model subscription must never become a credential for either system.
This creates a federated capability plane rather than one central super-connector. A system can evolve its capability contract and presentation without surrendering its authority to the AI client or the model provider.
The enterprise AI gateway governs inference
Enterprise inference governance is required in this reference architecture. A network AI gateway is the enforcement point for off-device inference: it enforces approved inference endpoints, workload identity, routing and fallback, quotas, cost controls, and audit signals, and participates in broader residency and disclosure controls. For fully on-device inference, managed endpoint policy performs the equivalent governance role.
“Required” does not mean every organization must deploy a new standalone product. The role may be implemented by an existing AI platform, a managed control plane, or gateway infrastructure. Envoy AI Gateway is one open-source example of a control and data plane for AI traffic; it is an implementation option, not a dependency of this pattern.
Inference governance does not replace the authorization of each connected system. It answers a different question: which model or inference service may process this request, under what policy?
The managed AI client composes work at the user edge
The AI client is more than a chat window and more than a model selector. It is a user-scoped orchestration and execution runtime. Within enterprise policy, it combines independently authorized systems, selected local materials, user approvals, system-authored presentation, and endpoint tools.
That gives us a compact responsibility model:
Systems own capability semantics and authorization, and define domain presentation. The enterprise AI gateway governs off-device inference. The managed AI client composes context and executes user-specific work at the user edge.
The user chooses more than a model
“Bring your own model” is too narrow for this architecture.
Two people using the same AI model may have completely different working environments. One may be authorized to access source control, a deployment system, observability data, incident records, and a local architecture document. Another may see only a subset of those systems, but have different local notes, scripts, or datasets. Their clients have different capability graphs because their identities and permissions are different.
The meaningful choice is therefore not just which model produces the answer. It is the composition of:
- an enterprise-approved inference path selected within policy;
- the systems the user is individually authorized to access;
- personal or local materials the user chooses to contribute;
- tools available on the managed endpoint;
- and the compute, memory, and storage available for temporary work.
The enterprise still defines the outer boundary. “User-chosen” does not mean arbitrary models, unmanaged connectors, or invisible data movement. It means that within policy, the user composes an authorized working environment instead of waiting for every product team to centrally build the exact integration and workflow they need.
Why centralized assistants reach practical limits
An embedded assistant remains valuable. It can provide a carefully guided experience, use a public or private model, and integrate deeply with one product. For common workflows, centralization can be exactly the right choice.
The limit appears when we ask it to become a general-purpose working environment for every user.
Every new connector becomes a platform responsibility for credentials, network reachability, authorization, lifecycle, audit, and data handling. Every request for on-demand code or a new library becomes a multi-tenant sandbox commitment. Every long-running analysis becomes a capacity and cost decision. Every cross-system workflow creates another place where data from separate authorities may be combined.
These legitimate security and operational concerns naturally push a centralized assistant toward predefined workflows and approved integrations. A valuable one-off analysis may be rejected—not because the idea is bad, but because offering it safely to every tenant from a shared backend is a much larger commitment.
A client-first architecture changes the scope of the question:
Instead of “Can the platform safely offer this on-demand workflow to everyone?”, ask “What can this authorized user safely perform on this managed endpoint?”
The result is not unlimited freedom. It is an identity-scoped and endpoint-governed execution boundary that can support temporary parsing, correlation, scripting, and cross-checking without turning every product backend into a general-purpose agent platform.
The endpoint is an execution node, not merely a screen
Modern laptops and workstations already provide CPU, memory, storage, local files, development tools, and user-scoped access to work systems. A managed AI client can use those resources for ephemeral, user-specific work: parsing a large result, correlating timestamps, running a temporary script, comparing captured results, searching local documentation, or rendering a domain view.
This does not make a laptop inherently secure. The useful observation is that an enterprise-managed endpoint already has controls that contribute to this execution boundary: device identity, disk encryption, endpoint protection, OS permissions, network and data-loss policy, software provenance, and direct user confirmation.
Moving work to the user edge can reduce the concentration of credentials and general-purpose execution in one multi-tenant assistant. It also creates endpoint obligations: sandboxing, resource limits, approval policy, auditable execution, and clear data-flow controls remain necessary.
There is also a subtle governance issue. Permission to read two systems does not automatically mean their data may be freely combined and sent to any model. Cross-source composition can create new sensitivity. A responsible client preserves provenance and applies disclosure policy, redaction, user confirmation, and gateway controls to the combined evidence.
A stability practice: one operation, one snapshot, two projections
Once the AI client becomes a first-class interface, many capability results must serve two destinations: model reasoning and human presentation. Treating their requirements as identical can either starve the model of semantics or burden its context with presentation detail. The contract therefore benefits from a logical split, even when both consumers share one bounded result.
Not every capability needs a snapshot. Static configuration, versioned artifacts, and immutable records may already provide a stable identity. But when data is dynamic, time-bound, expensive to reproduce, or likely to change between analysis and display, capturing the result is the safer practice.
Consider a capability that queries a dynamic system over a time window. One execution can produce a capability snapshot with an identity, capture time, source, scope, input parameters, schema version, and indicators of partial or truncated results. From that observation, the system derives two logical projections.
The reasoning projection contains bounded, model-visible evidence: baselines, extremes, anomalies, important relationships, representative records, and explicit uncertainty. It lets the model analyze, summarize, find patterns, propose a root cause, and decide which capability to call next.
The presentation projection contains the data and metadata needed by a trusted renderer: captured chart buckets, table rows, topology edges, labels, interaction identifiers, and presentation type. It lets a person inspect the evidence directly.
The projections describe the same observation, but they do not need to contain the same bytes.
┌─ reasoning projection ──> model contextcapability execution ─── snapshot └─ presentation projection -> trusted rendererThis avoids two common failures. First, when the host preserves a distinct presentation channel, the visualization payload need not enter model context merely to reach the renderer. Second, the renderer does not issue a second live query and accidentally display data that has changed since the model formed its conclusion.
The distinction is logical before it is physical. When the host preserves a distinct presentation channel, it can keep detailed visualization data out of model context. When it cannot, one bounded structured capture may serve both the model and a trusted renderer. In either form, both consumers work from the same observation, the renderer remains system-authored rather than model-generated, and the implementation must not silently widen model context with an unbounded presentation payload.
For a captured result, rendering should not issue a second semantic query merely to reconstruct the view. A deliberate refresh or drill-down is a new capability execution, with a new capture time and provenance.
Rendering should not pass through the model
Model-generated UI is compelling, especially when a person asks for an ad hoc visualization that the system could not anticipate.
But it is a poor default for stable product presentation.
If the model must receive detailed data and generate rendering code every time, presentation becomes slower and more expensive. Quality may depend on a higher-tier model. Layout and interaction can vary between runs. A plausible but incorrect substitute may appear when the intended renderer fails. Users can be surprised by a view whose semantics, accessibility, scale, or aggregation rules differ from the product they trust.
For repeatable system views, the system should publish versioned presentation resources and renderers that encode its domain knowledge. The model decides what capability to use and explains what the evidence means. The system-authored renderer decides how that evidence is shown.
The system does not need to publish one universal renderer. It can provide multiple presentation adapters against one versioned, semantically consistent result contract. A GUI-capable host might mount an interactive chart or topology; a terminal client might run a deterministic text renderer. Their form and interaction can differ, while their labels, values, scope, and provenance remain consistent because every adapter consumes the same capability result.
A client chooses the adapter it can safely support; the model does not improvise the presentation. A client without a compatible renderer still receives the reasoning evidence and a plain explanation. Presentation becomes progressive enhancement rather than a condition for correct analysis.
The principle is broader and simpler:
AI-native does not mean token-native. Rendering code should not pass through the model, and presentation-only data should bypass model context when the host allows.
The client must be a trusted harness
System-provided presentation code creates a real trust boundary. Executing code received from a configured system is privileged; trusting its source does not by itself make the code safe.
The AI client therefore needs to act as a trusted harness, not a passive script runner. Depending on the environment, that harness should:
- authenticate the source and verify signatures or trusted provenance;
- pin, review, and audit renderer versions, with static scanning as defense in depth;
- execute UI in a restricted sandbox with a deny-by-default content policy;
- isolate system credentials and mediate interaction through declared capabilities;
- require confirmation for sensitive or mutating operations;
- record the capability, result or snapshot identity, renderer version, user decision, and resulting action;
- and provide an administrative off switch.
Scanning is useful, especially because renderers should be mostly static and auditable. It is not the sandbox. Trust comes from layers: authenticated delivery, provenance, policy, isolation, capability mediation, and audit.
Failure behavior matters too. A renderer failure does not invalidate the captured evidence. The client should report that presentation is unavailable and continue with the evidence, rather than ask the model to invent a substitute that may look authoritative but behave differently.
Client access is not public-model disclosure
Exposing a capability to an authorized AI client does not by itself make the system endpoint public. Whether model-visible evidence reaches an external provider depends on the client's configured inference path, synchronization and telemetry behavior, and enterprise policy.
There are two distinct credential and authorization planes. The client uses an inference credential or session appropriate to its configured path—for example, a subscription sign-in, enterprise-gateway credential, provider key, or local-provider configuration. It separately presents a system-scoped credential when invoking protected capabilities. Those credentials must have distinct audiences and must not be forwarded across planes.
Approved off-device inference can reach public providers, private-cloud deployments, or self-hosted models under gateway policy; fully on-device inference remains governed by endpoint policy. In a host with a separate presentation channel, detailed presentation data can remain outside model context entirely.
An embedded assistant can also use a private or self-hosted model. Privacy is not exclusive to the client-first pattern. The architectural difference is platform-selected integration versus a user-composed working environment within enterprise policy.
Two distinctions are easy to miss:
- An authorized local AI client does not necessarily use a local model.
- A remote or subscription AI client does not necessarily require every connected system to be publicly exposed.
The actual network path depends on the host. A desktop or terminal client may connect directly to an internal system over local networking or VPN. A vendor-cloud connector may require a publicly reachable endpoint, an allowlisted ingress, or a tunnel.
One capability contract, multiple client experiences
This pattern lets software meet users in desktop, terminal, IDE, and supported mobile AI experiences without rebuilding an assistant inside every product. The stable contract is the capability result, not one universal renderer: each host selects a compatible presentation adapter while preserving the same values, scope, identifiers, and provenance.
MCP provides a common capability connection, but hosts still differ in connectivity, authentication, local execution, and UI support. Desktop and terminal clients with local connectivity are the first proving ground; mobile becomes a first-class entrance only where the host provides the required connectivity, authorization, and presentation support. Structured fallback and a tested compatibility matrix therefore remain essential because these paths must be evaluated separately for each host.
Putting the Pattern to Work: Horizon
These ideas become clearer in a system with dynamic, high-volume, domain-specific data. Apache SkyWalking Horizon UI is where we first put this pattern to work. Its MCP implementation brings system capabilities and domain presentation into an external AI client.
Horizon already understands observability evidence—from metrics and topology to traces, logs, profiling, and root-cause investigation—and renders it as domain components rather than generic JSON.
Our first step was to make those investigation capabilities reusable. The same registry now serves Horizon's embedded assistant and an authenticated MCP endpoint. A connected AI client invokes read-oriented tools under the operator's permissions. Horizon retains authority for observability semantics, data access, and permission enforcement; the client owns the conversation and cross-system orchestration. In this path, Horizon makes no LLM request and holds no model credential.
The following short desktop tour shows the pattern in operation. Codex discovers services, requests a live service topology, and opens Horizon's domain-specific BanyanDB deployment presentation. AI working periods are accelerated 12×.
{{< youtube rY0vDyAAnWM >}}
Video 1: Codex accesses governed Horizon capabilities directly. The AI client owns the conversation; Horizon supplies the observability semantics, data, and interactive presentation.
Horizon implements one logical result contract with two system-authored presentation adapters. Every capability with a visual presentation returns one bounded capture that the model can analyze and the client can present through either:
- a GUI renderer that reuses Horizon's visual components; or
- a terminal renderer for text-based environments.
We verified this implementation with Codex on desktop and Codex CLI , both connected to the same authenticated Horizon MCP endpoint. On desktop, Horizon presents service traffic as a line chart and one-hop dependencies as its domain topology. In the CLI, it presents the same time series as a terminal-native chart and the topology's nodes, relations, and metrics as compact tables. Both invoke the same Horizon capabilities and preserve the same observability semantics through one result contract. Codex is the host used for this demonstration, not a dependency of the pattern.
The client chooses the presentation adapter that fits its environment and applies it to the same result. Horizon does not need separate GUI and terminal versions of the underlying capability. The presentations can differ while their data and meaning remain consistent. Neither renderer needs to query the system again merely to reconstruct the initial view; an intentional refresh or drill-down is a new capability execution.
This implementation illustrates an important distinction: rendering responsibilities can be separate even when transport channels are shared. The bounded capture is available to both analysis and presentation, while the rendering code neither passes through nor is generated by the model.
For the demonstration, we run the same investigation in Codex on desktop and in Codex CLI, using the same closed time window:
Investigate the service<service-name>in theGENERALlayer from<start-time>to<end-time>. Show its Traffic metric and one-hop service topology. Identify the busiest incoming or outgoing dependency by RPM, and explain whether the traffic trend together with edge latency and SLA supports an overload hypothesis. Use Horizon's system-authored presentation for every result. This is a read-only investigation; do not make changes.
This request deliberately combines temporal evidence—the traffic trend—with structural evidence from the dependency graph. It asks the model to assess a bounded hypothesis rather than manufacture a root cause from insufficient data. The desktop and terminal presentations differ, but the capability semantics, identifiers, scope, and evidence remain consistent.
The user's AI client may also have separately authorized access to source control and CI, an incident system, and local runbooks. It can correlate Horizon's bounded results with deployment events and incident history, search local knowledge, or run a temporary analysis script on the managed endpoint. Any additional drill-down remains an explicit capability execution with its own tool identity and timestamp.
No single product team had to build that entire cross-system workflow. No model had to rediscover Horizon by clicking through its pages. No generic client had to understand how an observability topology should be drawn.
Horizon provides the observability capability and presentation it understands best. The user's AI client combines them with the rest of the user's authorized world.
Principles and practices for AI-native software access
The pattern and its recommended practices can be summarized in eight points.
- Capabilities over pixels. Use browser manipulation as the compatibility path; expose direct capabilities where the software can be changed.
- The contract is more than an API. Include semantics, authorization, evidence, presentation, provenance, and declared interactions.
- Federate system authority. Every system remains responsible for its data, operations, scope enforcement, and auditing.
- Govern inference centrally. For enterprise use, route off-device model access through an approved AI gateway or equivalent inference control plane; govern fully on-device inference through managed endpoint policy.
- Compose at the user edge. Let the managed AI client combine the user's authorized systems, local context, tools, and compute.
- Prefer a stable shared observation. For dynamic, time-bound, or expensive results, capture once and derive reasoning and presentation from that observation. Immutable data can keep its existing identity.
- Keep rendering system-authored by default. Publish client-appropriate renderers against a consistent result contract, and keep presentation-only detail outside model context where the host supports it.
- Treat the client as a trusted harness. Verify provenance, sandbox renderers, isolate credentials, mediate capabilities, request approval, and audit execution.
From software that tolerates AI to software designed for it
The goal is not to eliminate browsers, native applications, embedded assistants, or browser automation. It is to stop treating a human-facing page as the only contract software can offer an AI.
AI-native software can expose governed capabilities, bounded evidence, system-authored presentation, and safe interactions directly to an AI client. Each system retains authority over its data, permissions, and domain semantics. The enterprise governs inference. The managed AI client composes the user's authorized systems, local context, tools, and compute.
This makes software available through more user-chosen interfaces without binding it to a single model or assistant. System providers continue to own the domain semantics and presentation they understand best, without having to own every model, assistant, or cross-system workflow.
The next generation of software access will not be defined only by agents that click pages more reliably. It will be defined by systems designed to meet users through the AI clients they have already chosen.
Expose governed capabilities, not pixels. Let systems own semantics, authorization, and presentation; let enterprises govern inference; and let users compose work through the AI clients they choose.
Series: AI × Observability (7 articles)
- 2AI Clients as First-Class Interfaces: A New Pattern for Software Access This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article