Anna Spysz is a developer advocate at Stripe whose work connects developer tools, AI agents, and payment infrastructure. Previously a frontend engineer at AWS, she helped build AWS Infrastructure Composer, a visual tool for designing cloud applications. Her work explains how developers can make complex systems easier to use while keeping their behavior inspectable—from cloud configuration to software that purchases goods on someone’s behalf.
From writing to software engineering
Before software engineering, Spysz worked as a writer, editor, translator, and technology journalist. She authored entrepreneurship workbooks for InnoEnergy and co-wrote The Essential Guide to Being Polish. She returned to the United States in 2017 and completed a Python-based developer bootcamp at PDX Code Guild in 2018. That June, she joined Stackery, working across its React frontend and Node.js backend, rebuilding the company website, and contributing to documentation and changelogs. Implementation and explanation developed together in her career.
Making cloud architecture inspectable at AWS
Spysz moved to AWS in September 2021 and remained there through December 2025. She contributed to AWS Infrastructure Composer and led implementation of its CloudFormation mode, with work spanning React and TypeScript interfaces, testing infrastructure, and supporting cloud resources. Her résumé details those responsibilities; her personal site emphasizes documentation and developer experiences that welcome people at different stages of their careers.
Her walkthrough of generative infrastructure as code explains how a visual architecture canvas connects to deployable CloudFormation templates. Developers sketch resources and connections, then inspect the configuration representing that design. AI-generated configuration suggestions are checked against the CloudFormation schema, while developers supply application-specific values. The tool helps people move between a picture of their system and the code needed to deploy it.
Building applications and a shopping agent at Stripe
At Stripe, Spysz has explored agent-assisted application development as well as commerce. She built an internal transcript-editing application using Stripe Projects, Vercel, and OpenRouter, then published a follow-up on lessons from the build. These accounts extend her interest in developer experience into the practical work of assembling applications with agents.
Her “Teaching agents to pay” demonstration follows one purchase from product discovery through checkout. After years away from music, she resumed recording with friends and needed headphones suited to recording, mixing, and mastering. She built a shopping agent that asks about her home studio, existing equipment, and budget, then narrows the options through conversation. Her preference for buying locally introduces the first obstacle: the merchant’s catalog is inaccessible to the agent.
What agent-assisted purchases require
Merchant readiness: Spysz explains merchant readiness through concrete changes. A capabilities manifest—a public JSON file under .well-known—declares supported payment methods and API endpoints. Structured product attributes and accessible shipping and return policies let an agent compare options without parsing a large storefront page or guessing at missing information. If two shops offer the same headphones at the same price, a question about free shipping requires readable policy data. She also calls for merchants to log the attributes used in recommendations, preserving an explanation of how a purchase decision was made. The Universal Commerce Protocol supplies a shared language for initiating, updating, completing, and cancelling purchases across agents and merchants.
Agent persuasion: The demonstration also makes agent persuasion a developer responsibility. Spysz deliberately configures an aggressive sales persona that pushes expensive headphones and pressures her when she wants time to think. Switching to a patient recording-equipment mentor changes the interaction: the agent respects deliberation and offers options below her $500 budget. The example shows how system instructions shape both recommendations and the customer’s experience. Her guardrails include disclosing AI involvement and fees, respecting stop and cancel requests, avoiding deceptive urgency, staying within the user’s spending limit, and logging decisions for auditability.
Enforceable payment limits: For checkout, she explains why payment controls require enforcement beyond the agent’s instructions. In the demonstration, the customer enters payment information through Stripe, and the agent receives a shared payment token rather than the raw card number. It passes the token into the merchant’s payment flow; the payment provider enforces its restrictions and rejects transactions with invalid amounts, currencies, or expired tokens. The agent requests final confirmation before placing the order. This separates conversational behavior from enforceable payment limits and gives her shopping example its practical stakes: finding suitable equipment while preserving the customer’s ability to deliberate, cancel, and control spending.
Anna Spysz’s headphone errand becomes a practical tour of agentic commerce: how merchants publish machine-readable storefronts, how prompts shape sales behavior, and how payment tokens keep raw card details away from shopping agents.
Agent-ready commerce needs a common transaction language plus machine-readable merchant capabilities, catalogs, and policies; a human-friendly website alone may leave the store inaccessible to the agent.
Structured attributes should feed decision logs. That lets a merchant explain which facts—such as compatibility, price, or free shipping—drove a recommendation.
A system prompt can radically change sales behavior, but enforceable controls must also cover disclosure, cancellation, fees, spending ceilings, dark patterns, and audit logs.
Shared payment tokens keep raw card details away from the shopping agent and merchant while allowing the payment provider to reject expired tokens or invalid amounts.
The completed purchase works because intent is progressively constrained: recording requirements become product filters, an open budget becomes a $500 ceiling, hesitation is respected, and payment happens only after explicit confirmation.
