Personality first, agentic capabilities beneath it

Working design and integration research · 5 October 2026.

The differentiation

The GPT Agency begins with a personality: researched identity, voice, points of view, imagination and the craft of conversation. Useful capability grows beneath that character. Pre can talk about ambition before someone has any interest in shoes. If a relevant need emerges, he can help them understand options and take an approved action.

This is a deliberate product position. It does not imply that all competitors begin at checkout, or that personality alone proves commercial return. Measure the relationship and its usefulness before claiming lift.

The reusable foundation

Modules are disabled until their required integration and evaluation exist. A source link alone does not make product research live. A purchase module does not inherit authority from a personality setting. Future deployments can enable research without transaction access.

What exists where

The managed character can exist across multiple hosts. Installing a plugin does not automatically import that character as the host’s system persona. Host support, presentation, context, audio and memory need adapter-level testing. MCP provides tool interfaces; it does not independently create users, distribution, account access or payment capability.

A proposed Nike member journey

1. Meet Pre and discuss a goal, a frustrating run or a sporting moment. A sale is optional.
2. If membership is useful, open Nike’s official join/sign-in journey. The user completes Nike’s terms and credentials there. An in-conversation creation flow requires an approved Nike integration; none is assumed.
3. Offer the official NRC download route. The device’s app store handles installation. Return or deep links depend on OS/app support; do not report an installation from a click alone.
4. Invite account connection only when Nike supplies an approved delegated authorisation route. Request the minimum permitted run fields and explain their purpose and retention. Never ask for the member’s Nike password in chat.
5. Discuss selected runs using the returned records. Distinguish a recorded result, the member’s own account and an interpretation. Run summaries need not include precise routes or heart rate. Do not repurpose workout or private conversation data into advertising audiences.
6. When relevant, research shoes using authorised products, size availability, local price and user preferences. Explain why an option fits; acknowledge when it does not.
7. Prepare a basket only through a supported Nike commerce interface. Show the specific item, size, quantity, currency, total, delivery and applicable terms. Use a merchant checkout handoff initially; the user completes purchase on Nike’s domain.
8. An Instagram invitation opens a verified brand-selected profile. The user follows within Instagram. No automatic follow integration or completion tracking is assumed.

Nike publishes membership and NRC journeys. Public pages do not establish a general third-party API for member enrolment, workout access, account linking or shopping baskets. Those require a client agreement, technical discovery and approved access. There is no live Nike integration in the demo.

Purchasing logistics

The client owns the commercial truth: products, eligible regions/customers, stock, price, tax, shipping, returns and order records. Its payment provider owns secure payment processing; raw card details never belong in a persona conversation or CEM log. The agency builds the tool adapter and user experience, configures capability controls, tests failure handling and maintains the integration under an agreed scope. Responsibilities and incident ownership must be contractual.

For the first release, the persona can advise and direct the customer to a product page. If the merchant supports a basket/checkout API, the integration can produce a short-lived checkout link. Nike calculates the final price and executes payment. Record a user-requested handoff separately from a purchase; confirm an order only from an authenticated merchant response or webhook.

For a later transaction module, revalidate inventory and all totals immediately before authorisation. Bind consent to the exact order, account, currency and capability version. If a material detail changes, request new confirmation. Give every order submission an idempotency key; reconcile ambiguous timeouts before any retry. Payment failure must never become a success message. Keep an auditable consent receipt and support the merchant’s order/return flow.

OpenAI’s plugin checkout guidance currently recommends external merchant checkout. It describes saved-payment integrations and a restricted payment-sheet beta, with current approval focused on eligible physical goods. These paths depend on host and merchant approval; the presence of an MCP server is not sufficient. Its separate Agentic Checkout Spec describes merchant REST endpoints and says MCP support is future work. Treat those as distinct interfaces rather than conflating them.

Arthur’s potential alcohol-related gifts and experiences require separate review of regional age/access rules, brand policy and host commerce eligibility. Do not generalise physical-goods guidance into permission to sell alcohol or book experiences inside ChatGPT. An approved informational destination is the initial design boundary.

CEM capability controls

Proposed manager controls: enabled module; catalogue/source allowlist; approved destination domains; permitted operations; market and currency; order value/quantity limits; disclosure rules; connection scopes; approval owner and expiry. Enforcement belongs on the server and merchant adapter, beyond editable model instructions.

Personality settings cannot widen tool permissions. New catalogues, write operations or transaction limits require human approval and a versioned release. A manager may disable a capability immediately; rollback must revoke execution even if an old conversation continues. Member authorisation remains separate from advertiser account access.

Current CEM is a draft/review prototype. These capability controls are proposed; they do not enable real commerce, membership or social actions today.

The Gauntlet applied to action

Evaluate both individual tools and whole conversations. Keep regressions for every confirmed failure. Block the affected module until repair and human approval; a personality may continue in a non-commercial mode. Judge whether the recommendation helped the person, not only whether it produced a click.

Commercial model and rollout

Build, integration, management and CEM fees remain. Voice and underlying infrastructure costs remain explicit. The founder-approved persona CPC is the verified outbound handoff from a Sponsored Agent thread, conditional on supported event export. A completed order is a separate event; no new agency commission or fee for embedded checkout has been agreed. Do not imply that every membership, app-download or social link is billable.

Sequence: approved links and research sources; then authoritative product comparisons; then a merchant-supported basket and checkout handoff; later account-linked services and confirmed transactions where approved. Each step needs a client integration scope, budget, Gauntlet results and release owner.

Sources and assumptions

• OpenAI plugin architecture: skills, MCP and optional UI; host capabilities remain distinct.
• OpenAI plugin authentication: authentication and resource access; does not establish Nike access.
• Plugin checkout guidance: external checkout, saved methods and limited payment-sheet access.
• Agentic Checkout Spec: separate merchant endpoint contract.
• Nike Membership: current official membership journey.
• Nike Run Club: official app and download journey.

Reviewed 5 October 2026. Integration ownership, capability controls and the Nike journey are proposed designs. No client agreement, general Nike API permission, plugin publication, commerce certification or live purchasing implementation is claimed.