Why we built Scout
Ads and specifications can tell someone what a product does, but they cannot tell them how it feels in daily use. Shoppers often have to commit before they feel confident. Suppliers, meanwhile, spend money attracting attention without knowing whether someone has had a meaningful experience with their product.
Scout explores a different path: a short product trial before the buying decision. A shopper can discover products, talk through preferences with Scout, review trial terms, and request a demo. A supplier can present products, manage physical inventory, respond to requests, and learn from completed trials and service reviews.
What we built
Scout combines a borrower experience with a separate supplier workspace. The conversational assistant uses Strands Agents SDK and Gemini, and calls Scout’s self-hosted MCP tools over Streamable HTTP. It helps users explore options and understand the request process while keeping booking decisions with the supplier system.
The demo marketplace includes product discovery, supplier listings, reviewed requests, simulated wallet balances and price breakdowns, returns, refunds, ratings, imports, and supplier analytics. Supplier identity and inventory are kept separate from borrower accounts. The marketplace’s money, tax, transfers, KYC, and fulfillment examples are fictional simulations; no real payment or product loan occurs.
For the Alexa+ track, our web interface demonstrates an agent-style experience backed by a working MCP server. It is a simulation, not a claim of native Alexa+ integration.
How we built it and what we learned
The borrower interface is built with React and TypeScript. Cloudflare Workers run the application and the private MCP service. Firebase Authentication and Firestore support accounts and application records, while a separate Checkout service owns supplier inventory and booking decisions. We learned how much care an agentic shopping flow needs around identity boundaries, changing availability, retries, and clear user approval before a request is submitted.
The hardest challenge was making a convincing end-to-end demo without implying that fictional balances or seeded orders are real commerce. We made the simulated nature of the marketplace visible throughout the experience and kept supplier decisions and request status explicit.
Built With
- cloud-firestore
- cloudflare-workers
- firebase-authentication
- gemini-api
- model-context-protocol
- plawright
- react
- strands-agents-sdk
- streamable-http
- typescript
- vite
- vitest
- zod
Log in or sign up for Devpost to join the conversation.