This is the finale of Part V — the lesson where every thread comes together.

Class 13 taught you how software talks: requests, responses, and documentation. Class 14 taught you who may talk: identity, keys, OAuth consent, and boundaries. Class 15 taught you how agents discover tools through MCP. Class 16 taught you to choose the smallest useful path. Class 17 taught you what to build and what to connect.

Now you turn all of it into a habit: no integration without a one-page plan.

Why a plan comes before keys

Coding agents are fast and literal. Tell one to "add weather data" and it will pick a provider, invent field names, hardcode a key, and wire live data into production before you have reviewed anything. The failure is not the agent's — it is the missing specification.

A connection plan fixes this by deciding the boundary *before* implementation: what the integration is for, which path it takes, what data crosses, whose credentials carry it, how success is proven, and how you roll back. One page of decisions saves ten pages of debugging — and it becomes the context you paste to the agent so it builds what you meant.

Think of it as the key-ring rule from Lesson 14.4 made concrete: small keys, named doors, tested first.

The connection plan template

Copy this template for every integration. Fill every field — "TBD" is an acceptable draft answer, a blank line is not.

Ten fields. Each one maps to a Tools lesson: outcome and capability (17.1), service (17.2), path (16.3), data shape (13.2–13.3), identity (14.1–14.4), docs-first workflow (13.4), MCP inspection (15.3), evidence and logging (16.2), custom-layer handoff (17.3).

Worked example: read-only weather data

Say your small planning app should show a forecast beside each saved trip. Here is a compact plan:

• Outcome: each trip card shows today's high, low, and conditions for its destination.
• Capability: live reference data — pure infrastructure, not differentiated.
• Source: a documented public weather-data provider with a free tier sufficient for trip-card volumes (confirm current terms, coverage, and attribution requirements from its official docs before building).
• Path: direct read-only API call from server-side code. No MCP server needed — this is app data, not an agent workflow — and no custom adapter yet.
• Data: outward — latitude, longitude, date. Inward — high, low, condition code, observation time. Nothing personal leaves; responses cached per destination for one hour, not stored permanently.
• Identity: server-side API key in deployment environment variables plus local .env (never committed, never in browser code). Read-only key with a spending cap and rate-limit alert.
• Test: local script first with one fixed coordinate; then a preview deployment showing two destinations. Production only after both render correctly.
• Evidence: a 200 response with the three expected fields saved to the project log, plus a screenshot of the trip card rendering them.
• Rollback: if the key leaks, revoke and rotate; if the provider fails, trip cards render without weather plus an "unavailable" note — the app never breaks because weather is down.
• Owner + docs: named owner; link to the provider's current endpoint reference pinned in the plan.

Notice the discipline: read-only first, smallest request, server-side secrets, cached responses, graceful degradation. That is Classes 13 and 14 applied. And notice what the agent receives: not "add weather," but this page. An agent given this plan implements; an agent given a vague wish improvises.

The plan is agent context

Paste the finished plan to your coding agent before it changes anything:

Only after the summary is correct do you authorize the test call — then implementation, then the preview check. Inspect → draft → test → limited write → production, the graduated ladder from Lesson 14.4. The plan does not slow the agent down. It aims it.

Keep every plan in the project. When a provider renames a field six months from now, the plan tells you — or your successor, or your next agent — what was intended, what was connected, and where the boundary was drawn.

Pointing at the data path

One question survives every plan in this finale: the plan says *how* to connect — but is the underlying data worth it? Is the coverage real, the licensing clean, the freshness adequate, the source trustworthy?

That is Part VI: Data. Tools taught you to call and control. Data teaches you to judge: source quality, licensing, storage, queries, and retrieval — including the full database work with Supabase and Postgres that Lesson 17.2 deliberately deferred. You now have the pipes. Next you learn what deserves to flow through them.

Check your understanding

1. Why should the plan exist before the agent receives credentials? 2. What belongs in "success evidence" — and why isn't "it returned something" enough? 3. What is the difference between the *path* field and the *source* field? 4. What should happen to your app when a read-only data provider goes down?

Exercise: write your INTEGRATION-PLAN.md

Create a connection plan for one real idea — the weather example above, your research app's first data source, or any integration from your Lesson 17.2 stack card. Use the ten-field template, keep it to one page, and save it in your project as INTEGRATION-PLAN.md.

Finish line: a Markdown file an agent can read before it changes anything — outcome, path, data fields, identity, test environment, evidence, rollback, owner, and docs link, all filled. Verify it with the agent prompt above: if the agent cannot summarize the boundary back correctly, the plan is not done. When it can, you have closed Part V — and you are ready for Part VI, where you learn whether your data deserves the pipes you just built.