Forward-deployed marketer. From strategy to working systems.

What a useful handover can look like

Illustrative examples, not client deliverables or results. Actual scope and outputs are agreed for each engagement.

Measurement map

1. Paid-search visit
2. Confirmed demo request
3. Qualified CRM opportunity

Example window: 30 days. Define each handoff owner and check missing sources before comparing channels.

AI-assisted workflow

1. Approved campaign brief
2. Draft with evidence flags
3. Human accepts or returns

A person reviews the evidence and approves any use; the workflow does not publish or change spend.

Decision & experiment

1. Hypothesis: checkout friction
2. Test one payment-step change
3. Compare completion & margin

Record the hypothesis, owner, success measure and the evidence that would change the decision.

What does an AI-native marketer actually do?

An AI-native marketer builds AI into a defined marketing workflow and checks whether it improves the work. In my practice, that means connecting approved source material, frontier models, APIs, analytics and CRM systems to a clear business decision. The deliverable is a usable workflow with an owner, evidence and a fallback—not simply more generated content.

Forward-deployed describes how I deliver that work: embedded with your team, close to the actual data and systems, from diagnosis through implementation and handover. A growth lead owns cross-functional priorities and the learning cadence; a fractional CMO provides senior marketing direction. We agree which responsibilities you need rather than treating the titles as interchangeable.

• GEO and LLM visibility: separate mentions, retrieved pages, citations, visits and genuine enquiries before deciding what to improve.
• Agent workflows: specify permitted actions, human approval, evaluation examples, failed-write recovery and monitoring before connecting production systems.
• Commercial measurement: compare quality, reviewer effort, cost and downstream outcomes with the existing process. Faster generation alone is not proof of growth.
• Use the AI marketing agent evaluation scorecard
• Inspect the lead-agent and CRM handoff workflow
• Review my growth lead experience
• Compare fractional CMO responsibilities

Strategy that stays for the implementation.

I have delivered and am actively working across GEO, LLM visibility, analytics and monitoring, frontier-model integrations, APIs and agent workflows. My role is to connect those capabilities to a business decision, a usable implementation and an accountable owner.

For startups, B2B teams, ecommerce and retail businesses, forward-deployed means working close to the actual stack and customer journey. I help define the problem, build the agreed intervention, evaluate it and leave your team able to operate it. It is not a promise of unrestricted autonomous marketing.

• Fractional CMO: leadership, positioning, priorities and cross-functional direction.
• Forward-deployed marketer: strategic context plus hands-on systems, integrations, evaluations and delivery.
• AI workflow sprint: one bounded workflow. Forward-deployed support: a connected operating problem with an explicitly agreed delivery remit.
• Compare Fractional CMO support
• Explore a single-workflow sprint

What can we build together?

A focused engagement can address one operating problem or connect several parts of the growth system. These are proposed deliverables, not claims about an undisclosed client project.

• AI discovery and GEO: define a repeatable prompt set by market and engine, review brand mentions and cited sources separately, and connect findings to useful, accessible pages.
• AI lead-agent handoff: map the permitted information, identity checks, CRM write, named owner and exception queue; test an uncertain write before any retry.
• Growth measurement: reconcile source events with CRM outcomes and document the denominator, missing records and handoff ownership before drawing conclusions.
• Read the AI lead-agent and CRM handoff guide
• Inspect the public form-to-CRM reconciliation example

Agentic shopping changes the path—not the need for trust.

A buyer may ask an assistant to compare products, narrow a shortlist and prepare a transaction before ever landing on a merchant page. My view: the next advantage is not simply appearing in an AI answer; it is giving an assistant accurate, current product and policy evidence while keeping the customer’s choice, consent and merchant economics visible. Distribution through an assistant is a different question from whether the merchant’s checkout can actually transact there.

Design the journey as linked but distinct decisions: discovery → candidate selection → cart → buyer approval → merchant order confirmation → fulfilment and returns. A product mention is not a visit, a cart is not an order, an authorization is not a settled payment and a completed transaction is not newsletter consent. An assistant’s answer can be plausible while using stale price or inventory; the merchant must validate the actual purchasable variant and terms at the point of commitment.

Building on my work across GEO, model integrations, analytics, APIs and agent workflows, I approach agentic shopping as an architecture and pilot to be agreed with your team. Production integrations depend on verified partner access, implementation ownership and a clearly defined delivery scope.

• Discovery: make product identity, variant identifiers, current price and availability, delivery or pickup options, returns, compatibility and merchant ownership explicit. Different locales or stores may legitimately return different results; record source and freshness rather than presenting a model’s cached answer as a promise.
• Selection and cart: return a machine-readable offer with an expiry or freshness policy, but check the authoritative merchant system again before the buyer commits. Preserve the human-readable product page and an accessible fallback if a partner, browser or payment flow is unsupported.
• Checkout authority: distinguish an agent preparing a transaction, the buyer’s explicit approval and the merchant confirming an order. Validate destination, shipping, taxes, discounts and the final amount in the merchant system; never let generated text alone authorize payment or assert an order succeeded.
• Measurement: retain observed assistant referrals, merchant events and confirmed CRM or order outcomes as separate facts. A missing recommendation impression is unknown—not zero—and a platform citation is not evidence that a person visited or bought.
• Google Merchant Center UCP early-access scope
• Google merchant checkout responsibilities and roadmap
• Explore the detailed AI shopping guide
• Read the agentic checkout measurement guide
• Use the checkout reconciliation framework
• Calculate known checkout outcomes
• Map buyer consent to CRM subscriptions
• Evaluate marketing agents before they act

Protocols solve different problems. Combine them deliberately.

My working model is to separate the business action from the transport. A commerce contract can describe a cart or checkout; a tool protocol exposes a callable operation; an agent-to-agent protocol coordinates a delegated task; a browser interface exposes actions available in a human’s current session. They are complementary layers, not interchangeable badges or proof that a specific channel supports the whole journey.

Use the following as a design map for a proposed integration. Specifications, browser trials and partner support change: pin a version, verify access and test a real merchant-and-platform combination before committing to a roadmap.

• UCP / commerce semantics: exchange merchant capabilities and checkout data where both parties support them. Google’s Merchant Center integration describes selective early access for products sold in the US, with later markets planned; do not assume global availability. Merchant acceptance, inventory, shipping and final buyer approval still need explicit handling.
• ACP / checkout contract: OpenAI’s checkout specification currently documents REST checkout sessions, merchant totals, idempotency keys and order webhooks. It describes MCP as future support; do not describe today’s REST checkout as an MCP integration or equate a request acknowledgement with a paid order.
• MCP / tools and resources: expose a narrow operation such as get-verified-offer or prepare-cart with typed inputs, validation, permission checks and scoped credentials. A tool description or risk annotation does not itself stop prompt injection or authorize the action.
• A2A / agent coordination: use agent cards, tasks and artifacts when independently operated agents need to delegate and report work. Discovery is not trust: verify identity and capabilities, exchange credentials out of band, and define who owns a task, cancellation, timeout and partial failure.
• WebMCP / browser-session interaction: expose structured form or JavaScript tools within an actual web session. Chrome describes an early preview and evolving specification; keep a normal accessible interface and server-side checks. A browser-exposed tool is not a shortcut around the user’s permissions.
• Shopify Cart MCP / implementation detail: cart context is a localization hint, not an authoritative shipping address. An update replaces the cart object, so retain required attribution on each update and before conversion to checkout. Revalidate with the provider’s current specification rather than assuming other merchants behave identically.
• Google UCP integration scope
• OpenAI Agentic Commerce Protocol checkout specification
• Shopify Cart MCP documentation
• A2A key concepts
• A2A discovery and trust considerations
• Chrome WebMCP early-preview guide
• MCP tool annotations and security limits

A concrete pilot: from product evidence to a verified order.

Illustrative design, not a client result: start with a bounded product category, one supported surface and an accountable merchant owner. Build an offer adapter that resolves canonical product and variant IDs against a versioned catalogue, stock and price source. Its response should include currency, market, timestamp, availability, fulfilment choices and uncertainty; the final checkout must recalculate against the destination and live merchant rules.

Keep state transitions explicit: offer returned → cart prepared → buyer approved → merchant confirmed or rejected → paid, refunded or unknown. Store a correlation ID, event source, timestamp, stable transaction ID, currency, permitted purpose and relevant consent choices only where justified; record tool and model versions without retaining unnecessary personal inputs. Verify order webhooks and deduplicate events. If a write times out, inspect merchant state before any retry; an acknowledgement, timeout or browser redirect alone is not proof of purchase.

Synthetic reconciliation example: 20 distinct buyer-approved checkout attempts lead to 18 merchant-confirmed paid orders, one expired session and one unresolved status. Two of the 18 confirmed orders are later fully refunded, leaving 16 not fully refunded at the observation cutoff. The two unresolved/expired attempts are not assigned revenue; partial refunds, tax and fulfilment costs require their own records. This is a state ledger, not a conversion benchmark or evidence of incremental growth.

I would compare a documented baseline with a bounded pilot using the same markets, products and observation window. Review product-data freshness, valid-offer rate, human-approved handoff, confirmed payment, refunds, support exceptions and contribution separately. Recommendation exposure may be unavailable; report it as unknown. A change after launch is an observation, not proof the agent caused it.

• United States: test the actual merchant and channel eligibility before investing in a native checkout. Map state-level privacy, tax and delivery requirements to the specific business; use a conventional checkout when the surface or merchant is unsupported.
• Europe and Belgium: validate language, tax-inclusive pricing presentation, shipping, returns and applicable privacy requirements for each customer journey. The precise consumer rights and exceptions depend on the transaction; do not infer consent to marketing from a purchase.
• India: test currency, local delivery and payment options with the actual provider. NPCI documents multiple UPI merchant flows, but a specific agent or merchant integration must prove which flows it supports; do not assume an in-chat payment is available.
• Middle East / GCC: test country, currency, language, delivery address quality, payment method and fulfilment independently; requirements and support vary by market. A regional brief is not evidence that one platform supports every GCC country.
• B2B and startup teams: where checkout is a qualified conversation rather than payment, replace order states with verified enquiry, permission to follow up, named owner, accepted CRM write and human disposition. Record rejected or uncertain handoffs rather than inventing a conversion.
• Shopify cart and checkout integration detail
• OpenAI checkout states and idempotency
• Google merchant responsibilities and consent roadmap
• EU distance-selling guidance
• NPCI UPI merchant-flow FAQs
• Read the bounded lead-agent handoff guide
• Define a measurement contract

One operating loop. Six concrete outputs.

This is my proposed engagement method, not a claim about a specific client project. Each stage has an artifact and an exit condition. If evidence is insufficient, we narrow the scope rather than manufacture confidence.

• 01 Diagnose → a constraint brief, baseline, metric definition and decision owner.
• 02 Connect → a source and permission map: API contracts, identity, consent, freshness and failure paths.
• 03 Build → a versioned workflow with typed inputs, bounded tools and a deterministic fallback.
• 04 Evaluate → a representative test set, acceptance rubric, failure cases and cost/latency budget.
• 05 Release → an approved change, limited exposure, rollback path and verification against the real destination.
• 06 Observe → outcome metrics, execution traces, alerts, reviewer feedback and a next-decision log.

Different businesses. Different deployment constraints.

Illustrative engagement briefs—not client results. Expand a business context for the deployment considerations.

• Startups: turn fragmented customer evidence into a traceable positioning and experiment backlog. Separate approved facts from model suggestions; use founder review when sample sizes cannot support a statistical winner.
• B2B: connect search and LLM discovery to account journeys, CRM stages and sales feedback. Define buying-account identity and stage timestamps; a form fill, qualified opportunity and closed-won deal are different events.
• Ecommerce: connect product knowledge, discovery and conversion to contribution after discounts, returns and fulfillment. Variant identity, stock and price freshness matter more than an impressive agent demo.
• Retail: reconcile product and local availability across stores, web and customer-support journeys. Define location and channel scope; do not present a national inventory total as a store-level promise.

GEO is a measurement problem as well as a content problem.

I work on generative engine optimization and LLM visibility as part of a wider distribution system: what a buyer asks, which sources an answer uses, how the brand is represented and whether a measurable customer journey follows.

A useful baseline fixes the query cohort, market, language, model or surface, date and sampling method. Repeat observations and separate brand mentions, citations, sentiment, referral sessions and qualified enquiries. A change in one is not proof of a change in another; model answers vary and many journeys leave no attributable referral.

The implementation starts with accessible pages, explicit entities, evidence-backed claims, useful comparisons and maintained product information. Google states that its normal SEO fundamentals apply to AI features; there is no special AI schema required for inclusion. No crawler permission, schema, llms.txt file or protocol can guarantee a recommendation.

• Google: AI features and your website
• Inspect the public resource library

Frontier models. Deliberately bounded systems.

I integrate frontier models and APIs into agent workflows with a task-first approach. Model choice follows the acceptance test, data constraints, latency and operating cost—not a permanent allegiance to one leaderboard. Provider and model versions, prompts and tool schemas should be recorded so a change can be evaluated.

For retrieval, establish document ownership, freshness, permission filtering and evidence references before increasing context size. Keep retrieved material as untrusted data. For generation, validate output shape and source support separately: valid JSON can still contain an unsupported conclusion. For execution, make the server—not the model—the authority for access and business rules.

• Use deterministic code for arithmetic, eligibility and idempotency; reserve model reasoning for tasks that benefit from it.
• Budget tool calls, retries and elapsed time. Retry only safe operations; reconcile uncertain writes before repeating them.
• Measure cost per accepted output, not just token cost. Include reviewer effort, failed runs and rework.
• Keep credentials and personal data out of prompts and traces unless explicitly necessary and approved. Use scoped access, redaction and retention controls.
• Evaluate prompt injection, unavailable sources, malformed outputs, stale retrieval, partial tool failures and changes in model behaviour before broad release.

Know which layer you are actually changing.

These are protocol-readiness and integration-design considerations, not claims that I have delivered production UCP, A2A or WebMCP deployments. Their role is to make an interface more explicit; none removes the need for security, customer permission or a viable business case. Technical references checked 26 October 2026; pin the relevant specification and test actual partner support before implementation.

• MCP — tool and context integration. Expose narrowly scoped operations with explicit schemas. Tool descriptions are not a security boundary; enforce authorization and validation at execution time and keep human review for consequential actions.
• A2A — collaboration between agents. Agent Cards describe interfaces and capabilities; tasks and artifacts support delegated work. Discovery is not trust. Validate supported capabilities, authenticate the caller, and define task cancellation, ownership and failure handling.
• WebMCP — structured actions inside a web application. Chrome documents declarative forms and imperative tools, with an experimental origin-trial rollout. Verify browser and feature availability at delivery time. Keep accessible human controls and a non-WebMCP path; exposing an action must not bypass the site’s validation or approval.
• UCP — commerce capabilities and their negotiation. Profiles describe supported services, capabilities and payment handlers. A checkout integration still needs truthful product data, deterministic totals, supported fulfillment and appropriate buyer handoff. Do not confuse protocol exposure with platform distribution, merchant acceptance or guaranteed conversion.
• MCP tool specification
• A2A specification
• Chrome WebMCP origin-trial guidance
• UCP overview
• UCP checkout and buyer handoff

Observe the journey. Audit the execution.

The commercial view and the system view must meet without being confused. GA4, product analytics such as PostHog, search and LLM visibility evidence, CRM outcomes and workflow traces answer different questions. The integration plan establishes which system owns each event and which identity links are permitted.

A workflow can execute successfully while producing a bad recommendation. A WhatsApp click is intent, not a sent message or a qualified lead. A CRM contact is not necessarily marketing consent. An attributed conversion is not automatically incremental revenue. These distinctions determine what the dashboard can responsibly say.

• Commercial layer: eligible audience, funnel stage, qualified outcome, contribution and observation window.
• Execution layer: correlation ID, model/prompt/tool versions, source freshness, validation result, approval, latency, cost and retry state.
• Quality layer: factual support, task completion, reviewer acceptance, exception rate and regression against an agreed reference set.
• Alerting layer: actionable thresholds, named owner and runbook. Avoid alerts for every fluctuation; use a baseline appropriate to volume and known delays.

An implementation your team can own.

We agree the delivery level before work starts: discovery, prototype, production implementation or ongoing embedded support. The proposal names systems, access dependencies, acceptance criteria, responsibilities, fee and review milestones. Production readiness is a separate gate from a convincing demo.

You receive the agreed working assets, configuration and interface documentation, evaluation fixtures, measurement definitions and an operating handover. Your team retains control of its accounts and approval paths. Ongoing monitoring or support is explicitly scoped; 24/7 operations, software fees and compliance certification are not implied.

• Start with one costly or strategically important constraint, not an entire autonomous department.
• Bring a business question, existing stack, implementation owner and examples of a good outcome. No credentials or customer exports in the first enquiry.
• Agree what would stop the release: unsupported claims, missing consent, unreliable data, unacceptable error rates or absent rollback.
• Review delivery and commercial outcomes separately. No engagement guarantees traffic, AI citations, conversion lift or revenue.

Supporting material

• Professional background
• Existing case studies and measurement limitations
• Design a reliable AI lead-agent and CRM handoff
• Explore AI shopping discovery, checkout and measurement
• Choose an AI marketing agent by task and review controls
• Design a bounded decision layer for an agent workflow
• Build the marketing data and CRM measurement foundation
• From prompt to production: marketing operations
• Compare all services

Tell me what you need to change.

A message is prefilled for you to edit and send. Nothing is sent automatically. Do not include confidential data.