Picture the offsite. Whiteboard columns: Growth, Retention, AI. Under AI, the stickies write themselves. Chatbot for support. Smart search for inventory. Copilot in the booking flow. A little agent that "helps users find what they need" — meaning: helps them navigate your taxonomy while they remain trapped in your session.

Every sticky assumes the same geometry. The human still enters your world. Your product still owns the interaction. Your AI sits inside your attention machine and makes the clicks slightly less painful. That is not stupid. It is merely one generation behind the threat.

Why can't my AI use your business?

The app still thinks it owns the customer

For fifteen years the consumer software playbook was simple enough to print on a mug: own the user's attention. Download the app. Stay logged in. Turn notifications on. Open us. Navigate our filters. Receive our recommendations. Complete the transaction inside our glass.

That model trained an entire industry to treat the human interface as the integration surface. If a partner needed access, you built a portal or an EDI project. If a power user needed speed, you added shortcuts and saved searches. If AI arrived, you put it where the attention already was — inside the app — because that is where product managers are paid to put features.

The agent world reverses the centre of gravity.

USER ATTENTION
      ↓
     APP
      ↓
  your AI (maybe)

USER INTENT
      ↓
PERSONAL AGENT
      ↓
  your service
  (among others)

In the second geometry, your service is not the custodian of the user's life. It is an actuator — one of several systems the agent can operate when a durable intention becomes actionable. Pickleball is important. The booking app is replaceable. Travel is important. The airline app is a vendor. The claim is important. The adjuster's operational database is not something the insurer should have to install.

That is the lived complaint behind this ebook. People building product can readily invent AI features for humans who are already logged in. What they are not designing — yet — is a clean way for an external, authorised intelligence to hold the user's intent and transact without asking the human to re-express that intent through five clicks, twice a week, forever.

Name the requirement: agent addressability

Agent addressability is the service-side product question this piece owns:

Can an authorised intelligence outside your product perceive relevant state, understand available actions, and safely act for a human without impersonating fingers on your UI?

That is a different job from "add AI." It is also a different job from "we have an internal API the mobile app uses." The mobile app is still your client. The personal agent is the customer's client. Confusing those two is how organisations ship V2 copilots and call the strategy complete.

Humans do not disappear. Discovery, trust formation, edge cases, and high-emotion moments will keep using screens. What collapses is the unpaid labour of translating a durable intention — keep me in suitable sessions, show me this claim, reorder the usual — into navigation theatre every time the world changes.

The sticky that never makes the board

If you want a diagnostic for your next planning session, add one sticky under AI and force a serious answer:

Customer grants their agent scoped access. Agent completes the primary job without opening our UI. What is missing?

If the room can only answer with "they'd use our chatbot," you are still stuck in the old geometry. If the room answers with state, actions, delegated authority, consequences, and change feeds — you have started to speak agent addressability. The next chapter names the ladder most teams are climbing without realising which rung is the cliff.

Product language has collapsed too many different systems into the word "agent." A help bubble, a copilot sidebar, an in-app booker, and a personal agent that never opens your product are not the same animal. If you fund them as if they were, you will optimise for demos that look modern and still leave the business unusable by the intelligence the customer actually trusts.

Here is the ladder this ebook uses as doctrine. Later chapters apply it; they do not redefine it.

Most vendors build V2. The threat is V4.

V1 — Chatbot: smarter navigation, same fingers

A sports booking product ships a help bubble. You type "pickleball Sunday." It returns a link into search, a FAQ about membership, or a cheerful paraphrase of the filters you already knew existed. The human still scrolls results, interprets capacity icons, and taps Book.

V1 is not worthless. It reduces support load and occasionally shortens the path through a bad information architecture. It is still the human operating the app. The AI improved the brochure, not the operability of the business.

V2 — In-app agent: come into my world and give me your intent

Now the product has a real conversational surface inside the logged-in experience. You can say "beginner pickleball near me this week" and the agent filters inventory, explains waitlists, and proposes times. Product marketing calls it an agent. Engineering is proud — correctly — that retrieval and tool use work inside the session.

Look at the geometry carefully. You still opened the app. You still talked to their AI. The context window ends at the product boundary. The centre of gravity has not moved. You have built a better concierge for a hotel you still have to walk into.

This is where most 2026 roadmaps live. It photographs well. It is fundable. It is also the rung people confuse with transformation.

V3 — App's AI acts: autonomy without surrendering context

The in-app agent can book, join a waitlist, cancel within policy, and charge a saved card — for you — inside the product. The demo is strong: "just tell us what you want and we handle it." For a single-domain, single-session job, V3 is a genuine step up from V2.

What V3 cannot do honestly is hold a full human life. Your work calendar, other sports, travel, health constraints, and the fact that you cancel Friday sessions but never Wednesday ones do not naturally live inside a booking vendor. To approximate that, every vendor would need its own longitudinal dossier of you — OpenSports-Scott, airline-Scott, insurer-Scott, bank-Scott — six partial Scotts, each creepy and incomplete.

V3 is still app-centric. The app's AI operates the app. Context ownership has not flipped.

V4 — User's AI operates services

V4 is the discontinuity. The personal agent holds durable intent and authorisation across domains. The service exposes a machine-legible surface. The happy path does not require the human to open the product UI at all.

Human: "Keep me booked into suitable pickleball."

        PERSONAL AGENT
  knows calendar · pattern · payment grant · preferences

        ↓ discovers opening / books within scope

Service: inventory · capacity · rules · payment rails

Human sees: ✓ Wednesday 7pm booked
            (no product UI in the loop)

The service still does the hard operational work — membership, capacity, payment, policy. What disappears is the monopoly on the interaction. The human interface becomes invisible for the routine loop. That is not an insult to design. It is what happens when attention is too expensive to waste on re-expressing known intent.

The Scott model should sit with Scott

V4 is also a privacy and product sanity argument. The longitudinal model of a person — preferences, patterns, constraints, authorisations — should sit with the person (and their agent), not be poorly reconstructed inside every SaaS they touch. Services should expose state and action. They should not need to become the operating system of someone's life to remain useful.

Mark every AI initiative on this ladder before you fund it. If the portfolio is all V1–V3, you are investing in a better hotel concierge while someone else builds the transport layer that never needs the lobby.

Teams that have spent a decade polishing onboarding flows, empty states, and brand moments often hear "agent access" as an insult — as if you are asking them to throw away craft. You are not. You are asking them to admit that craft for humans and operability for agents are different surfaces. A logo that covers half the screen during a habitual rebooking is not a feature an agent can use. It is noise in a transaction phase.

Two different contracts with the world

Chapter 6 turns those five elements into a working checklist. Here the point is simpler: shipping AI onto the left column does not create the right column. People are adding LLMs to pixels and navigation. Agent addressability asks for the second contract.

Pixels + navigation are not a delegation surface.

Why "we have an API" is usually not the answer

Of course your service has machine interfaces. The app talks to a backend. Partners may have Zapier hooks or a B2B API. Internal tools hit the same databases. That proves the domain is computable. It does not prove a customer's personal agent can, under a grant the customer controls:

• read only the slice of state it needs,
• invoke only the actions that were authorised,
• understand monetary and policy consequences before acting,
• learn when inventory opens without asking the human to refresh.

A traditional REST surface can implement all of that. Most products implement some of the first two and call the project finished. Agents fail in the gaps: authority semantics, structured consequences, and change subscription. "POST /bookings exists" is not the same as "an external agent may book pickleball for Scott up to $X until revoked, and will be told when Wednesday opens."

App-shaped worlds are hostile to foreign agents

A public website is at least broadly legible to a browser agent. A native app often puts the same business behind a mobile sandbox, a private application protocol, device-bound session state, push notifications, and platform payment flows. The service still has machine interfaces somewhere — the app must speak to something. That interface is optimised for your client, not for an independent agent the user brought with them.

So teams reach for the fake solution: let the agent drive the UI. Screenshot, click, scrape, hope the layout does not change. That is RPA cosplay. It is brittle, often policy-hostile, and it treats your accidental affordances as a contract. Impersonating fingers is not addressability. Addressability is a stable, authorised, machine-legible surface you intended to expose.

A small example that is not small

Consider booking horizon. Humans invent workarounds: "check every evening after six, because that is when next week's sessions appear." That rule lives in the user's head. An agent cannot ethically or reliably inherit a superstition about refresh timing. It needs machine-legible facts: when booking opens, who is eligible, what capacity remains, what join_waitlist does as a side effect, whether a second identical request is a no-op or a double charge.

None of that is a gradient button. All of it is product work. If you only invest in prettier human journeys, you will keep winning design awards for a surface agents will eventually route around — or that competitors will wrap.

Notice what the human was actually doing in that "check after six" workaround. They were running a subscription loop in wetware: poll for change, evaluate eligibility, decide, act. That loop is exactly what a personal agent is for. If your product only supports the loop as a sequence of screens, you have outsourced your change-subscription system to unpaid human attention. Agent addressability means taking that loop back as a first-class surface — not hoping users enjoy the choreography.

Part II makes this concrete: one modern booking intent walked up the ladder, and one twenty-five-year-old claim URL that already knew the integration could be a pointer — not a thick client.

The desired sentence is short enough to fit on a lock screen:

"Keep me booked into suitable pickleball."

The current product experience is not. Open the app. Survive "things near me" as if the software has amnesia about where you live. Filter past sports you have never booked. Squint at lists that mix events you already joined, events you can join, and events that are closed — often with a tiny icon doing too much semantic work. Somewhere in that slurry is Wednesday beginner at the club you actually use. Hit refresh again in three days when the next horizon opens.

I want to play pickleball, not refresh the app.

That line is not a rant about one vendor. It is the diagnostic for any service that confuses its domain model with the customer's intent. The app ontology is sports, groups, sessions, memberships. The customer ontology is: I regularly want this kind of session, subject to my life. Those are not the same thing. AI that only makes the domain model easier to navigate is still answering the wrong job.

Walk the same service up the ladder

V1 — Help me find the button

Chatbot: "How do I book?" Answer: a link into search and a paragraph about membership. Human still performs inventory reconciliation. AI reduced support tickets. It did not close the world loop on durable intent.

V2 — Talk to our agent inside our walls

In-app agent understands "Sunday beginner pickleball" and returns a cleaner shortlist. You still opened the product. You still re-stated location and sport the product already knew from twelve prior bookings. Context dies when you close the session. Next week you re-express the same life.

V3 — Our AI books for you (here)

Now the in-app agent can complete a booking after confirmation, charge the card on file, and email a receipt. For that Wednesday, it feels like magic. For the longitudinal pattern — Sunday and Wednesday, beginner-ish, no calendar conflicts, don't double-book, watch the release horizon — the product is still a goldfish. It treated six bookings as six independent commands:

BOOK
BOOK
BOOK
BOOK
BOOK
BOOK

…when the evidence was one intent:

"I regularly want this kind of pickleball."

Worse: the app AI cannot honestly see the rest of life without becoming a second operating system. Work dinner appears on the calendar the booking vendor does not read. Flight gets moved. The personal agent could know. The in-app agent would need you to build a creepy universal profile inside every SaaS you touch.

V4 — My agent keeps me booked

The personal agent already holds the pattern, the authorisation, and the attention. The booking service exposes enough surface that the agent can read current bookings, discover eligible sessions, act within policy, and learn when inventory opens. The human's notification is an outcome, not a to-do:

✓ Pickleball booked Wednesday 7pm
  Next Sunday 10am already booked
  Nothing else to do

There is no product UI in that happy path. The service still ran capacity, membership, payment, and cancellation policy. Its human interface became invisible for the routine loop. That is V4. That is agent addressability applied to one boring, valuable intention.

What this chapter asks of the service (only)

We are not designing the personal agent here. We are listing what the business must make true for V4 to be possible at all:

• machine-readable bookings and availability for this member,
• book / cancel / waitlist actions with clear policy,
• a grant the user can hand their agent (scope, spend, duration, revoke),
• a way to learn when sessions open without human refresh labour.

If those are missing, your AI roadmap can be full of V2 stickies and still leave the customer saying: I want the outcome, not your navigation. The next chapter shows this is not a 2026 fashion. Twenty-five years ago, the same instinct shipped as a claim-scoped URL into someone else's system — because forcing outsiders into your operational software was already the wrong integration.

Agent addressability sounds like a protocol-era invention. It is not. The product move — give an external party a scoped pointer into exactly what they need, without dragging them into your operational thicket — shipped in the early web period under much worse connectivity and much less hype.

Freemans: the right system for the field, the wrong system for outsiders

Freemans Australia, at the time of this work, was an insurance loss-adjusting firm with offices around the country and a few hundred staff. When disasters hit — floods and the rest — adjusters did not sit in a perfect data centre. They worked out of temporary setups, took notebooks to sites, and needed to establish claims, reserves, and paperwork without reliable infrastructure.

The operational answer was a Lotus Notes application that worked in the office and on notebooks. Field work happened offline. When connectivity returned — hotel dial-up, early wireless, whatever the decade offered — the databases replicated. Reserves that once lagged a week or two in Word-document email chains could be worked much faster once the system was live. Notes earned its place: intermittent connection, replication, and a real operational store for people who lived in the mess.

Then the clients arrived. Insurers wanted access. They wanted to see their claims. The naïve answers write themselves if you have ever sat in an enterprise integration meeting: deploy a Notes client to the insurer; federate identity; train external staff on your internal tool; provision accounts; start an EDI megaproject. All of that treats the operational system as sacred and forces the outside world to become you.

The move: one URL per claim

The better answer was smaller and ruder in its simplicity. For each claim, generate a URL. Put a code in it — signing smarts in the link, conceptually close to what the industry later normalised as signed or capability URLs (this was before S3 made signed URLs a household pattern among builders). When a claim was set up, the system emailed that URL to the insurer. The insurer put the URL into their system. Whenever they needed status, they used the pointer. What they got was a projection of exactly one claim — not a login to the entire adjuster world.

claim created
      ↓
opaque / signed-ish URL generated
      ↓
URL emailed to insurer
      ↓
insurer stores URL in its own system
      ↓
fetch
      ↓
read-only projection of exactly one claim

The URL was the integration.

Not "deploy our client." Not "become a Notes shop." Not "wait for the EDI programme." A durable pointer to the thing the other party actually cared about, with scope baked into the capability of the link.

Serving layers change; the instinct does not

Notes was a beautiful replicated operational store and a poor public web serving layer for the new workload. Projection machinery moved data toward environments that could serve external readers efficiently. That is a normal architectural story: when the next computational environment cannot efficiently operate where the data lives, you stage a better surface. The load-bearing idea for this ebook is not the replication saga. It is the boundary decision:

Same instinct under different economics. You do not hand the outsider your operational system of record as a lifestyle. You hand them a scoped capability to the outcome they are entitled to see or act on.

Why this belongs in an agent-addressability ebook

Copy-a-URL delegation in Chapter 7 is not a TikTok-era gimmick. It is Freemans productised for a new consumer: the user's agent instead of the insurer's claims system. The artefact changes (keyed agent connection, protocol discovery, OAuth scopes). The doctrine does not: integration can be a pointer stored in the other party's world.

When a product team says agent access requires a twelve-month partner platform programme before any user can connect anything, remember the claim URL. Sometimes the first correct external surface is embarrassingly small — and that is why it works.

If this ebook leaves one artefact on your whiteboard, make it this checklist. Chapter 3 introduced the contrast with pixels. Here we make it operational: product questions you can take to an engineering planning session without inventing a new religion.

1. State

What can the agent read about the user and the world you manage?

Bookings, eligibility, inventory windows, claim status, balances, membership tier, constraints that affect whether an action is even possible. State must be machine-legible — structured fields, not a PDF of a screen or a marketing paragraph. If the agent needs to know "already booked Wednesday," that fact must be a first-class read, not something inferred from a half-pixel icon in a list view.

Product questions: What is the minimum state for one durable customer intent? What must never leak beyond the grant? How fresh is "current"?

2. Actions

What verbs exist, and when are they legal?

Book, cancel, join waitlist, update preference, pay, message, approve. Each action needs preconditions: is this session bookable now? Is the member eligible? Is the claim still open? Agents are terrible at guessing which greyed-out button was decorative and which was policy.

Product questions: Which verbs cover the primary intent end-to-end? Which are deliberately human-only? Are preconditions explicit in the API, or only in UI disabled states?

3. Delegated authority

Who is the agent acting for, how far, and for how long?

This is the element most "we have an API" stories skip. Without delegated authority you have a password shared into a chatbot — an industry failure mode, not a product. Authority needs: principal (the human), scope (pickleball only, this organisation, this claim), monetary limits, cancel rights, duration, and a revoke path the human understands.

Product questions: Can a user mint a grant without calling sales? Can they revoke it in one place? Can you explain the grant in one screen of plain language?

4. Consequences

What happens if the action runs — including when it fails or runs twice?

Fees, penalties, confirmation rules, refund windows, partial success. Idempotency: does a retried book create two reservations or one? Agents will retry. Networks will glitch. If consequences live only in a terms-of-service essay, you have not built a delegation surface; you have built a liability trap.

Product questions: Is every side effect structured in the response? Can the agent preview cost before commit? What does "success" mean in a typed result?

5. Subscribe-to-changes

How does the agent learn the world moved without the human opening the app?

Session openings, cancellations, claim status flips, waitlist promotions. Webhooks, event streams, or a documented poll contract with honest rate limits — pick a real mechanism. "User gets a push notification and opens us" is a human subscription model. It is not an agent subscription model.

Product questions: Which state transitions matter for the durable intents you care about? Can a grant include event types? What is the latency budget?

Worked grant: one booking intent

Scott grants agent:
  read my bookings
  read suitable available sessions
  book sessions
  join waitlists
  cancel within policy
  use authorised payment method

scope:
  pickleball only
  this organisation
  max $X per session

duration:
  until revoked

That block is not a full security architecture. It is the product shape of delegated authority plus the actions and state the agent will need. Implementation can sit on OAuth scopes, capability tokens, or whatever your platform standardises — the point is that users can issue something like this without a partner integration programme.

How to score yourself

Give each element 0 (absent), 1 (partial / internal only), or 2 (customer-grantable, documented, production). A product that scores 10 is rare. A product that scores 2–4 on state and actions and 0 on authority and subscribe is normal — and not V4-ready. Be honest in the room. Honesty is cheaper than another in-app copilot that cannot be reached from outside.

Use the score in roadmap language. "Raise subscribe-to-changes from 0 to 2 for the booking domain" is a shippable programme. "Become AI-native" is not. The checklist also prevents a common self-deception: shipping a public OpenAPI document for partners and telling the board you are agent-ready. Partners are not personal agents. Organisation automation is not a user-minted grant with revoke. If the customer cannot hand their agent a scoped connection without sales engineering, you have not finished the product job this ebook describes.

Chapter 5's claim URL worked because the insurer could store a pointer in their world. Chapter 6 listed what a modern grant must mean. Now the product moment: how does a normal user connect their agent without filing a partner ticket?

The flow that should exist

Profile / Security
────────────────────────
Connect your AI agent

[ COPY AGENT CONNECTION ]

        ↓ paste into personal agent

Agent fetches the URL once:

  • who it is acting for
  • allowed operations
  • how to call the surface
  • scoped authorisation material
  • (optionally) human-readable agent instructions

        ↓

User states durable intent in *their* agent
Agent operates within the grant

That is the shape. Conceptually it is an API key, an API description, and onboarding instructions for a non-human client — bundled so the user performs one gesture. Production systems will use better cryptography than a naïve long secret in a query string. The product concept remains: one artefact the user can hand to their agent.

Sort of like an API key and an API and instructions all in one.

Why this is good product, not a hackathon joke

Low ceremony beats "email sales for API access." The user already understands copy-paste. The agent already understands "open this URL and learn." You meet both where they are. You also force your own organisation to answer Chapter 6's checklist: if the first fetch cannot describe state, actions, and authority, you do not have a connection — you have a dead link.

Compare the alternatives that currently pass for strategy:

• Undocumented scraping tolerance — brittle, often ToS-hostile, not a contract.
• Shared human passwords into agents — audit nightmare; actions look like the human in logs.¹
• Partner-only APIs — fine for B2B; useless for a consumer handing a grant to their personal agent on a Tuesday night.

Standards are building the plumbing

You do not have to invent the entire universe from a blog post. Two protocol families already sketch pieces of the "one connection artefact" intuition.

MCP: act on behalf of a resource owner

The Model Context Protocol's authorization specification is explicit: MCP clients make protected requests to MCP servers on behalf of a resource owner. A protected MCP server acts as an OAuth 2.1 resource server; the client is an OAuth client; discovery of the authorization server uses protected resource metadata and well-known URLs.²

That is not a sports-booking UX. It is the transport-level admission that agents need delegated access with discovery, scopes, and standard token handling — not a forever-anonymous pipe into your tools.

A2A: Agent Cards at a well-known URL

Google's Agent2Agent (A2A) protocol, announced with a large partner coalition, lets agents advertise capabilities via an Agent Card — a JSON document describing skills, endpoints, and authentication requirements. Discovery is designed around a well-known URL pattern (commonly discussed as /.well-known/agent.json), comparable to an OpenAPI document for agents.³⁴

A2A is positioned as complementary to MCP: MCP for tools and context, A2A for agent-to-agent collaboration. For product leaders, the combined lesson is simpler: the industry is standardising "fetch a URL, learn how to talk, authenticate properly." Your copy-connection button is the human-facing on-ramp onto that kind of world.

Security is real — and not a reason to ship nothing

A raw secret in a URL is not your final architecture. Tokens expire. Scopes minimise. Audience binding matters. Revocation must work when a phone is lost. Those are engineering requirements, not objections to the product category. Freemans' claim URL was also "not perfect security by 2026 standards." It was the right integration shape for the problem. Ship the shape; harden the implementation; do not wait for metaphysical safety before the first grantable pilot on a low-risk scope.

A practical pilot is deliberately boring: one domain (for example bookings only), read plus a small action set, hard spend ceiling, short default TTL, loud revoke in the profile UI, and audit logs that name the agent grant rather than impersonating the human. That pilot teaches your organisation more than another quarter of chatbot A/B tests. It also surfaces the political question early: are you willing to be operated without owning the attention? If the answer is no, say so — and stop calling in-app AI a complete strategy.

None of this says "delete the design team." Humans will still discover you, evaluate trust, recover from edge cases, and enjoy well-made moments. What changes is the economics of the routine. Durable intent does not deserve a weekly tax of navigation. The party that absorbs that tax — the personal agent — becomes the high-frequency customer of your service surface. Your human UI becomes the showroom and the exception desk. Your delegation surface becomes the loading dock. Teams that keep measuring success only as human session length will optimise for the wrong customer just as the valuable one stops needing sessions at all.

When the agent is the customer, UI polish stops being a moat.

Where competition moves

For a long time, product competition in consumer software was a fight over attention: who reduced friction enough that humans completed the funnel, who won the home-screen slot, who trained notifications without being deleted. Those fights do not vanish. They are joined by a new one: who is reliably operable under a scoped grant with clear consequences and honest change feeds.

A competitor does not always need to rebuild your entire inventory system on day one. They need to be the service a trusted agent prefers to call — or the wrapper that can call you when you refuse to be called cleanly. Addressability is not only defence. It is distribution into a world where the agent chooses actuators.

Vendors stuck on V2 will keep shipping prettier copilots. That work is visible in demos and safe in budget meetings. V4-ready competitors will look quieter in the app store screenshots and more inevitable in the agent's tool list.

What to do Monday

What we deliberately left on the table

Three adjacent problems are real and not this ebook:

• What the personal agent does with the connection — intent custody, scheduling, multi-service planning — is a separate product conversation.
• Friction economics of incumbents — how attention tax becomes a market for intermediaries — is a separate strategic conversation.
• Provenance and runtime authority infrastructure — proving who authorised what, in-path gates, attestation — lives with the Agent Provenance Stack and Decision Authority Infrastructure. For a public window into the provenance problem, see the related LeverageAI piece on agents and provenance.

This piece owns the service-side product question only: ladder, delegation surface, copy-a-URL connection, and the twenty-five-year proof that scoped pointers already worked.

Keep the artefacts portable. When someone proposes "an AI strategy offsite," bring three pages: the V1–V4 table with every initiative labeled, the five-element score for one flagship intent, and a wire of the Copy agent connection screen. Those three objects end philosophical fog faster than another slide about models. They also make scope honest — you can point at what belongs in personal-agent design, friction economics, or provenance engineering without pretending this product surface solves all three.

The question to put on the board

Stop only asking where AI goes in the app. That question produces chatbots. Ask the question that produces addressability:

Why is the user's AI unable to use our business?

If you can answer with a grant, a surface, and a change feed — you are building for the customers who will not open you every time. If you can only answer with another in-app agent — you know which rung you are on, and how far the climb still is.