Storefront Agent

Storefront Agent is an observability-first AI agent that continuously monitors your online store, analyzes issues, and recommends or executes approved fixes directly in WordPress and WooCommerce.

Comment

Storefront Agent

An observability-First AI Agent that reads live store health from Dynatrace, reasons with Gemini 3, and takes human-approved remediation on a WooCommerce storefront.

Closing the loop from problem to fix.

Primary Partner Bucket

[Dynatrace] ← I integrate Dynatrace (observability) as the primary partner MCP. WooCommerce/WordPress MCP is the action layer.

Inspiration

For any store, reliability is revenue: a slow checkout or a broken plugin during a traffic surge costs sales in real time.

Teams already have rich production telemetry in Dynatrace, but acting on it still means a human jumping between dashboards and the store admin. I wanted an agent that closes that gap. Sees the problem, explains it, and fixes or communicates it on the storefront while keeping a person in control of every change.

What It Does

The agent runs a multi-step loop:

  1. Observe: pulls live signals from Dynatrace (open problems, error rates, latency, traffic surges) via the Dynatrace MCP server.
  2. Diagnose: Gemini 3 explains the likely root cause, citing the Dynatrace evidence.
  3. Decide: proposes the smallest safe, reversible action.
  4. Act: executes on WooCommerce/WordPress (publish a "high demand" notice, pause a runaway promo, etc.) but only after explicit human approval.
  5. Verify: re-checks Dynatrace to confirm the signal is recovering.

It's not a chatbot: it uses tools to do real work across two systems, plans across steps, and keeps the operator in control via an approval gate.

How I Built It

  • Google Cloud Agent Builder (ADK) with Gemini 3 as the reasoning layer.
  • The agent is an MCP client to two partner MCP servers:
    • Dynatrace MCP server (read: problems, metrics, traces, logs).
    • WordPress/WooCommerce MCP (write: posts, notices, store actions).
  • Human-in-the-loop gate: a before_tool_callback blocks any write tool and requires explicit approval (approve_pending_changes) before it runs.
  • Observability-first / self-instrumentation: the agent exports its OWN traces + metrics back to Dynatrace over OTLP (spans approval_gate, approve_pending_changes; metric storefront.tool.decisions) so the agent is observable in the same tenant it reads from.
  • Store hosting: WooCommerce on [Amazon Lightsail / managed WordPress]; agent deployed to [Cloud Run].

Partner MCP integration (the "superpowers")

  • Dynatrace MCP server gives the agent real-time production context. It reasons over actual telemetry instead of guessing.
  • WooCommerce/WordPress MCP gives it hands to act on the storefront. The combination is a closed observe -> act loop across two partner platforms.

Challenges

  • Standing up a local store was I/O-bound on our dev machine, so we moved the store to a hosted WordPress and kept reproducible Docker/GCE/Lightsail paths.
  • Token types: Dynatrace uses a Platform Token for the MCP server but a separate Access Token (OTLP scopes) for telemetry ingest. Easy to mix up.
  • Free-tier model quota: Gemini 3 Pro is limited on the AI Studio free tier, so we run on Gemini Flash (same family) for the demo.

Accomplishments

  • A genuine closed loop (observe -> diagnose -> decide -> act -> verify) across two partner MCP servers.
  • The agent is itself observable in Dynatrace: "observability-first" in both directions.
  • A real human-approval gate, so autonomy never means losing control.

What I Learned

  • MCP makes multi-partner agents practical: each system exposes typed tools and the model orchestrates them.
  • Self-instrumentation turns an opaque agent into something an SRE can trust.

What's next

  • Richer remediations (auto-disable a failing plugin, scale messaging).
  • Per-tenant policies for what the agent may do without approval.
  • Multi-store fan-out for a whole mall of tenant storefronts

Built With

Share this project:

Updates