Picture the product offsite. Under the AI column the stickies write themselves: chatbot for support, smart search, copilot in checkout, a little agent that helps users find events. Every idea assumes the same geometry. The human still enters your world. Your AI still sits inside your attention machine. That is not stupid. It is one generation behind the threat.

Why can’t my AI use your business?

For fifteen years consumer software trained itself to own attention: download, login, notify, navigate, convert. AI arrived and product managers did the rational thing — they put intelligence where the attention already was. The agent world reverses the centre of gravity. Durable intent lives with the user. A personal agent holds authorisation and attention. Services become actuators, not attention prisons.

OLD: USER ATTENTION → APP
NEW: USER INTENT → PERSONAL AGENT → APP/SERVICE

Agent addressability is the service-side question: 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 different from “add AI.” It is different from “our mobile app has a backend API.” The app is still your client. The personal agent is the customer’s client.

The V1–V4 ladder

Not every “AI feature” is the same generation. Use this ladder before you fund the next sticky.

Most vendors build V2. The threat is V4.

V1 is a help bubble that links you into search. V2 is a real conversational surface inside the logged-in app — better concierge, same hotel. V3 lets the in-app agent book or cancel for you inside product context; impressive, still app-centric, still unable to hold a full human life without building a creepy second operating system of Scott inside every SaaS. V4 is the discontinuity: the personal agent holds longitudinal intent; the service exposes a machine surface; the happy path needs no product UI.

Human: "Keep me booked into suitable pickleball."
        → personal agent (calendar, pattern, payment grant)
        → service (inventory, rules, payment rails)
Human sees: ✓ Wednesday 7pm booked

The service still does membership, capacity, and policy. Its human interface becomes invisible for the routine loop. The longitudinal model of the person should sit with the person — not be poorly reconstructed as six partial Scotts across six vendors.

Pixels are not a delegation surface

Human UI is pixels, navigation, and interaction. An agent needs something else:

• State — what is true now
• Actions — what can be done
• Delegated authority — who, how far, how long, revoke
• Consequences — fees, failures, idempotency
• Subscribe-to-changes — when the world moves

Shipping LLMs onto the left column does not create the right column. “We have an API” usually means the app and maybe partners can talk machine. It rarely means a customer can mint a grant so their agent may book pickleball up to $X until revoked and learn when Wednesday opens. Technically automatable is not agent-addressable. RPA that clicks your UI is a failure mode, not a product strategy.

Keep me booked

The desired sentence is short: keep me booked into suitable pickleball. The current experience is not: open app, survive “things near me,” filter sports you never play, interpret tiny icons for already-booked versus closed, refresh again when the horizon opens.

I want to play pickleball, not refresh the app.

Walk the same service up the ladder. V1 answers “how do I book?” with a link. V2 finds Sunday beginner faster inside the walls. V3 books one Wednesday after confirmation — then next week starts over, treating six bookings as six commands when the evidence was one durable intent. V4 lets the personal agent complete the loop under a grant. If V4 is impossible on your product today, that is a product gap, not a user failure.

The URL was the integration (twenty-five years ago)

This is not a protocol-era invention. In the early 2000s, Freemans Australia ran insurance loss adjusting with Lotus Notes for intermittently connected field adjusters — the right operational system for disaster sites, the wrong system to hand to insurers. The integration was not Notes clients, federation, or EDI megaprojects. It was a claim-scoped signed-ish URL (pre-S3 signing) emailed into the insurer’s own system: a durable pointer to exactly one claim.

The URL was the integration.

Same instinct now: external agents need scoped operability without your human UI, just as external parties needed scoped visibility without your thick client.

Copy agent connection

Product moment next to Share and Export:

Profile → [Copy agent connection]
        → paste into personal agent
        → first fetch: capabilities + instructions + scoped auth
        → agent operates within grant

Conceptually: API key + API surface + agent instructions in one artefact. Production needs real token hygiene; the product shape still stands. Refuse password-sharing into agents (actions become indistinguishable from the human in audit logs)¹ and refuse scrape-as-API as a strategy.

Standards are catching the intuition. MCP authorization models clients making protected requests on behalf of a resource owner, with OAuth resource-server semantics and metadata discovery.² Google’s A2A protocol uses Agent Cards — JSON capability manifests, often at a well-known URL such as /.well-known/agent.json — and positions itself as complementary to MCP.³⁴ Protocols supply plumbing. They do not decide who holds durable intent. They do not replace provenance and runtime authority design — that is a sibling problem.

When the agent is the customer

UI craft still matters for discovery, trust, and exceptions. Routine transactions migrate to authorised agents. Competition shifts from who owns the home-screen slot to who is reliably operable under a scoped grant with clear consequences and honest change feeds.

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

This article owns the service-side product question only. What the personal agent does with the connection, friction-arbitrage economics, and cryptographic provenance internals are separate conversations. Stop only asking where AI goes in the app. Ask whether the user’s AI can use your business — and if not, build the surface that makes the answer yes.