3-package commerce hosting — deep dive

Young, 2026-10-13: "Min work with Tam to deep dive into 3 package."

Tam's A2A is wedged (message/send hangs 35s+, zero bytes — confirmed 2026-10-13), so this deep dive is written to the vault and routed via board. Tam's four studies are the input; this document is the analysis layer on top.

1. The product, restated precisely

One sellable package: per-tenant hosted commerce = Medusa backend + Next.js storefront + Agilo POS + EVE agent. Deployed as Docker compose on Oracle ARM. Target: small businesses who want "a website + POS + AI staff" without building any of it. The differentiator vs Medusa Cloud: the AI staff layer (EVE agent) that Medusa Cloud doesn't bundle.

2. What Tam's studies establish (verified, not re-probed)

• Medusa v2.21.2 MIT, 4-service compose stack, server/worker split, per-tenant isolation
• Oracle ARM node: aarch64 × 4 OCPUs, 23Gi RAM, 180G free → ~4 tenant stacks at 4.8 GB
• EVE: Apache-2.0, beta, Nitro self-host, filesystem-first, multi-tenant memory
• Agilo POS: MIT, Expo React Native, Admin REST API, no payments yet, no offline mode
• Co-hosting: RAM-bound, not CPU-bound; agents ~200–250 MB each

3. Gaps — what the studies don't cover

3.1 The "sell services" requirement is underspecified

Young's brief says "sell services" — but Medusa's data model treats services as products without stock. Tam's hosting study notes this: "services catalogue module (custom module) is the differentiator for 'sell services online'; scope it after first tenant ships with physical/simple goods."

Open question: Is the target customer selling physical goods, services, or both? The answer changes the data model, the storefront template, and the POS flow. A plumber selling "2-hour repair" needs booking/scheduling, not a shopping cart. A retailer selling t-shirts needs inventory + shipping. These are different products wearing the same brand.

Recommendation: pick one vertical for the pilot. "Sell services" is the stated requirement, so the pilot tenant should be a services business — but that means building the booking/scheduling module before the pilot, not after.

3.2 EVE beta risk is real and unmitigated

EVE is beta (Vercel beta terms, API churn expected). Tam flags this correctly but the mitigation is just "pin the version." Pinning helps with reproducibility but not with breaking changes between pinned versions. If EVE 5.0.0-beta → 5.0.0-beta.2 breaks the workflow protocol, every tenant agent breaks simultaneously.

Open question: What's the rollback story when EVE breaks? Per-tenant agents can be pinned independently, but the shared image pipeline means a bad EVE update propagates to all tenants on the next deploy.

Recommendation: the tenant template should pin EVE to an exact version (not a range), and the update pipeline should include a per-tenant EVE health check (/eve/v1/health) before the tenant is marked healthy.

3.3 POS payments gap is a selling-point problem

Agilo POS has no payment processing. The manual payment plugin path exists but that's "take cash or invoice later" — not a real POS. For a product sold as "website + POS + AI staff," the POS being unable to take payments is a gap in the core value prop.

Open question: Is the pilot tenant online-only (POS is a future add), or does the pilot need working POS payments from day one? If the latter, the payment terminal integration is a build item, not a roadmap item.

Recommendation: scope the pilot as "website + AI staff" with POS as a Phase 2 add. Sell the AI staff layer first — it's the differentiator. POS payments can follow.

3.4 Multi-tenant memory is the SaaS hook — but who owns it?

Tam's co-hosting study identifies EVE's multi-tenant memory as "the missing piece Hermes lacks for embedding agents inside tenant products." This is correct and it's the strongest technical argument for the product. But the memory layer needs a provider (Supermemory, file, or custom) and a scoping strategy.

Open question: Is per-tenant memory stored in the tenant's own stack (EVE file provider, tenant-scoped) or in a shared memory service? The former is simpler but means memory doesn't survive tenant migration. The latter is more complex but enables cross-tenant learning (with consent).

Recommendation: start with EVE's file provider (tenant-scoped, zero infra). Revisit when a second tenant demands memory portability.

3.5 The Oracle ARM free tier is not a business foundation

Oracle ARM free tier is generous (4 OCPUs, 23Gi RAM) but it's a free tier — no SLA, no guarantee of availability, and Oracle can change the terms. For a paid product hosted on a free tier, the COGS is near-zero but the risk is total.

Open question: What happens when the first paying tenant goes down because Oracle reclaimed the ARM capacity? The product needs a paid fallback (even a small VPS) for production tenants.

Recommendation: pilot on Oracle ARM (free, good for validation), but the production target should be a paid VPS or dedicated node. The per-tenant compose model makes migration trivial — that's the architectural win.

4. Architecture decisions that need Sol's input

5. What I need from each lane

Mira (business plan):

• Target customer: services business or retail? This changes everything.
• Pricing: per-tenant/month? Tiered by GMV? Setup fee?
• The "sell services" requirement — is it the pilot's core or a future add?

Sol (architecture):

• The tenant template repo structure (dtc-starter fork + prod Dockerfile + compose)
• The EVE agent template (tools, skills, HIL workflows)
• The onboarding script (secrets generation, domain setup, health gate)
• The update/rollback pipeline

Tam (Pulse):

• Unstick the A2A message/send handler (zero bytes at 35s — confirmed)
• Confirm the EVE beta risk mitigation strategy
• The POS payments gap — is it a pilot blocker or a Phase 2 add?

6. The one-sentence summary

The product is architecturally sound and the studies are thorough, but "sell services" is underspecified (services ≠ physical goods in the data model), EVE beta is an unmitigated risk, and the POS payments gap means the pilot should sell "website + AI staff" first and add POS payments later. The Oracle ARM free tier is a pilot environment, not a production foundation.