# When not to use Meguro

Meguro is deliberately narrow. It is the wrong tool when:

## Scope and proof boundaries

**You need proof of live performance.** Receipts are rehearsal evidence from a simulated store — not forecasts, certifications, or evidence of market demand. Meguro says this in-band because it's true.

**Your critical path lives outside the modeled subset.** Meguro models a subset of the Shopify Admin API and refuses the rest with a teaching error rather than faking behavior. If the calls your app depends on aren't in the modeled subset — the refusal enumerates it, and the [compatibility table](/help/admin-api-surface.html#admin-api-surface) lists it — Meguro cannot exercise them, and won't pretend to.

**You're testing storefront, themes, or checkout UX.** A practice store is commerce state behind an Admin-shaped API, not a rendered storefront.

**You're load-testing.** The throttle model exists to exercise your agent's backoff discipline, not to benchmark a platform.

**Your agent never touches commerce state.** If it reads a static catalog once, a fixture file is cheaper.

**You want someone to run your agent for you.** Meguro never executes your agent; it provides the store and the record. Bring your own agent — that's the design, not a gap.