# Tools, browsers and service access in the agentic economy

The APIs, protocols, browsers and computer-use systems through which agents reach software, data and external capabilities.

Source: https://aecon.ai/guides/tools-browsers-and-service-access
Author: Agentic Economy
Published: 2026-09-13
Updated: 2026-09-14

<!-- PUBLICATION CONTRACT: Render BlogPosting JSON-LD with an Organization publisher and BreadcrumbList. Emit og:title and og:image, then verify the rendered page during website review. -->

**Chapter 7 of The Hitchhiker's Guide to the Agentic Economy**

[Report hub](/guides/hitchhikers-guide-agentic-economy-2026) · Previous: [runtimes, orchestration and harnesses](/guides/ai-agent-runtimes-orchestration-harnesses) · In this chapter: [the route ladder](#section-the-access-route-ladder) · [market map](#section-who-supplies-access) · [failure states](#section-operating-flow-and-failure-states) · [service access contract](#section-the-service-access-contract) · Next: [agent-to-agent coordination](/guides/ai-agent-to-agent-coordination)

## Our view

Five access markets now coexist. Purpose-built APIs expose explicit schemas, effects and resource receipts. MCP standardises how compatible tools are discovered and invoked, but does not establish trust or authority. Connectors centralise authentication and routing across many services, moving part of the control plane into the connector platform. Browser and computer use reach the long tail of software without a suitable API, while inheriting interface, session and adversarial-content risk. Skills package instructions and supporting files; they neither grant authority nor create access that the runtime does not already possess.

This chapter uses **service access** for the boundary between an agent and an external capability. A **direct API** is a versioned service operation called by the application. **MCP** is a common protocol for discovering and invoking compatible tools and resources. A **connector** is an integration layer that manages access to one or more external applications. **Browser or computer use** is the control of a graphical interface through application-executed actions. A **Skill** is a versioned package of instructions and supporting files. The capability may read a record, calculate a result, write to a system, send a message, operate a website or provide instructions for one of those routes.

The model may propose a call. The application, server, connector or browser worker executes it. That separation is the starting control. OpenAI's function-calling loop sends a tool definition to a model, receives a structured call, executes the function in the application and returns the result ([OpenAI, "Function calling"](https://developers.openai.com/api/docs/guides/function-calling)). Anthropic describes the same boundary: Claude selects a tool call, but the client application runs the function or request and supplies the result ([Anthropic, "How tool use works"](https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works)). Google's function-calling documentation likewise places execution in the application ([Google, "Function calling"](https://ai.google.dev/gemini-api/docs/function-calling)).

> **Key Takeaways**
>
> - Direct APIs provide the clearest access contract when a service exposes stable, versioned operations and structured data.
> - MCP standardises discovery and invocation semantics. It does not certify provenance, uptime, security, pricing or permission.
> - A connector can shorten integration work and manage delegated credentials, while leaving scope, principal mapping, data path and effect policy with the customer.
> - Browser automation is a compatibility route, not a free substitute for an API. Pages, screenshots, selectors, cookies and login state remain changing and potentially hostile inputs.
> - A Skill is a package of behaviour, resources and instructions. Its effective authority comes from the tools and credentials available at runtime.
> - A production access route needs an explicit effect, idempotency rule, timeout, failure evidence and revocation path.

This chapter uses provider and standards documentation checked on 13 September 2026. Product names, preview states, pricing, supported tools and retention terms can change. Documentation establishes capability and stated operating terms, not demand, reliability or accepted-job outcomes.

### Sources and scope

Agentic Economy compiled the dated participant map from the primary specifications and provider documentation linked in this chapter. The method separates documented capability from adoption and outcome evidence. MCP Registry metadata, provider catalogues and pricing pages show that an access surface is published or offered. They do not show how often independent customers invoke it, how often the work is accepted or whether the route is safe in a particular deployment. Records were checked on 13 September 2026. [About Agentic Economy](/about) explains the publication and its Australian focus. Readers can submit source corrections through the [contact page](/contact), where the editorial record can be checked before an update.

## Five access routes are coexisting

Agents currently reach external services through direct APIs, tool-calling interfaces, MCP servers, managed connectors and browser or computer control. Skills sit across these routes as packages of instructions and resources. None has displaced the others because each reaches a different part of the software market.

Direct APIs remain the strongest contract where a service exposes a stable operation. MCP is becoming a common way to describe and invoke tools across compatible hosts. Connector platforms aggregate authentication and routing across large SaaS catalogues. Browser and computer control extend agent reach into the long tail of software without suitable APIs. Our view is that access will remain hybrid: structured routes will carry repeat work, while browsers will continue to handle fragmented and exceptional paths.

Anthropic describes MCP as “an open standard connecting AI apps to tools and data” ([Anthropic, "Claude can now connect to your world"](https://www.anthropic.com/news/integrations)). The phrasing captures MCP's centre of gravity: connection. It does not turn the connected service into a trusted supplier or settle the authority attached to an invocation.

### Where this layer sits

Chapter 6 covers the runtime that holds state, selects components, handles interruption and recovers a run. This chapter covers how that runtime reaches a capability and what the capability returns. Chapter 8 covers messages and task lifecycles between independently operated agents. Chapter 9 covers identity, authority and policy. Orders, payment and settlement remain in Part III.

The same application can contain all five access forms. A Skill may tell the runtime how to use an API. A connector may expose that API through an MCP server. A browser session may be used for an exception. The forms are composable, but their evidence and failure modes remain different.

## The access route ladder

The route ladder orders access paths from explicit service contracts to interface-level compatibility. Structured repeat work clusters near the top; fragmented and exceptional work pushes down towards browser control. A Skill can accompany any row, but it does not change the underlying access contract.

![A radio array illustrates several service-access routes converging on one controlled execution path.](/media/editorial-library/radio-array-medium.webp)

| Order | Question | Route | What it gives the builder | What must still be proven |
| --- | --- | --- | --- | --- |
| 1 | Is there a versioned operation with structured input and output, server-side validation and a clear effect? | **Direct API or function call** | Deterministic transport, schema validation, explicit error responses and a service-owned resource boundary | Current authorisation, side-effect controls, idempotency, timeout handling and an acceptance receipt |
| 2 | Does a compatible capability need a common discovery and invocation protocol across clients? | **MCP server** | Standard server, client and host roles; `tools/list`, tool invocation, structured content and capability negotiation | Server identity and provenance, tool annotations, auth, approval policy, version drift, data handling and actual resource enforcement |
| 3 | Does one application need to reach multiple SaaS systems with user-delegated credentials? | **Connector** | Managed OAuth or API-key flows, account linking, routing and a normalised callable surface | Exact app scopes, end-user mapping, provider limits, token refresh and revoke behaviour, data retention and the action's business meaning |
| 4 | Is the service reachable only through a website or desktop interface? | **Browser or computer use** | UI interaction, session state and access to a long tail of software | Isolation, allowlisted destinations, current page state, login and cookie lifecycle, selector or visual drift, prompt injection, confirmation and a verifiable result |
| 5 | Is the route still ambiguous, unavailable or outside the authority boundary? | **Human hand-off or build the integration** | A safe stop and an explicit owner, or a stronger interface for repeated work | Acceptance, escalation, cost and a decision about whether the capability belongs in the product at all |

```text
The route begins with the capability the job must reach:
  |
  +-- Stable, versioned API with structured effect and receipt?
  |       +-- yes -> direct API/function call
  |
  +-- Common discovery and invocation needed for a compatible server?
  |       +-- yes -> MCP, after provenance/auth/tool review
  |
  +-- Many SaaS systems and delegated user accounts?
  |       +-- yes -> connector, after principal/scope/data-path review
  |
  +-- No reliable contract, but a website or desktop UI is available?
  |       +-- yes -> isolated browser/computer route, with confirmation
  |
  +-- otherwise -> human hand-off or build a stronger integration

  A Skill may sit beside any route as instructions and resources.
  It does not add credentials, permissions or a service effect.
```

The “yes” at each branch means “the route meets the job's reliability and authority requirement,” not merely “a library or product exists.” The narrowest route can still be rejected if it cannot show what happened.

## What each route actually standardises

### Direct APIs and function calls are the strongest starting contract

An API can name operations, validate inputs, return typed outputs and let the service enforce its own permissions. Function calling adds a model-facing schema and a loop around that API. OpenAI's strict mode is designed to make generated arguments adhere reliably to a supplied JSON Schema, and its `tool_choice` controls whether the model may choose any tool, must call one or must call a specified tool ([OpenAI, "Function calling"](https://developers.openai.com/api/docs/guides/function-calling)). The builder still needs server-side validation. A model-valid argument can be commercially wrong, stale or outside the user's mandate.

The direct route is strongest when the provider can answer five questions in its own contract:

1. What operation is being requested, and which fields are required?
2. Which reads, writes, disclosures or other effects can occur?
3. What response proves the operation completed, was rejected or remains unknown?
4. What should a caller do after a timeout, duplicate request or partial failure?
5. How are credentials, versions, rate limits, data handling and revocation managed?

The route does not have to be REST. A typed RPC method, a database procedure behind a policy gateway or a provider-specific function can be equally suitable. The test is whether the effect and evidence are explicit enough for the application to control.

### MCP standardises a conversation, not trust

The [MCP specification dated 28 July 2026](https://modelcontextprotocol.io/specification/2026-07-28/) defines a protocol for LLM applications to integrate with external data sources and tools. It separates a host application, MCP clients and MCP servers. Servers can expose resources, prompts and tools; tools are discoverable and invokable through JSON-RPC. The tools specification defines `tools/list`, pagination, input schemas, optional output schemas and structured results ([MCP, "Tools"](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). These are valuable interoperability primitives.

They are not a trust decision. The specification says tool annotations should be treated as untrusted unless the server is trusted. It also places consent and human control around tool use on the host and client. The MCP authorisation section makes OAuth-based authorisation optional for MCP and requires implementations that use it to validate tokens for the intended resource and audience ([MCP, "Authorization"](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)). A server can therefore be protocol-conformant while still being unsuitable for a sensitive job, incorrectly scoped or unavailable.

The [official MCP Registry](https://modelcontextprotocol.io/registry/about) is currently a preview metadata service. It manages namespaces and standardised `server.json` metadata, points to separately published packages or remote URLs and is intended to feed downstream aggregators. It does not host server artifacts, private servers or a universal security and uptime assessment. The [registry quickstart](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx) is therefore discovery evidence, not execution evidence.

A production MCP route pins the server identity and version, reviews the tool list, restricts the allowed tools, validates arguments and structured results, and retains approval and invocation evidence. A registry listing or a familiar tool name is not a substitute for those controls.

### Connectors centralise auth and routing

Connectors are integration products that make a set of third-party services callable through one application or agent surface. They may manage OAuth consent, token refresh, account linking, provider-specific request formats and routing. This can reduce the amount of integration code the buyer must maintain.

Pipedream's Connect documentation describes managed authentication and an MCP route for connecting an application or agent to third-party APIs ([Pipedream, "Connect"](https://pipedream.com/docs/connect); ["MCP for developers"](https://pipedream.com/docs/connect/mcp/developers)). Composio's connected-account documentation describes storing and refreshing provider tokens, private account links, access control and server-side credential injection ([Composio, "Connected accounts"](https://docs.composio.dev/docs/auth-configuration/connected-accounts)). Zapier's MCP documentation describes selecting app actions, connecting an MCP client and reviewing actions before confirmation ([Zapier, "MCP"](https://docs.zapier.com/mcp/home); ["Quickstart"](https://docs.zapier.com/mcp/quickstart)).

The convenience changes the control location. The connector may know the user's account, but the buyer still has to establish which principal the account represents, which scopes were granted, which application receives the data, which provider terms apply and how revocation propagates. A normalised action called `create_record` can have different validation, side effects and acceptance semantics in each destination.

Connectors win where managed authentication and service coverage reduce integration cost. Portability depends on preserving the provider resource identifier, request or correlation identifier, source account and action receipt rather than only the connector's display name.

### Browser and computer use reach the long tail with more uncertainty

Browser automation covers services that expose a UI but no suitable API or MCP server. Playwright's locators demonstrate the deterministic end of this route. Locators re-find elements on each action, support auto-waiting and retry, and are intended to use user-facing attributes such as roles and labels ([Playwright, "Locators"](https://playwright.dev/docs/locators)). That improves resilience to ordinary re-rendering. It does not make a changing website a stable contract.

Computer-use models operate at a broader boundary. OpenAI's computer-use guide has the application provide a browser or desktop environment, execute model-selected actions and return screenshots or tool results. It recommends isolation, allowlists, treating screen content as untrusted and confirmation for consequential actions ([OpenAI, "Computer use"](https://developers.openai.com/api/docs/guides/tools-computer-use)). Anthropic's computer-use documentation and Google's computer-use guide give the same basic operating boundary: the application controls the environment, and a sandbox, supervision and careful treatment of prompt injection are required ([Anthropic, "Computer use tool"](https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool); [Google, "Computer Use"](https://ai.google.dev/gemini-api/docs/computer-use)).

Australia's cyber-security authority reaches the same architectural conclusion. The Australian Signals Directorate treats the harness around an agent, including its tools, permissions and external data, as a control boundary and recommends defence in depth rather than relying on model behaviour alone ([ASD, "Agentic AI harnesses"](https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/agentic-ai-harnesses)). The guidance is globally relevant because the same boundary exists wherever an agent can act through an external service.

Managed browser providers supply the session layer. Browserbase documents an isolated cloud browser session with a connection URL, region, viewport, recording, proxy and identity options ([Browserbase, "Create a browser session"](https://docs.browserbase.com/platform/browser/getting-started/create-browser-session)). Its cost guidance distinguishes reusable sessions for cookies and multi-step work from short-lived stateless functions ([Browserbase, "Cost optimisation"](https://docs.browserbase.com/optimizations/cost/cost-optimization)). Browser Use documents sessions, persistent profiles and a client that starts and polls an agent run ([Browser Use, "Agent quickstart"](https://docs.browser-use.com/cloud/agent/quickstart)). Steel documents isolated sessions, lifecycle states, framework attachment, cleanup and metering by session duration ([Steel, "Session lifecycle"](https://docs.steel.dev/overview/sessions-api/session-lifecycle)).

The buyer is purchasing more than a selector library. Total cost includes model calls, browser session time, proxy or captcha services where permitted, recordings and storage, re-authentication, maintenance after UI changes and human review. A browser receipt contains enough page or application evidence to show which account, target and state were reached. A screenshot alone may not prove that a destructive action completed; a DOM extraction alone may not prove what a user saw.

### Skills package behaviour, not authority

Skills make repeatable know-how distributable. OpenAI describes Skills as reusable instructions and supporting files that can be selected by a model in a container, with explicit versions and hosted or local execution ([OpenAI, "Skills"](https://developers.openai.com/api/docs/guides/tools-skills)). Anthropic describes organised folders of instructions, scripts and resources that extend an agent's capability and can be versioned or kept private ([Anthropic, "Skills guide"](https://platform.claude.com/docs/en/build-with-claude/skills-guide)).

The package can explain how to call a tool, interpret an output, recover from a known error or perform a multi-step workflow. It cannot make a missing API exist, turn an unapproved token into an approved one or prove that its instructions are safe. OpenAI warns that a Skill can influence planning, tool use and command execution and warrants inspection for prompt injection and data-exfiltration risk. Skills are privileged instructions and supporting code, not a trust root.

The MCP Skills working group is still experimental. Its repository explicitly says the extension is in incubation and is not an official MCP specification or recommendation ([MCP Skills Working Group](https://github.com/modelcontextprotocol/ext-skills)). This is useful evidence that the packaging problem is being explored. It is not evidence of a settled portable authority standard.

## Who supplies access

<!-- SOURCE COMPILATION: Agentic Economy assembled this dated participant map from primary specifications and provider documentation checked on 13 September 2026. Capability and commercial-model descriptions are provider statements; the adoption column records what this review can and cannot infer. -->

| Participant or layer | Documented capability | Business model or access surface | Adoption evidence and boundary |
| --- | --- | --- | --- |
| **OpenAI** | Function calling, remote MCP and maintained connectors, computer use, and versioned Skills | API usage for model and tool calls; connector and remote-server terms sit beside the model account; Skills run in an API-managed execution boundary | Official guides establish callable surfaces, approvals and safety controls. They do not publish a comparable accepted-job denominator in this review. |
| **Anthropic** | Client and server tool use, remote MCP connector, browser/computer use and Agent Skills | API or managed-agent usage; remote MCP calls use a server URL and optional authorisation; Skills are attached and versioned | Official documentation establishes the execution boundary and configuration. It does not establish cross-customer invocation or outcome rates. |
| **Google Gemini** | Function calling, managed tools such as Search, Maps, URL Context, Code Execution and File Search, plus computer use | Gemini API or Google Cloud endpoint; managed tools and custom function calls have different execution and billing boundaries | Official guides establish tool classes and client-side computer-use execution. They do not establish production reliability for a buyer's job. |
| **MCP specification and Registry** | Common host/client/server roles, JSON-RPC, tool discovery and invocation, metadata publication and namespaces | Open protocol; servers may be self-hosted, packaged or remote; registry is a preview metadata service | Specification and registry docs establish interoperability and publication mechanics, not server trust, uptime, demand or completed work. |
| **Playwright** | Browser automation with locators, auto-waiting, retries and browser contexts | Open-source automation library; the operator supplies browsers, workers, sessions and hosting | Documentation establishes implementation behaviour. Package availability is not evidence that a target site's UI remains compatible or that a job is accepted. |
| **Browserbase, Browser Use and Steel** | Managed browser sessions, profiles or storage, framework connections, recordings and lifecycle controls | Cloud browser sessions or agent runs, generally metered by session duration, run or related resources; exact plan terms vary | Provider docs and pricing establish available supply and cost units. They do not prove page stability, successful outcomes or safe handling of a particular site. |
| **Pipedream Connect** | Managed auth, connected accounts and an MCP surface for third-party APIs | Connect development and production plans with platform or usage terms; provider credentials are managed by the service | Docs establish auth and routing features, not the correctness of principal mapping or the acceptance of downstream effects. |
| **Composio** | Connected-account lifecycle, OAuth/API-key handling, server-side credential injection and tool execution | Managed integration platform with plan and usage terms | Docs establish token isolation and lifecycle operations. They do not establish that a normalised tool has identical semantics across providers. |
| **Zapier MCP** | App connection, selected actions and MCP invocation through a client | Existing Zapier plan and task or usage terms, as documented by Zapier | Docs establish a broad app-action catalogue and client flow. They do not establish task success, safe scopes or portability of the resulting workflow. |

The table is deliberately compact. It records capability supply as of a date, not a league table. A provider's number of listed tools, integrations or Skills would be a catalogue measure. It is not adoption, accepted-job volume, reliability or customer value.

## Operating flow and failure states

The route is a controlled state transition, not a single model call.

```text
job objective and acceptance test
  -> choose route and pin provider/server/version
  -> resolve principal, credential and allowed effect
  -> discover or load only the permitted operation
  -> validate input and approval requirements
  -> invoke through API, MCP, connector or browser session
  -> receive result, receipt and evidence
  -> reconcile the resource state
  -> accept, retry safely, compensate or hand off
```

The following failure labels belong in the run record. They describe what the application knows, what it must not infer and the minimum next action.

| State | Meaning | Operating requirement | Evidence retained |
| --- | --- | --- | --- |
| **Discovery failed** | The server, connector account or operation cannot be found, or the advertised tool list changed | Execution stops pending provenance and configuration review; similarly named tools are not substituted automatically | Registry or catalogue record, server URL, tool-list version and discovery error |
| **Authentication or authorisation failed** | Credential is missing, expired, revoked, wrong audience or outside scope; common HTTP responses include 401 or 403 | Re-consent or owner escalation; blind retries and model-invented credentials remain outside the route | Principal, audience, scope, issuer, response code, consent and revoke state |
| **Schema invalid** | Input does not satisfy the operation's schema, or output fails its declared schema | Pre-effect rejection where possible, followed by deterministic repair or hand-off | Input and output schemas, validation errors, proposed arguments and whether execution began |
| **Approval denied or effect out of policy** | A required human approval is absent or the target, amount, data or timing exceeds policy | A hard stop until the canonical effect is re-presented or the job changes through an authorised path | Approval digest, policy version, decision inputs and denial reason |
| **Rate limited or unavailable** | Provider returns a quota, overload or service-unavailable response | Documented backoff only for reads or operations proven safe to retry; writes retain an unknown state | Provider response, retry-after or deadline, attempt number and idempotency key |
| **Transport timeout or connection loss** | The caller does not know whether the provider completed the call | Outcome remains unknown until an idempotency key or status query reconciles the side effect | Request ID, deadline, connection status, status-query result and final resource state |
| **Browser session lost** | Browser, cookie, profile, login or worker state disappeared or expired | Execution stops and reauthentication follows an approved route; assumed page state is discarded | Session ID, profile, last known URL, screenshot or DOM checkpoint, release reason |
| **UI changed** | Locator, page structure, text, visual control or navigation no longer matches the tested route | The workflow moves to maintenance or human review rather than improvising a destructive click | Target URL, locator or action, page fingerprint, screenshot and changed-state signal |
| **Adversarial content detected** | A page, file, tool description or result contains instructions that try to redirect the job or expand authority | The content remains data; operating policy holds, new permissions are blocked and material cases escalate | Content source, extracted instruction, policy decision and blocked action |
| **Ambiguous or partial result** | A response is incomplete, contradictory or reports a partial effect | Status and resource-state reconciliation, followed by human review where uncertainty remains | Provider receipt, resource snapshot, partial fields and reconciliation decision |
| **Revoked during work** | The principal, token, session, server or Skill is no longer approved | Queued work and sessions are cancelled; derived credentials and in-flight effects are contained | Revocation event, propagation checks, active sessions, queued calls and containment result |

The highest-risk state is not an explicit error. It is an unknown write. The system must be able to say “the request's final effect is not yet known” without converting that uncertainty into a duplicate action or a false success.

### Browser-specific evidence

For a browser route, record the destination, account or profile, session identifier, page or application state before the action, exact target locator or computer action, confirmation event and post-action state. A model-generated screenshot is evidence of an observation, not by itself a receipt from the service. Do not close a destructive or externally visible action on visual evidence alone: capture and reconcile a confirmation number, resource URL, event ID or downloadable record, or require independent human verification when the service exposes no durable receipt.

### MCP-specific evidence

An MCP evidence record contains the server URL or package identity, namespace, version, transport, `tools/list` snapshot, selected tool, input and output schema, auth audience and scopes, approval decision and returned structured content. Tool annotations and descriptions remain untrusted until the server enters a reviewed trust set. A changed tool list is a changed interface, not presumed backward compatibility.

## The commercial models behind the routes

Service access is part of the cost of an accepted job. The visible model or API price is only one line.

| Route | Common charge or funding model | Additional operating cost |
| --- | --- | --- |
| **Direct API** | Request, token, compute, data-volume, seat or volume-commitment pricing | Integration, schema migration, retries, rate-limit capacity, monitoring and provider exit work |
| **MCP server** | Self-hosted open-source operation, hosted server subscription or provider API usage | Server hosting, package and version review, registry or catalogue maintenance, auth, tool-list drift and per-server due diligence |
| **Connector** | Platform subscription, connected-account plan, credits or successful tool-call/task usage | Provider limits, data transfer, connector-specific semantics, account support, switching and the platform's own outage or policy boundary |
| **Browser or computer use** | Browser session minute/hour, agent run, request, proxy, recording or storage usage | Model actions, session start-up, re-authentication, UI maintenance, failed runs, review, captcha or approved specialised access services |
| **Skill** | Often distributed with the model or agent product, or managed as a private package with versioning | Inspection, testing, sandboxing, package updates and the runtime, tools and credentials used by the Skill |

The correct denominator is cost per accepted job. Include model calls, tool calls, browser time, connector usage, integration maintenance, review, failed or duplicated effects and the cost of retaining evidence. A connector that reduces initial build time may still cost more if it obscures an important provider limit or raises the cost of migration. A browser route may be rational for a low-volume exception and uneconomic for a high-volume workflow that could justify an API.

## The Service Access Contract

<!-- UNIQUE INSIGHT: Agentic Economy's Service Access Contract turns a route choice into an operational record. It is an editorial decision artefact, not a tested or standards-approved schema. -->

A material capability increasingly needs one Service Access Contract. It owns the schema, effect, idempotency and receipt for one capability boundary, and references the job, run and current Authority Record instead of duplicating them. Chapter 10 defines the [shared record ownership and join keys](/guides/ai-agent-evaluation-observability-security#section-one-job-record-five-linked-control-views).

| Contract field | Required answer |
| --- | --- |
| **Capability and purpose** | What does this route do, for which named job, and what is explicitly out of scope? |
| **Owner, intermediary and canonical endpoint** | Which resource owner, provider, connector or browser intermediary is accountable for each boundary? What API URL, MCP server, connector action, website or desktop application is canonical? |
| **Interface and version** | Which transport, API version, MCP protocol/server version, connector release, browser profile and Skill version are allowed? |
| **Input schema and constraints** | What structured fields, formats, bounds, defaults and validation rules are required? Which values must never come from untrusted page or document text? |
| **Output schema and acceptance** | What fields, status, receipt or resource state prove success? What is the acceptance test for this job? |
| **Credential boundary** | Which principal, agent workload, user account, audience, scopes, token lifetime and session/profile may be used? Where are credentials stored and injected? |
| **Permitted effects** | Which reads, writes, sends, disclosures, purchases, deletions or other effects are allowed? Which are prohibited? |
| **Approval and policy** | Which effects require confirmation? What canonical representation is approved, which policy version evaluates it and where is the decision enforced? |
| **Idempotency and reconciliation** | What idempotency key or natural deduplication exists? Which status query or resource read resolves an unknown write? |
| **Timeout and lifecycle** | What is the deadline, session timeout, keep-alive, release rule and maximum retry window? |
| **Error classes and retry matrix** | Which errors are safe to retry, which require reconciliation, which require re-authentication and which are hard stops? |
| **Evidence returned** | Which request, correlation, event or resource IDs, structured output, page state, screenshot, DOM record, version and timestamp are retained? |
| **Data handling** | What data crosses the boundary, where it is processed or retained, which intermediaries and subprocessors receive it, when it is deleted and who can prove deletion or preserve a lawful hold? |
| **Revocation and kill path** | How are new calls blocked, active tokens and sessions invalidated, queued calls cancelled and in-flight effects contained? What propagation time is expected? |
| **Change and ownership** | Who reviews schema, tool-list, UI, Skill, provider-term and permission changes? Who accepts or retires the route? |
| **Recourse** | Which party owns a wrong, duplicated or undisclosed effect, and which correction, restoration, refund, notification or dispute path applies? |

### Minimal completed example

This example is intentionally generic. It shows the shape of a contract, not a production integration or a claim about any named provider.

| Field | Example entry |
| --- | --- |
| **Capability and purpose** | Read the current status of a named customer service request. No update, message or deletion. |
| **Route** | Direct API operation, version pinned; MCP and browser are fallback candidates only after separate review. |
| **Input** | `customer_id` and `request_id`; both validated against the caller's tenant and job scope. |
| **Output** | Status enum, provider resource ID, `updated_at`, request correlation ID and source version. |
| **Credential boundary** | Short-lived service credential for one tenant, audience restricted to the provider resource; no general write scope. |
| **Side effect** | Read only. The provider must not send notifications or mutate workflow state. |
| **Idempotency and timeout** | Read can be repeated; 10-second deadline. On timeout, one status read is allowed before hand-off. |
| **Failure handling** | 401/403 stops for re-auth or owner review; 429 follows provider backoff; 5xx and timeout return unknown freshness, not a fabricated status. |
| **Evidence** | Raw provider status, resource ID, correlation ID, retrieval time, API version and acceptance result. |
| **Revocation** | Disable the service credential, remove tenant mapping, close active sessions if any and prove a denied read. |

For a write operation, add the exact effect representation, approval digest, idempotency key, post-action resource state and compensation or manual-recovery path. For a browser operation, add the allowlisted origin, session/profile policy, locator or action sequence, page checkpoint and human confirmation. For a Skill, add package hash, files inspected, sandbox boundary and a statement that no additional credentials or tools are introduced.

## What the sources establish

| Evidence source | It establishes | It does not establish |
| --- | --- | --- |
| Direct API or function schema | A described operation, input shape and possibly output shape | That the model's proposed values are safe, that the caller is authorised or that the effect completed |
| MCP specification | Common roles, messages, capability negotiation, discovery and structured tool results | Server trust, code safety, uptime, commercial terms, resource policy or accepted outcomes |
| MCP Registry record | Published metadata, namespace and installation or remote-server pointers | That an artifact is available, secure, current, private, reliable or widely used |
| Connector documentation | Account linking, token handling, routing and a callable integration surface | Correct principal mapping, least privilege, provider-specific semantics or portability |
| Browser framework or session docs | How locators, contexts, sessions, profiles, screenshots and lifecycle controls work | That a target UI will remain stable, that a login is legitimate or that a clicked action had the intended effect |
| Skill package or Skills API | A versioned set of instructions, scripts and resources | Authority, credentials, tool existence, safe content or successful fulfilment |
| Pricing or catalogue page | A published commercial access model and available product surface | Demand, accepted-job cost, uptime, quality, security or switching cost in the buyer's workload |
| One successful run | One job reached an observed result under one route and configuration | General reliability, safe retry, revocation, cross-tenant isolation or performance under change |

The adoption gap is material. Public documentation is rich on interfaces and sparse on comparable accepted-job denominators. A catalogue count, registry listing, SDK download or case study may indicate supply or interest. None is a substitute for buyer-specific acceptance tests, failure evidence and post-revocation checks.

## What the market has not resolved

Access is becoming easier to package but not necessarily easier to trust. MCP registries and connector catalogues expand the number of visible tools. Browser agents expand the number of reachable applications. Neither development establishes the identity, authority, reliability or commercial terms of the underlying service.

The strategic contest is moving towards the control point around access: who holds credentials, selects tools, governs browser sessions and observes the resulting effects. We expect APIs and MCP to converge around structured repeat work, connector platforms to retain an enterprise distribution role, and browser infrastructure to become the compatibility layer for everything else.

## Where we see the market going

Access will remain a hierarchy rather than collapse into one universal interface. Direct APIs will carry high-repeat and high-consequence work; MCP and connector platforms will broaden reach; browser and computer use will remain the long-tail adapter; Skills will package behaviour across all of them.

Competition will move from raw connector counts towards authority, evidence and maintenance. The winning access layers will show which principal acted, which effect occurred, whether it can be revoked and how quickly a broken integration is repaired.

The chapter's thesis would be weakened if matched production tests showed that a broader route consistently delivers more accepted work at lower total cost without sacrificing authority, evidence or revocation. The open seams to watch are:

1. **MCP trust and portability:** Can independently operated MCP servers develop verified provenance, security, uptime, schema compatibility and accepted-job evidence that travels across clients? If so, per-server review may become lighter, although resource policy would still remain local.
2. **Connector authority:** Can connector platforms preserve principal, purpose, scope, data lineage and revocation across many providers while costing less than direct integrations for the buyer's actual jobs?
3. **Browser reliability:** Can managed browser systems make UI change, session recovery, hostile-content handling and result receipts dependable enough that the UI route approaches an API for a material workflow?
4. **Skills boundaries:** Can Skills become portable, signed and inspectable packages whose instructions are separated from policy, credentials and tool authority? If they cannot, they remain useful packaging with a persistent supply-chain risk.
5. **Accepted-job evidence:** Will providers publish comparable, independently checkable evidence of completed and accepted work rather than only catalogue size, tool-call counts or product availability?

## Summary and source limitations

The market is settling into a route hierarchy. Direct APIs remain the narrowest option where they exist. MCP adds interoperable discovery and invocation after server and tool review. Connectors trade some directness for managed identity and routing. Browser and computer interaction cover the long tail at the cost of isolation, confirmation and maintenance. Skills package behaviour but do not confer permission.

This chapter relies on primary specifications and vendor documentation. Those sources are strongest on declared interfaces, configuration and commercial surfaces. They are weaker on independent adoption, cross-provider reliability, accepted-job rates, incident frequency, total switching cost and effective revocation in a customer's specific architecture. Those limitations are part of the finding, not a reason to turn catalogue supply into market proof.

## About the author and editorial record

Agentic Economy is an independent research and publishing project about the global infrastructure and markets behind delegated software work. Joel Chan founded the publication in Perth. This chapter is part of *The Hitchhiker's Guide to the Agentic Economy*.

**Editorial record**

- Drafted: 13 September 2026
- Evidence checked: 13 September 2026
- Scope: direct APIs and function calls, MCP servers and Registry, connectors, browser/computer use and packaged Skills
- Exclusions: agent-to-agent coordination, identity and authority semantics, payment and settlement, and application deployment architecture
- Status: global infrastructure edition, 2026

[Back to the report hub](/guides/hitchhikers-guide-agentic-economy-2026) · Previous: [runtimes, orchestration and harnesses](/guides/ai-agent-runtimes-orchestration-harnesses) · Next: [agent-to-agent coordination](/guides/ai-agent-to-agent-coordination).