LogiOps AI

The agent proposes, you approve, code enforces it. A simulated Alexa+ ops desk where an agent on Bedrock investigates late shipments through our own MCP server, and only a person can approve a plan.

Comment

In short: LogiOps AI is an operations desk you talk to, for the person who handles late shipments. On a simulated Alexa+ device, an agent on Amazon Bedrock investigates an incident through a real, self-hosted MCP server (Streamable HTTP, spec 2025-11-25, with an Agent Skill and MCP Apps), code prices every plan, and the agent recommends one. Only a person approves; code executes it once and verifies it.

Inspiration

When shipments slip, an operations lead spends the morning on the phone: which problem first, is there stock nearby, can another carrier make it, what does it cost, who approves it? The data lives in four systems and the decision is made in a spreadsheet. We wanted that morning to become a short conversation, without ever letting an AI move inventory or money on its own. So we built the boundary first and the assistant around it: the agent proposes, a person approves, and code enforces it.

Why Alexa+

The person this is for runs operations away from a desk: on a warehouse floor, at a loading dock, between calls. Their hands are busy and the decision is small but urgent, so voice is the natural first step, and a screen settles the details. Alexa+ is voice-first, not voice-only, and LogiOps uses what makes it more than a question-and-answer bot:

  • an agentic workflow across services: MCP tools for orders, stock and carriers, a deterministic planner, Amazon Bedrock for the reasoning, Amazon Polly for the voice and Amazon Cognito for identity;
  • state across sessions: preferences and memory (AgentCore Memory) that steer the next decision;
  • purchasing: a booking read back with its price and charged once;
  • rich cards: one surface at a time on an Echo Show-style screen, with the plans as an MCP App;
  • an Agent Skill the agent loads over MCP;
  • proactive alerts when the data under a decision changes.

Most of Alexa+ today is for people at home, and this is a work use case; the pattern is the one a person would want from any assistant that spends money: it proposes, explains the trade-off and waits for a yes.

What it does

LogiOps AI is a voice-and-text operations desk for logistics exceptions, shown on a simulated Alexa+ device (an Echo Show-style screen, full screen on a phone). Its inbox holds four synthetic incidents of different kinds, clearly marked as simulated:

  • SHIP-421: 20 laptops 12 hours late in transit
  • SHIP-433: The carrier stopped departures; one shipment carries a critical hospital order and a store order
  • SHIP-452: 40 routers held at customs for a 72-hour review
  • SHIP-460: A delayed replenishment leaves 30 laptops for a critical hospital order (20) and a school order (25)
  1. Start the day. "Any delays today?" The agent reads the inbox over MCP and says where to start: SHIP-433, because 12 critical units are at risk. The home screen draws every open incident as a light lane on one time scale, each running to its promise and trailing its delay. A briefing only reads; it cannot change anything.
  2. Investigate, and watch the agent work. "What's happening with SHIP-433, and which plan should we choose?" A Claude agent on Amazon Bedrock, running on Strands Agents, calls our MCP tools (shipment, orders, inventory, carrier quotes) over Streamable HTTP; the device lights each tool call as it returns, then the server calculates every feasible plan. Four for SHIP-433, from waiting ($0, everyone 24 h late) to flying the hospital order and rebooking the store on ground ($390, hospital on time). Every answer is checked against the incident's data before it is shown, the spoken line with the rest of the answer; a failed check goes back to the model once, and an answer that still fails is shown flagged, never hidden.
  3. Remember what you care about. "Remember my spend cap is $250." The preference persists across sessions, per signed-in user, and deterministic rules apply it to the same calculated plans: on SHIP-433, "Recheck" moves the pick to the $240 option, and the agent explains what that trades away. A preference never approves anything.
  4. Decide. The plans appear as an interactive MCP Apps card with a decision field (every plan by delay and cost, the pick lit, a plan that leaves a critical order late drawn as a hollow red ring). You say "approve the recommended plan"; it reads the plan back with the cost and each order's arrival against its promise, and your yes binds the approval to that exact plan and that version of the data. The card can select a plan; it cannot approve.
  5. Act. "Execute it." The system applies the allocations once (repeating the command never duplicates anything), simulates one notification per customer order plus one for operations, and checks that every unit is accounted for. The result shows the executed route and the critical units on time; the time to decision is measured from the recorded events.
  6. Stay safe when data changes. If stock changes after an approval, the approval no longer applies, "execute it" is refused, and a proactive alert offers the new pick, drawn next to the old one. Book and pay the carriers afterwards: the price is read back with its tax, and one yes charges it once, with a receipt.

Alexa+ speaks a short version of each answer (Amazon Polly on the deployed demo), while the screen keeps the detail. "More" opens the whole conversation with the Agent Skill and the tool trace of each reply. The operator console shows the same incidents as a three-column desk: the queue, the plans as a table with the approve and execute controls, and a rail that lights each MCP call as it returns; the preferences, the audit trail and the session's measured outcomes are there too.

Measured on the deployed demo (2026-10-19, live Bedrock)

  • From the question to a grounded recommendation: 12.2 s, 5 MCP calls, 4 priced plans, 5,941 tokens, one live agent run
  • Tool calls streamed to the device as they return: first at 2.6 s, last at 5.7 s; the answer at 12.5 s
  • From the first investigation to the verified execution: 13.1 s in a scripted walkthrough, with no human pause
  • Outcome of the chosen plan: 12 critical units on time, 18 standard units 8 h late, $390 extra
  • Booking read back and charged once: $466.10 with tax, receipt served
  • Bedrock usage per run: about US$0.04 (the prompt and the Agent Skill are cached after the first turn)

GET /metrics publicly reports decision and execution times, outcomes, model calls and tokens, and the session total booked from recorded events. Booking numbers and amounts per incident require operator access through the incident, booking or receipt endpoints; the answer and streaming times are what the client measured through CloudFront, and the cost is the run's tokens at Bedrock's prices. The same pattern fits any exceptions desk where an agent proposes and a person decides: payments operations, on-call incidents, returns.

How we built it

  • MCP server: the official Python MCP SDK, stateless Streamable HTTP at /mcp, protocol version 2025-11-25: 12 tools (none of them can approve a plan), 2 prompts, 2 resource templates (incident://, receipt://), URL elicitation, and the Agent Skill logiops-exception-desk served as a resource so any MCP host loads the same playbook. investigate_incident declares an MCP Apps view (spec 2026-01-26) that renders the plans and their decision field and can only ask the host to select a plan.
  • OAuth 2.1 with Amazon Cognito: the server is a protected resource (RFC 9728 and RFC 8414 discovery, PKCE S256, two scopes). Guests can read and ask; approving, executing, booking and the write tools need a signed-in user. A standard client such as MCP Inspector gets the 401 challenge and the Cognito sign-in.
  • Agent: a Bedrock Converse tool-use loop on Strands Agents with global.anthropic.claude-sonnet-4-6, through boto3, with prompt caching. The agent gets only read and investigation tools and a 50-second deadline. Follow-ups and the queue briefing are shorter loops with read-only tools. A streaming route sends each MCP tool call to the device as it returns; the model's tokens are not streamed.
  • The data check: a deterministic evaluator compares every answer with the plans and figures the tools returned (costs, delays, ETAs, the recommended plan); the spoken line is checked with the rest of the answer.
  • Memory: AgentCore Memory keeps each signed-in user's conversation turns and long-term facts, so a new session opens with "Welcome back… Last time … we were on SHIP-433 and you said “book it”"; "forget me" deletes it.
  • Preferences: a rule (balanced, or cheapest unless a critical order would be late), an optional spend cap and a note, per user; deterministic code picks the plan the preference points to, and the model is told it as a fact.
  • Workflow core: SQLite with one transaction per action and every table keyed by incident. Plans are versioned; approvals and executions check the exact plan id and data version; execution is idempotent; bookings are quoted, read back and charged once.
  • The device is an MCP client too: it runs initialize, tools/list and resources/read for the MCP App, and reads its own inbox and alerts with tools/call (list_incidents, list_alerts) over Streamable HTTP, the same way any MCP client would.
  • The device: plain HTML, CSS and ES modules, no framework. After four design critiques it was redesigned as light trails on a night road: the incident lanes, the route map, the agent's tool calls as stations, the decision field and one large figure per screen. Accessibility is tested with axe at desktop, Echo Show and phone sizes.
  • AWS: EC2 with an encrypted EBS volume for SQLite, CloudFront for HTTPS (a second distribution is the MCP Apps sandbox origin), a private S3 bucket for releases, Systems Manager for SSH-less deploys, Cognito, Polly and AgentCore Memory, plus an AWS Budgets action, a Route 53 health check, a CloudWatch alarm and SNS for spend and uptime, all in Terraform with least-privilege IAM.
  • For judges: a replay mode runs the whole demo with a scripted model and zero tokens (docker compose up); 534 tests, 127 front-end unit tests and 62 browser walkthroughs, each run in Chromium and in Firefox, in CI. The deployed demo stays live until judging ends, watched by a Route 53 health check every 30 seconds with a CloudWatch alarm that e-mails us, reset every night, and with a fallback to the replay, clearly labelled, if the live model is unavailable. A guest meets the live agent without signing in: 20 of the day's 40 model calls are a guest share, about one live investigation per visitor, and guests hear Amazon Polly and receive the alert card too. Spend is capped in the app, and an AWS Budgets action cuts Bedrock and Polly at the account level if a month ever passes US$60; the demo then keeps answering from the replay.
  • Every tool, prompt and resource carries its own icon (MCP 2025-11-25), so a client's tool list reads at a glance. MCPJam Inspector, a third-party client, connects as a guest, validates investigate_incident's structured output against its schema and flags it as an MCP App.
  • It works in an existing AI assistant too. Added to Claude as a custom connector with no sign-in, the same server reads SHIP-433, asks before running investigate_incident (annotated as not read-only, because it records plans) and renders our plans card inside the chat, where it can select a plan but never approve one.
  • How we worked: we built it with Claude Code as our coding agent. Every change was a pull request to main with CI (unit, MCP contract, browser and accessibility tests, and a secret scan) and local checks before merging, and each decision is logged with its evidence in docs/hackathon/decisions.md.

Challenges we ran into

  • Alexa+ developer tools are partner-only. We built the simulated device the hackathon FAQ describes and kept everything under it standard: the device is itself an MCP client of the server, and MCP Inspector drives the same URL with the same OAuth sign-in. The server speaks the protocols Alexa+ add-ons are built on; what we expect is left to connect the real Alexa+ is in docs/hackathon/alexa-plus-readiness.md.
  • The model must never approve. No approval tool exists; the MCP Apps card can select but not approve; chat commands act only when the whole utterance is the command and contains no negation (in a live test, "please do not execute it yet" had executed the plan).
  • Grounding by construction is not enough. Models still mis-state a figure. The data check sends the answer back once and shows a failure instead of hiding it.
  • Strands' MCP client runs on a background thread, which deadlocks with an in-process server; we wrote a small tool adapter on the caller's event loop.
  • CloudFront and the bearer token. With the managed CachingDisabled policy, CloudFront does not forward the Authorization header on GET requests; we caught it in a configuration review before deploying, and a custom cache policy forwards it while the app answers no-store.
  • Replay honesty. When the model is the scripted replay, the device says so on every answer, and the agent stage says "Replayed from a recorded run" instead of pretending the model thought for 12 seconds.

Accomplishments that we're proud of

  • A real MCP server that a standard client drives end to end, with OAuth 2.1, MCP Apps and an Agent Skill, not a wrapper around one API call.
  • Every answer checked against the data before it is shown, the spoken line with the rest.
  • An approval bound to a plan and a data version, invalidated by a stock change, with a proactive alert drawn next to the old plan.
  • Outcomes measured from the recorded events, per incident and per session, on the deployed demo.
  • A device that shows the agent at work: each tool call lit as it returns, then the data check.
  • Zero-cost judging: replay mode, Docker, over five hundred tests, axe at desktop, Echo Show and phone sizes.

What we learned

MCP's value shows up when the same tools serve a person's assistant and an autonomous agent. The hard part of "agentic" is not the loop; it is deciding which actions a model must never take, and enforcing that in code rather than in the prompt. The same goes for preferences and for facts: the model should explain them, not apply them.

Who would use it, and how it reaches them

The first users are exceptions desks at regional distributors and third-party logistics providers: a handful of people who decide, several times a day, how to rescue late orders, usually away from a desk. The integration is the MCP server itself. Today a company loads its own incidents as a scenario pack over HTTP; next, adapters to its WMS and carrier systems sit behind the same tools. Because it is a standard MCP server, it already works with any MCP client; once the Alexa+ developer tools open, it becomes an Alexa+ add-on without changing the server's tools. The measured outcomes (time to decision, units on time, extra cost) come from the recorded events, so a pilot can compare them with how the desk works today.

What's next

Real carrier and WMS integrations behind the same MCP tools, the Alexa+ registration and configuration once the developer tools open up, token streaming from Bedrock on top of the tool-call stream, and an operator profile per account across several desks.

Built With

  • agent-skills
  • alexa-plus
  • amazon-bedrock
  • amazon-bedrock-agentcore
  • amazon-cloudfront
  • amazon-cognito
  • amazon-ec2
  • amazon-polly
  • amazon-web-services
  • aws-systems-manager
  • boto3
  • claude
  • docker
  • fastapi
  • javascript
  • mcp-apps
  • mcp-python-sdk
  • model-context-protocol
  • playwright
  • python
  • sqlite
  • strands-agents
  • streamable-http
  • terraform
Share this project:

Updates

Submission history