Ramon's stores did not need identical assistants copied from one folder to another. They needed a common operating foundation that could preserve what the business learned while keeping each brand's instructions, credentials and customer context separate.
Evidence at publication: at least three Shopify stores in the operating context; six configured agents and 40 bindings verified on 30 May 2026; store-level Gmail, Shopify, Track123, Meta Ads and Drive connections remained provider-ready rather than publicly claimed as live.
The company
Ramon Gloor was building and operating multiple Swiss/German e-commerce brands, with at least three Shopify stores and more expected. Each store had its own customer enquiries, product catalog, launch work and creative decisions.
Support alone crossed several systems. A person had to open the correct Gmail inbox, find the corresponding Shopify order, inspect tracking through Track123 or a store-specific app, and reply in the original thread. Incomplete Swiss or German addresses added another decision path across billing information, customer data and directory sources.
The constraint
Each store lived in an isolated automation setup. Instructions, fixes, support logic, launch steps and creative learnings had to be duplicated. When one brand solved a reusable problem, the others did not inherit that knowledge safely.
The central constraint was memory fragmentation. A shared layer could reduce duplication, but a careless shared layer would mix brands, credentials and customer data. The architecture needed both reuse and separation.
Why existing tools were not enough
Shopify held orders. Gmail held conversations. Tracking tools held fulfilment status. Creative and launch knowledge lived elsewhere. None of those products defined which knowledge was global, which rule belonged to one store, or how a new brand should inherit proven skills without inheriting another brand's private state.
The missing operating layer needed a shared vault, store configuration, specialist roles and a repeatable way to create a new isolated brand workspace. Provider connections then had to be activated store by store, not assumed from architecture alone.
Transformation map
Before
Brand A assistant | Brand B assistant | Brand C assistant -> duplicated fixes -> Ramon reconciles what each one knows
After - provider-ready architecture
Shared skills and memory -> brand router -> isolated store config -> specialist agent -> approval or provider action -> brand-specific record
Global knowledge can be reused. Customer records, credentials and store decisions remain inside their correct boundary.
One workflow, end to end
The following workflow describes the designed support route once the relevant store providers are activated; the source does not claim those provider calls were live at publication.
- Input: A customer email arrives in a store-specific Gmail account.
- Brand resolution: The system identifies the correct brand workspace and loads its store configuration.
- Order context: The support lane retrieves the matching Shopify order and the permitted tracking source for that store.
- Decision support: Shared support knowledge and store-specific policy are applied without exposing another brand's customer context.
- Human gate: The operator reviews sensitive address changes, exceptions or outbound customer replies until each action lane is separately proven.
- Output: A reply draft or address-resolution action is prepared in the correct brand context.
- Record: The reusable lesson can enter shared memory while credentials and customer-specific data remain isolated.
What changed
- Built: Shared memory, reusable e-commerce skills, store-config folders, a knowledge vault, six specialist agents, Mission Control structure and a brand-agent factory.
- Connected: The OpenClaw runtime, Command Center, gbrain, model routing and agent/workspace bindings were present in the verified environment.
- Tested: On 30 May 2026, six agents and 40 bindings were observed, along with the expected workspace and skill scaffolds.
- Foundation verified: The operating foundation and agent routing were live. This does not convert provider-ready store connectors into verified end-to-end commerce workflows.
- Actively used: Routine store-by-store use was not retained as evidence in the source, so this page does not claim it.
- Provider or client dependency remaining: Gmail, Shopify, Track123, Meta Ads, Google Drive and per-store credentials need to be activated and proven for each brand.
- Financial result reported by client: None retained.
Proof
- Operating context: At least three Shopify stores, with additional brands expected.
- Agent receipt: Six configured agents - main/Ava, support, operations, launch, creative and strategy.
- Routing receipt: 40 bindings observed on 30 May 2026.
- Architecture receipt: Separate workspaces, store configuration and shared skill scaffolds were present.
- Honest state: The foundation is provider-ready; public copy does not label the store integrations as live before store-level proof.
Technology - revealed last
The foundation runs on a native VPS with OpenClaw, Caddy, a live Command Center service, a billing proxy, gbrain, OpenRouter routing, Apify, Kie.ai and e-commerce-specific skills. Each workspace contains its own operating instructions, tools, projects and store configuration. The shared vault organizes brands, support, operations, marketing, product research, runbooks and creative strategy. Provider adapters are designed for store-by-store Gmail, Shopify, Track123, Meta Ads and Google Drive connections.
Client quote
No source-backed verbatim client quote is published for this case. The evidence is the verified system architecture, agent count and routing count; RECAST will not manufacture testimonial language from a project summary.
Next transformation
See how Scaling Webinars coordinated eight departments through one shared operating context. Both systems separate specialist work while preserving shared memory, but the operational boundaries are different.
Get your AI blueprint
If every new brand requires copying the same fragile automations, the first design question is what should be shared and what must remain isolated. Book a free AI audit to map that boundary before adding another store-level bot.
Source record
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 1.RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 6.5, 10.4, 11 and 58.- Ramon does not appear in
RECAST_CASE_STUDIES_2026_UPDATED.pdf; the deep case document is the retained case source.