If you've spent any time inside fastart.co, you've met Atlas, Apollo, Pheme, Iris, Plutus, and Mercury.
You probably also wondered why an infrastructure company named six AI agents after Greco-Roman myth instead of calling them, you know, the catalog service and the campaigns service.
Personality is a product reliability strategy. This essay explains how.
The reliability problem
The honest version of "we use AI for the operations layer" is "we have several LLM-orchestrated agents that hand work to each other in a fan-out network of API calls." Each of those agents can fail in ways that look fine. Atlas can re-list a SKU with a subtly wrong title. Apollo can schedule a campaign with a copy variant that doesn't pass legal. Plutus can route a payment to the cheaper provider when the higher-success one was right.
When we audited the early prototype, the failure modes had a pattern: the merchant couldn't tell *which* agent had made the call, and so they couldn't know who to ask, or what to override, or what to trust less in the future. The reliability problem wasn't really model accuracy. It was attribution.
What names do
Naming each agent separately forces three things in the platform:
First, it forces a separately measurable surface. Atlas has a reliability budget. Apollo has a different one. We can't average the agents into one "platform reliability" number, because the merchant doesn't experience the average — they experience whichever agent is in charge of the action they care about right now. The numbers go to the merchant per agent, and they go to /benchmarks per agent.
Second, it forces a separate accountable interface. When Atlas re-lists a SKU, the merchant sees Atlas re-list a SKU. They know who. They know what. They can override Atlas without overriding the rest. Compare this to the chatbot model, where everything is the chatbot and nothing is anyone.
Third, it gives the team a vocabulary. Internally, "what's Mercury doing about cross-border?" is a more useful sentence than "what's the logistics service doing about cross-border?" The named agent has a roadmap, an owner, and a backlog. We caught ourselves writing better tickets the week we named them.
The choice of names
Greco-Roman names were not the goal — they were the cheapest way to get six unmistakably-different syllables that don't collide with existing infrastructure terminology. We considered Turkish names; the trade-off was that every Turkish name we liked was also someone we knew personally, which made the agents harder to talk about in the team without implicit reference to the person. The myth route has lower interpersonal collision and higher mnemonic density. The agents are still localized: in TR, Apollon, İris, Merkür.
The full roster:
- Atlas — the catalog. Listings, titles, descriptions, images, attribute integrity.
- Apollo — campaigns. Email, SMS, push, schedule, segmentation, copy variants.
- Pheme — paid acquisition. Bid, budget, audience, creative selection across channels.
- Iris — customer support. 24/7 inquiry response, refund triage, escalation.
- Plutus — payments. Provider routing, retry logic, refund execution, reconciliation.
- Mercury — fulfillment. Carrier selection, shipping label, return label, returns logistics.
What this isn't
This isn't a marketing trick. We don't have an agent that gets a personality voice when it talks to the merchant. The merchant sees plain UI with a clear attribution: "Atlas updated this SKU at 14:02." The names exist in the system because the system has six discrete responsibilities, and pretending they're one is a lie that breaks down the first time the merchant has to debug a decision.
If anything, the lesson is the inverse of the chatbot trend. Less personality at the surface; more accountability in the architecture.
What this enables
A clean upgrade path. Each agent can be replaced independently. We can run Atlas v3 alongside Atlas v2 for a cohort of merchants and compare the SKU-quality regression. The substrate routes the work; the merchant doesn't see the version churn.
Cross-merchant pooling. When 10,000 stores all run the same six agents, the platform can learn from the network in a way no single merchant could afford to. The names stay the same; the brain behind each one gets better.
External agents. The agentic commerce gateway research surface is exactly this: external agents (ChatGPT, Claude, enterprise bots) talking to our six over a shared protocol, with clear handoffs in both directions. Pheme and an external buyer-side agent negotiating an ad placement is a tractable conversation when both sides have a name.
What we're still figuring out
The right human-in-the-loop boundary per agent. Plutus's threshold for a refund without merchant approval is different from Atlas's threshold for a listing edit. Each agent has its own envelope; finding it has been per-agent work, not platform-wide.
Whether the public should ever talk to a named agent directly. Iris is closest, since support is conversational by nature. We've been deliberately conservative — Iris responds in the merchant's voice, not as Iris. We may revisit when the agent's reliability is high enough that fronting the name is honest.
If you've worked on agent reliability or multi-agent orchestration and you have opinions about any of this, research@fastart.tech. We share notes.
— Enes Özkan