Lossless — AI Store Ops Agent

An AI agent that lets non-technical retail managers monitor and fix their digital storefront in plain English, before it costs them sales.

Comment

Inspiration

Small and mid-size retailers run more of their business online every year — but they don't have an SRE team. When checkout breaks at 7pm on Friday, they don't see a Grafana alert; they see Saturday's revenue evaporate on Monday morning when the accountant flags it. The technical signal was sitting in Dynatrace the whole time, but nobody who could read it was watching.

We built Lossless to close that loop. The store owner doesn't have to learn observability — the agent does.

What it does

Lossless is an AI Store Operations agent that:

  • Watches the digital storefront through the official Dynatrace MCP server
  • Analyzes the customer conversion funnel (visitors → product views → add-to-cart → checkout → purchase) to find exactly where shoppers are dropping off
  • Translates technical incidents into business impact — dollars lost, customers affected, with peak-hours awareness
  • Proposes a concrete, single-sentence remediation
  • Only acts after the manager approves (staged action → human sign-off → execute → verify)
  • Reports the outcome in plain English

Example: when the payment gateway times out, the manager asks "where are customers dropping off?" Lossless calls list_problems and analyze_conversion_funnel over MCP, sees the purchase stage collapsed, computes a revenue-loss estimate, proposes a failover to a backup processor, asks for approval, executes on approval, and confirms the funnel is recovering.

How we built it

  • Gemini 3 on Google Cloud Vertex AI, accessed through the Gen AI SDK with a manual function-call loop (no automatic function calling) so every tool call is captured in the manager-facing action log
  • Dynatrace MCP integration via the official @dynatrace-oss/dynatrace-mcp-server Node binary, spawned as a subprocess and communicated with over stdio using the Python mcp client and the Model Context Protocol
  • 9 agent tools total — 4 from the Dynatrace MCP server (list_problems, execute_dql, get_service_health, get_problem_details) and 5 retail-specific tools we built (analyze_conversion_funnel, quantify_revenue_impact, propose_remediation, execute_remediation, get_action_status)
  • A conversion funnel engine that maps each incident type to the correct customer journey stage — a payment outage collapses the purchase stage, a search outage kills product discovery, a cart issue blocks add-to-cart
  • Peak-hours awareness so the agent knows a Friday evening outage costs 2-3x more than the same issue at 3 AM
  • A health grade (A through F) giving the store owner a single-glance metric
  • A graceful synthetic fallback: when no Dynatrace tenant is configured, the bridge serves Dynatrace-shaped responses from an in-memory mock storefront so judges can run the demo with zero external setup
  • FastAPI backend, single-file vanilla-JS frontend with a dark dashboard UI, deployed to Google Cloud Run

Challenges we ran into

  • Human-in-the-loop as architecture, not a prompt. We needed the "only act with approval" guarantee to be structural. Our solution: two paired tools (propose_remediation stages an action, execute_remediation checks an approval flag). The execute tool literally refuses to run without approval — the model can't skip it no matter what it hallucinates.
  • Making the demo work without a live store. Judges may not have a Dynatrace tenant or a real e-commerce site. We built a tool-name-compatible synthetic adapter behind the same MCPBridge interface, with smart routing that merges real Dynatrace data with synthetic data when both are available.
  • Gemini rate limits on free tier. The AI Studio free tier gives 5 requests per minute — one chat turn with parallel tool calls burns the whole quota. We solved this with per-model quota buckets, a multi-model fallback chain, and disabled SDK internal retries to conserve quota. On Vertex AI paid tier, this is a non-issue.
  • Honest revenue math. Early versions showed $13,000 lost the instant an incident was injected. We fixed the loss calculation to scale with effective_degraded_minutes — the smaller of the requested window and time since the incident started.

Accomplishments we're proud of

  • A 9-tool agent that executes genuine end-to-end multi-step workflows: detect → diagnose → funnel analysis → revenue quantification → propose → approve → execute → verify
  • The conversion funnel — no other monitoring chatbot shows WHERE in the customer journey people are dropping off. This is retail-specific intelligence, not generic DevOps with labels.
  • An interface a real store owner could use without any training
  • Built and submitted within the hackathon window with zero pre-existing code

What we learned

  • The cleanest "user oversight" pattern in agent UX is two paired tools (propose/execute) that gate by id, not a prompt instruction
  • MCP makes the partner integration story click — once the bridge was working, adding new tools was a one-line change
  • Domain-specific tools (conversion funnel, peak hours) matter more than a better base model — they turn a generic chatbot into something that actually thinks about the problem domain

What's next

  • Real POS integrations (Shopify, Square) so the same agent covers in-store + online ops
  • A nightly digest: "yesterday in the store" in three sentences and one chart
  • Multi-store rollout for franchisees
  • Proactive alerting: the agent messages the owner before they have to ask

Built With

  • cloud
  • dynatrace
  • dynatrace-mcp-server
  • fastapi
  • gemini-3
  • google-cloud
  • model-context-protocol
  • python
  • vertex-ai
Share this project:

Updates