Website/app integration and economics

Where the personas belong

The persona should help someone at a moment of curiosity, uncertainty or decision. Use an optional contextual invitation, text as well as voice, and explicit microphone activation. Avoid autoplay, obstructing checkout or replacing useful existing controls.

Guinness

The brand website organises beer, craft, experiences and sport. The Storehouse website has ticket purchase and visitor help. Its iPhone App Store listing describes ticket access, maps and audio guides. These are published capabilities, not an observed app walkthrough; the listing names Captains Conquest as developer and describes itself as official. Confirm brand approval and integration ownership before a pilot. No Android or global consumer-app availability is established here. The separate Guinness Nigeria retail app serves trade ordering and is a different scope.

Recommended first pilot: Storehouse visit planning. Place “Ask Guinness” beside experience selection and visitor FAQs. Someone asks, “I've an afternoon in Dublin—what would you show me?” The host asks about their time and interests, explains approved options and sends them to the existing booking journey. Value: less uncertainty and a warmer introduction. Measure task completion, useful handoffs and booking conversion against a comparable control, rather than assuming longer conversations are better.

In the Storehouse app, add an optional host beside an exhibit or map point. Pass an exhibit identifier so it knows what the visitor is looking at. Let the person ask follow-up questions about an advertisement or brewing history. Value: an interactive extension to the published audio-guide journey. Use text/headphones and accessible alternatives. Location access is optional; select an exhibit manually instead.

The GB Pub Finder distinguishes Draught and 0.0 availability. A host could ask for postcode and preference, then return approved results. A venue serving Guinness is not evidence that it shows a particular match or has current stock: those require a fresh venue feed. Sport and advertising pages can invite conversation about a specific story without demanding a purchase. Preserve market/age controls and approved responsible-drinking boundaries. Booking availability and accessibility arrangements need authoritative information; unresolved questions go to staff.

Nike

The Nike App page presents shopping, personalised recommendations and stories. Run Club describes run tracking, plans and audio-guided runs. Training Club presents workouts and coaching content. SNKRS combines releases and sneaker stories. These public pages were read, rather than the installed apps. Nike page text also includes “Ask NikeAI”; we have not tested its availability or capability. Do not pitch Nike as having no conversational offering.

Recommended first pilot: an athlete, campaign or shoe-heritage story, reached from Nike's editorial website or SNKRS. A visitor asks why a particular athlete or design matters; the persona connects sourced sporting history, an authored point of view and the product's documented story. It then offers a relevant article or product link. Value: turn passive content into a distinctive encounter. Measure useful answers, factual accuracy and voluntary next actions. This is a clearer demonstration of our cultural expertise than duplicating generic product search.

Second placement: beside running-shoe selection on the website or shopping app. Ask about intended use, terrain and preferences; explain a short comparison and link to products. Current regional catalogue, prices, size availability and policies must come from Nike-approved systems, not historical research or guessed stock. Test decision confidence and downstream outcomes.

In NRC, start with a short pre-run conversation that selects an existing approved guided run, or a post-run reflection. Run summaries require explicit user permission and a brand integration; MCP does not grant account access. In NTC, help find an existing session that fits available time and equipment. Maintain the scope of approved coaching; injury symptoms must not become personalised diagnosis or pressure to continue. Do not interrupt existing coaches with continuous generated commentary. Measure chosen-session starts, usefulness and opt-in return use. Add ongoing live coaching only after dedicated testing.

The logistics in plain English

Nike running companion — additional direction

The user proposes a conversational running companion inspired by Steve Prefontaine: spoken pacing updates, interpretation of permitted run data, encouragement and user-selected power songs. Preserve this as a product concept, not an existing Nike feature or an authorised recreation of Prefontaine. A named historical-person likeness/voice concept requires a separate rights and brand-approval process; begin with an original Nike character inspired by researched running values rather than claiming to reproduce his voice.

Example fictional interaction using hypothetical sensor data: runner says “How am I doing? Play my power song.” The app calculates pace against the selected target, the persona gives a brief accurate response, and an authorised music action starts the user's chosen track. Sensor calculations and music controls are tools, not facts invented by the language model. Missing/stale data must be acknowledged. Let users choose coaching frequency; test interruption, music ducking/restoration, wind, Bluetooth, app foreground/background behaviour and disconnected operation. Avoid continuous cloud speech streaming by default: short active exchanges and locally calculated cues are an initial cost/latency hypothesis.

Apple MusicKit provides authorised music access and playback. Spotify playback controls require Spotify Premium for this endpoint, plus appropriate authorisation, platform access and device support. These are integration possibilities, not verified permissions for our product. Run-data access still requires integration with the brand app. A mobile-sized website demonstration cannot prove native pacing/music reliability.

There is one centrally managed persona, reached through several interfaces. The website button or app screen is its face; the hosted service loads its approved identity, knowledge and tools. Sessions are separate. Persistent cross-device memory requires identity, permission and an explicit retention design.

1. Agree the brand, market, tasks, approved sources, permitted actions, retention and budget. Publish an approved persona version.
2. Deploy the service to a production host with isolated brand access. Private hosting does not by itself keep model processing on that server: a hosted voice model still receives audio. Dedicated infrastructure is an option, not a prerequisite for every customer.
3. On a website, the brand's developers install our small interface component or a hosted panel. It passes a public brand identifier plus permitted page/product context. Browser origin checks, secure session authorisation and microphone permissions are required. Embedded panels need explicit microphone permissions and browser testing. Never place a provider API key in the page.
4. In an app, the brand's developers add a native conversation screen or a carefully tested web panel. A production native voice implementation needs audio handling, permissions and lifecycle integration. The app requests an authorised session from the same service. Releases and app review belong to the brand's app team; we cannot insert ourselves into their app remotely.
5. The service validates the customer, loads the approved persona and grants a limited session. It connects the interface to the model, retrieves authorised evidence and controls tools. WebRTC is the current prototype's browser audio transport; mobile integration is still to be built.
6. Read-only product, venue or booking lookups call approved brand APIs, directly or through MCP. Actions such as booking, buying or changing an account need separately authorised tools and user confirmation. Initially return a link to the existing brand transaction flow.
7. Record session usage for billing and permitted performance events. Retain conversation content only under the agreed temporary-retention procedure. Present performance and suggested changes to managers; approval publishes a new version across configured channels.

MCP standardises access to resources and tools in compatible hosts. It is not an audience, app installation mechanism or guarantee that a third-party host will reproduce our full persona. For consistent personality, offer access to our managed conversation service and test each integration. See the official MCP architecture. We have not built this production service or MCP distribution layer.

Who supplies what

The GPT Agency supplies persona configuration, evidence, conversation software, evaluations and the integration interface. The brand supplies deployment permission, developers or an implementation partner, approved data connections and reviewers. The hosting/model providers supply agreed infrastructure and inference. Contracts should specify confidentiality, data uses, subprocessors, retention, ownership/export and cross-brand learning permissions; this is a requirements list, not legal advice or a drafted agreement.

Next three milestones

1. Guinness evaluation v1: a local bounded runner, four evaluator roles, reproducible failures, a human review report and one approved candidate. No unattended paid campaign until its scope and budget are agreed.
2. Embedding proof: put the same Guinness persona into a clearly illustrative local visit-planning page and a mobile-sized interface. Demonstrate contextual help and a booking-link handoff; do not clone or publish an official brand integration.
3. Measurement proof: implement consent-aware temporary text logging, expiry/deletion and session usage measurement, then show performance in a local dashboard. Reconcile voice costs before choosing a customer tariff. Billing infrastructure and payment collection follow measured evidence.

For the preferred subscription plus metered voice model, see the whitepaper. Codex can develop and run the local harness: official CLI documentation. Hosted model evaluations still consume provider usage, and subjective voice quality still requires listening.