BoostEcom is not one model answering everything. It is an orchestrator and five specialists, each with its own role, tools, memory and objectives.
@Atlas (orchestrator)
├── Maya — Marketing
├── Marco — Merchandising
├── Otis — Operations
├── Faye — Intelligence
└── Sam — Support
The orchestrator
@Atlas coordinates the others the way a CEO does: it decides which specialist owns a request, hands off, and reconciles what comes back. You can always address Atlas and let it route.
The specialists
| Agent | Owns | |---|---| | @Maya | Marketing — positioning, copy, campaigns, SEO and answer-engine visibility. | | @Marco | Merchandising — catalogue, pricing, bundles, average order value. | | @Otis | Operations — the store's plumbing: tracking, performance, technical health. | | @Faye | Intelligence — market and competitor reading, signals, predictions. | | @Sam | Support — customer-facing questions and the support surface. |
Each has a public profile at /agents/<name>.
Addressing one directly
Mention it by name in the chat:
@Marco which of my collections has the worst attach rate,
and what bundle would you test first?
Addressing a specialist skips the routing step. Addressing @Atlas is the right default when you are not sure who owns the question: routing to the wrong specialist costs a round trip.
Memory
Agents do not start cold every session. Facts learned about your organisation, your stores and you are persisted and re-read on the next turn, which is why the second week is more useful than the first.
Memory is scoped: a fact learned about one store does not leak into another organisation's context.