I Built a Cyberpunk Cat RPG to Teach Production AI Architecture
The Neon Scratch Lounge is a playable cyberpunk RPG where the game runs as a visible distributed system. Every turn walks through RAG, structured retries and idempotency, execution guardrails, structured observability, and persistent state, so you watch the production-AI patterns instead of reading about them.
The Neon Scratch Lounge is an interactive RPG where you play cat characters in a 2087 city and, while you play, watch the AWS infrastructure handle each turn in real time: the Step Functions trace, the Lambda invocations, the token counts. It's built to make abstract reliability patterns concrete. Instead of a blog post explaining what separates a working AI prototype from something you'd trust in production, you play it and see the difference.
Under the hood: Claude via Amazon Bedrock as the Dungeon Master, a Step Functions Express workflow orchestrating the pipeline, seven Lambdas, three DynamoDB tables, API Gateway, EventBridge for audit events, an SQS dead letter queue, and CloudWatch, all defined in CDK. It demonstrates five patterns. RAG: a retrieve-lore Lambda runs before every Bedrock call to ground the model in real facts about locations and enemies. Structured retry and idempotency: Step Functions does exponential backoff with full jitter, and tool results are cached in DynamoDB per turn so a retry can't double-apply a state change. Execution control separation: the model proposes actions, a validation Lambda checks them against an allowlist, and the actual logic lives in typed, unit-tested functions, not in the prompt. Structured observability: every Lambda emits one JSON log line with tokens, latency, retries, and status, and metric filters turn those into alarms. Persistent state: character stats, inventory, and quest log live in DynamoDB, and after 20 turns the system summarizes the narrative history to stay inside the context window.
Key takeaways
- Treat an AI agent as a distributed system, not a clever API wrapper: explicit failure handling, state, observability, execution guardrails
- Separate reasoning from execution: model decides, code validates against an allowlist and runs tested logic; that's what stops loops and unauthorized actions
- "Serverless" still has floors: OpenSearch Serverless holds a 4-OCU minimum (~$700/mo idle), so I switched to in-memory keyword scoring; read the scaling behavior, not the label
- Some gaps are deliberate: no auth, rate limiting, encryption at rest, or multi-region, stated as demo simplifications not architecture advice
Who this is for
Engineers building production AI systems who want concrete reliability patterns beyond chatbot prototypes. Assumes comfort with AWS serverless (Lambda, Step Functions, DynamoDB) and CDK. Source is open at github.com/chaotictoejam/neon-scratch-lounge and deploys with cdk deploy --all.
The full write-up, with all five patterns and the cost lesson in detail, is on DEV.to.