Shawn Durrani

Agentic Affiliate Pipeline Experiment

13 Feb 2026

This experiment explores what an "agentic affiliate pipeline" might look like when content exposure, product signals, LLM reasoning, and payment infrastructure are connected end-to-end.

The core idea is simple: if a viewer is repeatedly exposed to certain products in video content, could that signal be structured, surfaced inside a chat flow, and - with consent - carried all the way through to checkout?

The pipeline runs left-to-right:

Video library -> object detection -> affiliate catalogue match -> structured interest signal -> LLM recommendation -> Stripe-powered transaction.

Instead of burying everything inside one large prompt, the system treats each stage as observable and testable. That makes behaviour easier to reason about - and easier to break on purpose.

What This Proves

• Video signals can be converted into structured product-interest hints (YOLO World detection + catalogue matching).
• Recommendations can be introduced in chat without replacing the base assistant response.
• An affiliate suggestion can move from conversational intent to a completed Stripe transaction in the same flow.
• Economic attribution and payment execution can be tied directly to agent-mediated recommendations.

Stack

• Bufo GPT chat client, built with OpenAI Codex and powered by Claude
• MCP server exposing affiliate recommendation signals
• Stripe agentic commerce protocol flow to generate a shared payment token and complete checkout
• Built with OpenAI Codex

What Got Interesting

Some parts behaved exactly as intended. Others surfaced issues immediately:

• Latency accumulates quickly across detection + reasoning + payment flows.
• Consent and transparency must be explicit if behavioural signals influence recommendations.
• Guardrails become more important once agents cross from suggestion to transaction.

The architecture makes these failure modes visible rather than hidden inside prompt logic.

Boundaries & Next Steps

• Move detection and matching to pre-processed jobs to reduce runtime latency.
• Store scored interest signals instead of recomputing on each interaction.
• Add tighter controls before allowing the agent to complete transactions without explicit user confirmation.
• Keep recommendations opt-in and explainable.

This is not a polished product. It's a working prototype designed to test how agent systems behave when economic incentives, brand protection, and probabilistic reasoning intersect.

Watch the video

MCP Merchant — Public MCP server for agentic commerce

15 Sep 2025

Agents don’t yet have a reliable way to discover agent‑friendly, merchant‑run surfaces. MCP Merchant shows how the Model Context Protocol Registry can advertise a safe, hosted commerce surface that agents can find and use immediately. It’s read‑only, backed by Stripe test‑mode data, and bounded so it’s safe to try in the open. SSE endpoint (shown here as text): https://mcp.shawndurrani.ai/sse.

Why I built it this way

There’s a missing link between discovery and first use for agentic commerce. The pattern here is simple: publish to the MCP Registry (standardised metadata), host a minimal SSE endpoint, and expose a couple of useful, safe tools over a real catalogue. That connects discovery → connection → capability without bespoke connectors or a full app. It’s intentionally small and production‑shaped so a team could copy it tomorrow.

Stack

• MCP server (namespace: ai.shawndurrani/mcp-merchant, v0.1.1)
• Transports: hosted SSE and local stdio (NPM)
• Stripe Products/Prices (test mode) as the catalogue
• In‑memory cache (~94 items, AUD)
• Tools: health, searchProducts

What it does

• Exposes safe, read‑only product search for agent workflows
• Simple substring matching over name/description with pagination
• Designed for quick trials in ChatGPT MCP and the MCP Inspector

Try it

• ChatGPT (Web) → Settings → Developer → Model Context Protocol → Add Server → Type: sse → URL: https://mcp.shawndurrani.ai/sse. Start a new chat, then run ai.shawndurrani/mcp-merchant.health and ...searchProducts.
• CLI (Inspector): npx -y @modelcontextprotocol/inspector@latest --sse https://mcp.shawndurrani.ai/sse
• Registry Explorer: mcp.shawndurrani.ai/explore
• Health (JSON): mcp.shawndurrani.ai/healthz

Safety

• Stripe test mode only; no PII
• Results bounded: pageSize ≤ 20; query length limited
• Cache limited by product cap; safe defaults

Built to make agent experiments practical without touching production systems.

Agentic Commerce Demo – Voice-first LLM Checkout

2 Aug 2025

This is a third rewrite of a demo I've been experimenting with that explores agent-driven commerce using real tools. It started as a Python and HTML project, then moved to JavaScript and React once I hit limitations around orchestration, latency and modularity.

The core idea was to see if an LLM-based agent could guide a user through onboarding, product selection, and payment – all through voice – without relying on a traditional frontend or support flow.

Stack

• OpenAI GPTs for both orchestrator and specialist agents
• ElevenLabs for speech-to-text and text-to-speech
• Pinecone as the vector store for product recall and metadata
• Stripe Agent Toolkit for product catalogue and checkout links
• Salesforce as the customer record system
• Twilio for OTP
• Node.js as the backend layer
• ngrok to expose webhooks

What it does

• New user: Onboards via voice, sets up identity, verifies via OTP, browses products, and receives a checkout link
• Returning user: Recognised by phone number, verified again, and taken straight to purchase using a stored payment method

Everything is voice-driven and agent-orchestrated, from start to finish.

What went wrong

• Prompt structure was too fragile – especially around product handoff
• Agents would hallucinate product names or miss lookup steps
• Too much logic in prompt instructions made behaviour hard to debug
• Race conditions between OTP verification, Salesforce creation, and Stripe checkout
• Voice UX was inconsistent – speech-to-text accuracy was unreliable and latency was too high for fluid use

Why I built it this way

I avoided using vertical stacks on purpose. I wanted something composable, using real APIs that reflect what startups or teams might reach for. I also don't write code the traditional way – most of this was done through iterative prompt design, test scaffolding, and pairing with LLMs via Cursor or Claude Code.

This isn't meant to be polished. It's functional, testable, and closer to what you might build internally for validation or customer education.

Watch the demo