Lesson 31.1 traced one question through one tool path. Now the harder question: which path? An agent can reach the outside world through four different surfaces, and beginners treat them as interchangeable. They are not. The surface decides how reliable the result is, what it costs, what permissions are involved, and what evidence you can audit later.

You already met these surfaces in Part V. This lesson puts them to work inside an agent.

The four surfaces in plain language

API direct. Your code calls a service's documented software interface — HTTPS request, structured JSON back. Example: a market-data REST API, a Stripe API, a GitHub API. The service designed this door for programs. It is the most reliable, cheapest per successful result, and easiest to audit because requests and responses are structured and logged.

MCP standard. The Model Context Protocol standardizes how tools, data sources, and prompts are exposed to a model. Think of it as an agreement about the shape of the tool shelf: what each tool does, what inputs it takes, what it returns. An MCP server can wrap an API, a database, or a local resource so any MCP-compatible agent can use it the same way. It does not make the underlying data better — it makes the connection consistent, describable, and easier to permission and log.

Browser rendered. The agent operates a rendered web page the way a person would: navigating, reading visible content, sometimes filling forms or clicking. Useful when no API exists — checking how a page renders, validating a public listing, capturing what a customer actually sees. But pages change layout, logins expire, anti-bot measures trigger, and extracted data has no schema guarantee. Fragile, slow, and expensive per verified fact.

CLI authenticated project. The agent runs commands inside an authenticated project or system environment — git, gh, docker, kubectl, database CLIs, deployment CLIs. This is the surface for operating your own systems: inspecting logs, creating previews, running tests. Power comes with blast radius: a CLI command can read, build, deploy, or delete. Permissions, working directory, and dry-run support decide whether it is safe.

The rule that saves you

An official API gives you permission, structure, freshness metadata, error codes, and rate limits — the exact things Lesson 31.1 showed keep an agent honest. Browser extraction gives you pixels and hope. There are legitimate cases for the browser (no API, visual verification, one-off research inside your rights), but "the API needed a key and the page was right there" is not a reason. It is how agents end up with stale data, broken runs, and access they cannot explain.

The same honesty applies in reverse. Do not use a production CLI to answer a question a read API could answer. Do not drive a browser through a login flow to fetch data the provider offers as a CSV export or webhook. Match the surface to the job, then grant the narrowest permission that surface needs — a subject Lesson 31.3 makes operational.

Three scenarios, three choices

Scenario A: nightly price-and-filings check. An agent must record closing prices and flag new quarterly filings for ten tickers. Best surface: API direct (market-data API + filings API), optionally exposed to the agent through MCP so the tool definitions stay consistent. Why: structured, timestamped, cheap, auditable. Browser verdict: wrong — ten pages, layout drift, no freshness guarantees, ten times the model cost.

Scenario B: "does our signup page render correctly after deploy?" The agent must confirm the page looks right and the form submits. Best surface: browser rendered (or a hosted web-check tool). Why: the question is inherently visual and interactive — no API can answer "does the button overlap the text on mobile." Keep it bounded: named URLs, read-only except a test submission, screenshots saved as evidence.

Scenario C: "prepare a preview of this pull request and report the test logs." Best surface: CLI authenticated project (gh, git, deployment CLI) inside the project environment with a read-plus-preview scope. Why: the work lives in the repository and deployment system, not on the public web. The agent can read logs and create a preview but — as Lesson 31.3 will enforce — cannot promote to production or change DNS without human approval.

Notice the pattern. The choice follows the question: structured facts want APIs, visual truth wants the browser, your own systems want the CLI, and MCP keeps whichever tools you pick uniformly described and permissioned.

Check your understanding

1. What does MCP standardize, and what does it not guarantee about data quality? 2. Why does browser automation cost more per verified fact than an API call? 3. Why is a CLI powerful and risky in the same way? 4. State the official-API-over-scraping rule in your own words.

Exercise: surface choice for three scenarios

Create SURFACE-CHOICE.md with three scenarios of your own (or use the three above with your own reasoning). For each:

# SURFACE-CHOICE.md

## Scenario 1: [name]
- Question to answer:
- Chosen surface (API / MCP-wrapped API / browser / CLI):
- Why this surface fits:
- Rejected alternatives and why:
- Reliability effect:
- Cost / speed effect:
- Permissions needed:
- Audit evidence kept:

## Scenario 2: ...
## Scenario 3: ...

Finish line: three completed scenarios, each naming one surface, justifying it on reliability, cost, permissions, and auditability, and stating the evidence kept.

Verification: for each scenario, ask: "if the official API existed, did I choose it?" If you chose browser or broad CLI access where a scoped API would work, rewrite the choice. If a reviewer cannot tell from your file what permission the agent holds, narrow it.

Next, Lesson 31.3 turns permissions into a working document: scopes, read-only credentials, test environments, dry runs, and the approval gates that separate drafting from doing.