shoptalk

Your back office, out loud. An MCP server for Alexa+ that tells a small trade shop which customers are losing it money, before the first truck rolls.

Comment

Inspiration

More than half of Main Street service businesses run with one or two people. In a two-truck HVAC shop, the owner is also the dispatcher, the bookkeeper, and the analyst. The analyst part never actually happens. The data is all there, in the invoicing app, the schedule, and the quotes, but nobody looks at it until tax time.

The tools these owners can afford tell them what's scheduled and what's been invoiced. None of them tell the owner what any of it means: which customer quietly went negative, which kind of quote stopped closing, why last month's margin dipped. On the platforms I looked at, job costing and margin alerts sit on tiers that cost several times the entry plan. Owners on the entry plan export to a spreadsheet, or they don't look.

These owners aren't at a desk. They're in an attic, under a sink, in a truck. Voice on a screen they already have in the kitchen or the shop is the right surface for this, and Alexa+ opening to outside developers made it buildable.

What it does

shoptalk is a back office that talks. The demo shop is fictional (Dale's Heating & Air, two trucks, Lee's Summit, Missouri) and runs on a full, self-consistent sample dataset.

The morning briefing leads with what changed. "Alexa, open shoptalk" brings up a briefing card in under a second, and the voice follows. It opens with the items that need a decision, not the schedule: "Meridian is the third job in a row over the labor estimate. You're losing money on them, about 11% after labor." Every customer is compared against its own history, so a customer who always pays in 40 days isn't flagged at 38, and one who usually pays in 10 is flagged at 21.

The analyst answers the questions owners actually have. "Which of my customers lost me money this quarter?" returns a chart card and a spoken answer: three jobs, 11% negative after labor, $1,220 in change orders never billed, and a $70 trip charge worked out from the shop's own drive time and labor rate. It says which fix is bigger. It offers to flag the customer, and "yes" writes the flag.

It remembers. Ask "is that why margin was down last month too?" and it attributes the dip: Meridian about a third, and "the two warranty callbacks we talked about last week." That line comes from stored conversation history, not a script. Remove the stored turns and the reference goes away.

It acts. "Start onboarding for the Hendersons on Sycamore" creates the customer and runs a three-step workflow (welcome message, document request, kickoff walkthrough held on the next open weekday). The checklist card ticks as each step actually completes.

It goes beyond the demo script. Schedule, receivables, leads, quote win rates by job type, unbilled work, profit for any period ("since September 1"), revenue by customer, payment reminders. It refuses what it doesn't have (payroll, taxes) by saying so and offering something it can answer.

It works anywhere an assistant does. shoptalk is an MCP server, not an app. The same tools and the same cards work in the simulated Alexa+ display and inside Claude as a custom connector, where the cards render inline and expand to the full poster.

How I built it

The MCP server is the product. Python on the official MCP SDK, Streamable HTTP, protocol 2025-11-25. It exposes twelve tools, from get_morning_briefing and analyze_customer_profitability to flag_customer_for_review and start_onboarding. The cards are real MCP Apps (ui://shoptalk/*, served by the server as text/html;profile=mcp-app), so any MCP Apps host can render them. The simulated Alexa+ client (React and TypeScript) is the display surface only, and its source ships in the repo.

Agents on Bedrock AgentCore. A Strands supervisor uses the Agents-as-Tools pattern to route each turn to a specialist: schedule, invoices, leads, onboarding, and the analyst. It runs on AgentCore Runtime with sessions held across turns. Claude Sonnet 4.6 on Bedrock handles the supervisor, the analyst voice, and the briefing narration. Claude Haiku 4.5 handles the operational desks and the fast router.

The math never touches the model. Every figure is computed in Python from the shop's records: margin after labor per customer, trailing 90-day win rates with a documented "stopped closing" rule, baseline variance for anomalies, and per-customer payment habits for overdue logic. The model's only job is to say the result well. Tests enforce this. A provenance check traces every spoken number to a computed field. A consistency check makes sure Meridian's $1,220 is $1,220 in every tool, card, and sentence. A 135-question bank routes 100% correctly. The full suite is over 2,500 tests.

AWS underneath.

  • DynamoDB single table for business data, conversation history, flags, and onboarding runs, scoped per visitor so judges don't see each other's changes.
  • ECS Express Mode (Fargate behind an ALB) hosts the MCP server and display.
  • EventBridge Scheduler and Lambda reseed the demo shop at 4:30am Central, warm the briefing cache, and keep the runtime warm during the day.
  • Amazon Polly (neural) voices every answer, with an S3 cache so repeated sentences cost nothing.
  • Budgets and rate limits keep a public demo from running up the bill.

Challenges I ran into

  • App Runner was closed to new customers when I went to deploy, so hosting moved to ECS Express Mode mid-build.
  • Warm sessions served old code. After a runtime deploy, a session kept warm by the scheduler kept answering from the previous version. The fix was rotating the shared session id on every runtime deploy and treating "deployed" and "serving" as separate checks.
  • A temperature-0 multi-tool turn is not repeatable. Bedrock's Converse API has no seed, so the same two-tool turn occasionally skips its second tool. I stopped reporting single passes and started reporting counts.
  • Tests that agreed with themselves. Several early tests computed the expected value with the same code as the actual one. I rebuilt them so expected values come from an independent path.
  • Voice-first rendering. The card needs to appear before the voice starts, and the caption has to match what Polly says word for word. Getting both meant progressive rendering and a single text-cleanup step ahead of both the captions and the speech.

The full friction log is in the repo (FRICTION.md) and attached to this submission.

Accomplishments that I'm proud of

  • An analyst that's trustworthy because the model can't change its numbers.
  • A briefing that speaks first about what changed, judged against the shop's own history.
  • Cross-session memory that's real, tested, and removable.
  • Real MCP Apps that render in two different hosts from one server.
  • A security and hardening pass before submission: full-history secrets scan, least-privilege IAM, dependency audit, CSP headers, scrubbed errors, and a smaller container image.

What I learned

Deterministic first is the stronger story for this audience. Contractors rank inaccurate AI output as their top concern about AI tools. A new shop has months of data, not years. Fixed thresholds and the shop's own trailing baselines work from day one, and learned models can take over as history builds.

I also learned that an MCP server is the right commercial unit. Alexa+ add-on policy excludes business-only add-ons, so the asset that travels is the server. It shows up on Alexa, in Claude, and in any other host that speaks MCP.

What's next for shoptalk

  1. Close out a job by voice from the truck. "Just left the Johnsons, job's done." shoptalk closes the job, builds the invoice from the line items and any change orders, reads the total back, and sends it when the owner says yes. This closes the unbilled change order gap at the source instead of finding it after the quarter.
  2. Live connectors for Jobber and QuickBooks. The agents read through a repository layer, and Jobber- and QuickBooks-shaped adapters already pass the full analyst contract. Production swaps fixtures for OAuth and webhooks with no change to the analyst.
  3. Learns each shop's patterns. Per-shop models for labor estimates by job type, late-payment risk, quote close likelihood, and seasonal demand, labeled as estimates. Reported numbers stay computed from the records.
  4. Alerts the moment something breaks pattern, by text message, since Alexa+ doesn't offer third-party push.
  5. A phone line from the truck through Amazon Connect, so the same agent answers from any phone.

shoptalk is a DataWisdom Solutions Build project. The plan is to deploy and maintain it for local service businesses as a monthly service.

Try it yourself

  1. Open the live demo in Chrome: https://sh-1c5ae667cf42436584482c3c674f9bcc.ecs.us-east-1.on.aws/ and allow the microphone, or type.
  2. Say or type "Alexa, open shoptalk." Then: "Which of my customers lost me money this quarter?", "Yes. And is that why margin was down last month too?", and "Start onboarding for the Hendersons on Sycamore."
  3. Explore freely: "Which kinds of quotes stopped closing?", "Did I do any work I didn't bill?", "What was my profit since September 1?"
  4. Your flags and onboarding are scoped to your browser, so nothing you do affects other judges. The shop data resets every morning at 4:30am Central.
  5. Optional: add https://sh-1c5ae667cf42436584482c3c674f9bcc.ecs.us-east-1.on.aws/mcp as a custom connector in Claude and ask for "the shoptalk morning briefing."

All business data is fictional sample data; the display carries a permanent badge saying so.

The full friction log is in the repo (FRICTION.md).

Built With

Share this project:

Updates

Submission history