Stage 1 — Discover / Find
A single OEM tenant already owns the surfaces where vehicle discovery happens: a public brand website with a build-and-price configurator and dealer inventory search, an OEM-branded mobile app, and a dealer network that is the actual point of sale. AVX’s role at this stage is not to build a new discovery channel — it is to embed a conversational sales agent directly into the surfaces the OEM already operates, and to recognize that Discover has three structurally different entry paths with different identity preconditions and, for fleet buyers, a different channel entirely.
Path A — Anonymous / new-prospect Discover
A visitor with no existing relationship to the OEM lands on the OEM’s public website or app and starts a conversation with the embedded sales agent.
Channel: embedded directly in the OEM’s own website and app. The agent is invoked client-side from the OEM’s website or app via API Gateway, with Amazon Cognito used only for optional sign-in rather than as a session precondition. Voice, when offered, is Nova 2 Sonic invoked directly from the browser or app’s microphone through the same API Gateway path — an interaction modality embedded in the site itself. The agent’s framing is closer to a knowledgeable dealership salesperson standing at the configurator than to a Service-stage triage bot: it answers feature, tow-capacity, pricing, and lease-offer questions conversationally.
Identity: none required to start. An ephemeral session identifier is created at first interaction — no Cognito authentication precondition. AgentCore Memory holds this as short-term, session-scoped state only: stated preferences, viewed configurations, current-turn context. There is no persona to hydrate from LTM at session start, because for an anonymous visitor no persona record exists yet.
AgentCore Runtime dispatches per-turn tools.
The same AgentCore Runtime described in Agentic Architecture dispatches catalog_query() and, when the utterance is offer-aware, offers_lookup() on every turn — both scoped to the OEM’s own inventory and incentive data, not delegated to a third-party commerce platform.
For a single-OEM deployment, the OEM’s own website is the commerce system of record; there is no separate digital-commerce partner to delegate catalog ownership to.
Identity promotion — the entity-resolution boundary.
If the visitor saves a configuration, requests a callback, or authenticates, the ephemeral session is linked, not looked up — a deliberate write, not an automatic resolution.
The join key is contact information (email or phone) captured at the moment of linking, or a Cognito sub if the visitor authenticates into an existing or new OEM account.
That link produces a structured lead/reservation record — contact info, saved configuration, dealer of choice if selected, and an OEM-issued lead ID — written to the OEM’s own CRM / lead-management system, which is the OEM’s existing infrastructure, not new AVX infrastructure.
AVX does not write directly into a dealer’s DMS: DMS systems (Reynolds, CDK Global, Tekion, Dealertrack) are dealer-owned and per-vendor, the same per-tenant, per-DMS setup that DMS booking in the Service stage needs.
The OEM’s CRM already has the dealer-routing logic and per-DMS-vendor integrations built; AVX’s integration surface is the one system it can reasonably own talking to — the OEM’s CRM — not the fan-out to N dealer DMS vendors.
Handoff shape: a warm lead.
The lead/reservation record is a structured, asynchronously consumed record — the same shape as the Service stage’s book() STAR-JSON pattern. A licensed advisor picks it up from the OEM’s CRM on their own timeline; the customer receives a confirmation and, if they requested a callback, hears from a dealer directly.
Path B — Existing-owner re-engagement
A current OEM owner, already known to AVX through the LTM established at Onboard, receives a proactively pushed lease-maturity or upgrade offer and enters a new Discover cycle from a warm start.
Channel: push notification into the OEM’s existing app. The owner already has the app from onboarding; no new channel is needed.
Identity: already resolved. This is the same OEM-owner persona from Personas and Tenancy, re-entering a different journey stage — not a new persona category and not a new identity-resolution problem.
Trigger: the same proactive-engagement pipeline Onboard / Own already uses. A business-rule event — lease-maturity date, mileage threshold suggesting trade-in value, new-model-year launch matching the owner’s trim history — is evaluated through the same CMS Flink → MSK → threshold-evaluation → push pipeline described in Stage 3 — Onboard / Own, with a different rule set and a different offer source (dealer/OEM incentive data rather than maintenance/recall content). This reuse is deliberate and correct: the precondition that makes Onboard’s proactive pattern work — an existing owner with LTM already hydrated — is genuinely satisfied here, unlike Path A’s anonymous visitor.
What follows is Discover-shaped, from a warm start.
Once the pushed offer opens a conversation, the tool catalog is the same as Path A — catalog_query(), offers_lookup() — but the session bootstrap is completely different: warm, LTM-hydrated, persona-and-vehicle-history-known, versus Path A’s cold, session-only, anonymous start.
Path C — Fleet / B2B sourcing
A fleet sourcing manager evaluating vehicles for a commercial fleet is a structurally different buyer than Path A’s retail visitor, and does not enter through the same consumer configurator surface. Fleet purchasing is a B2B motion: named account relationships, RFQ-style volume-pricing requests, multi-vehicle order quantities, and (commonly) an existing fleet account manager at the OEM or a fleet-focused dealer group — not an anonymous website visit.
Channel: an OEM fleet-sales portal or a named account manager’s own tools, not the retail configurator. Large OEMs of any real scale already operate a fleet-sales function — a dedicated fleet portal, a named account-manager relationship, or both — entirely separate from the consumer-facing website Path A embeds into. The AVX agent’s role here, if any, is to assist an already-identified fleet account (authenticated via a business Cognito pool or federated from the OEM’s existing fleet-sales identity system) with catalog and offer questions scoped to fleet pricing and volume-order inventory — not to serve as the fleet’s initial discovery surface, which the OEM’s existing fleet-sales relationship already owns.
Identity: a business account, not anonymous.
Unlike Path A, a Path C session starts from an already-resolved business/fleet identity — the fleet sourcing manager is a known account, not a first-time anonymous visitor.
Persona resolution here is the existing fleet_driver/fleet-operator persona machinery this IG already defines elsewhere (Personas and Tenancy), applied to a sourcing conversation rather than an operations conversation — not a new identity problem, but also not Path A’s anonymous-session model.
Data and tools: the same catalog/offers surface, scoped differently.
catalog_query() and offers_lookup() are the same tools Path A and Path B use, filtered by the fleet’s negotiated pricing tier and available fleet-inventory pool rather than retail inventory — the tool catalog does not change; the identity precondition and the pricing/inventory scope do.
What comes next. A fleet RFQ that converts to a purchase enters Acquire / Finance the same way Path B does — from an already-established identity, with fleet-specific finance terms (master lease agreements, fleet financing programs) rather than individual consumer financing. Path C’s Acquire-stage financing needs are materially different from an individual retail buyer’s (see Stage 2 — Acquire / Finance) and are called out there rather than assumed to be the same flow with a different label.
What comes next (any path). Once the customer converges on a specific vehicle and initiates a transaction, the session transitions into the Acquire / Finance stage. For Path A, the bridge across that transition is the lead/reservation record’s contact info and OEM lead ID — not an AVX-native identity, since none exists yet. For Path B, the bridge is the already-established Cognito identity and LTM persona snapshot. For Path C, the bridge is the fleet account’s existing business identity, carrying an RFQ or negotiated-quote reference rather than an individual lead ID.
Data wiring. Connect the agent to two ADP data products via the cross-account Lake Formation grant pattern described in Building on CMS and ADP:
-
ADP Vehicle Identity Graph — provides year/make/model/trim attributes, powertrain and feature flags, and certified-pre-owned status that the agent uses to answer feature-matching questions. Sourced from the OEM’s own dealer DMS inventory feeds (CDK Global, Reynolds, Tekion, Dealertrack, Fleetio).
-
ADP Campaigns/Offers — provides the OEM’s own curated offers (lease rates, incentive packages) that the agent surfaces in response to price or availability questions.
Agent tools to implement.
At minimum, implement a catalog_query() tool that accepts natural-language vehicle criteria (body style, tow capacity, fuel type, target MSRP range) and returns a ranked list of matching inventory or models from the OEM’s own ADP-sourced data.
For offer-aware responses, a companion offers_lookup() tool queries the Campaigns/Offers product.
Add a lead_capture() tool that performs the identity-promotion write described above — session-to-lead linking, contact-info capture, and the write to the OEM’s CRM/lead-management system.
Persona inference. Path A is a retail/individual-buyer channel — there is no persona to infer at session start, since the visitor has no identity claim yet, but the segment itself is retail by construction: nobody reaches a public configurator-and-inventory-search widget as a fleet sourcing manager submitting an RFQ. A rental operator’s individual customer choosing an upgrade fits Path A the same way a retail buyer does — both are individual consumers browsing a consumer surface. For Path B, persona inference is already complete — it is the existing OEM-owner resolution from Onboard. Fleet buying is a structurally different B2B motion and does not enter through Path A at all — see Path C below.
Entity resolution across the AVX-to-dealer boundary.
The join key that survives the boundary between AVX’s identity space (Cognito sub, ephemeral session ID) and the dealer’s identity space (DMS customer record) is contact information plus an OEM-issued lead ID — not a single canonical identity in the agent layer, because the two systems only agree on contact info and a lead reference until a sale closes.
Once VehicleOwnershipTransfer fires at Acquire completion (see Stage 2 — Acquire / Finance), the resolve_or_create_owner_identity() tool resolves or provisions a VIN-linked Cognito identity from the lead record’s contact info, and the customer’s onward relationship becomes Onboard / Own’s familiar LTM-hydrated model.
Scope. Discover is a catalog-and-offers query surface plus lead capture, not a full configure-price-quote (CPQ) workflow. Personalized recommendation ranking, purchase-intent scoring, and configuration-and-order flows build on the same tools.
|
Building blocks |
Tools |
