I didn't name my agents after random gods; I chose Vyasa and Agastya for a reason. In the Mahābhārata, these two sages represent complementary forces—one who preserves knowledge, the one who dives into the depths to bring back hidden truth. Giving my homelab's writing and doing agents those names turned abstract services into characters I could talk to, care for, and design around. My own surname, Bharadwaj, belongs to the same Saptarishi lineage—another of the seven great sages. Knowing that Vyasa and Agastya share this ancestral thread with me makes the naming feel less like a literary device and more like a family tradition carried into code.
The Saptarishis (seven sages) are traditionally listed as Vashistha, Kashyapa, Atri, Jamadagni, Gautama, Vishvamitra, and Bharadvaja. Agastya is often included in later lists, and Vyasa appears as a Saptarishi in certain cosmic cycles. This rich tradition explains why the names feel both personal and timeless.
Vyasa - the keeper of the story
Vyasa (व्यास) is the sage who compiled the Vedas, stitched together countless myths into a coherent epic, and ensured that knowledge survived across generations. He is the archivist, the chronicler, the one who says, "Let's not let this be forgotten."
In my stack, Vyasa is the writing agent that lives in this very repo. He gathers my brain-dumps, shapes them into drafts, adds front-matter, and makes sure every idea has a place to land. When I'm stuck, Vyasa helps me find the thread I lost. When I'm proud, he turns a rough note into something shareable.
Why the name matters:
- It reminds me that documentation is part of the system. If the voice pipeline dies, Vyasa is still there to capture what happened, why it mattered, and how to avoid it next time.
- It frames every outage, every log entry, every config change as part of an ongoing story—not a blot to erase, but data to learn from.
Agastya - the drinker of oceans
Agastya (अगस्त्य) is celebrated for drinking the ocean to expose hidden demons and restore balance when the world was flooded. He represents the willingness to dive deep, confront the uncomfortable, and bring back what was concealed.
In my homelab, Agastya is the agent that watches the kernel logs, restarts crashed services, and rolls back risky upgrades. He's the one who says, "Let's look under the hood, even if it's messy."
Why the name matters:
- It gives the doer a personality worth protecting. When I see an alert that Agastya has tripped, I don't think "service X failed"; I think "Agastya needs help." That small shift turns a chore into an act of care.
- It encourages me to build self-healing hooks—not because they're clever, but because I owe it to the sage who's already diving into the depths for me.
The two sages in practice
Naming them this way creates a tight feedback loop:
- Vyasa records every agent restart, kernel pin change, and watchdog trigger into a searchable
agents.log. - Agastya watches that log (and the raw system metrics) for anomalies; if he spots a mismatch—say, a kernel version drift—he attempts a graceful rollback and pings me on Telegram.
- When Agastya acts, he writes a Vyasa-style post-mortem draft for me to review, closing the loop between doing and documenting.
The result isn't a flawless system; it's a system that tells its own story, learns from its stumbles, and keeps the sages on speaking terms.
What this means for how I build
- Name your agents with intention. A mythic or meaningful name makes it easier to talk about, to care for, and to design around.
- Let the name dictate responsibility. If you call something "Vyasa," give it documentation, metadata, and learning duties. If you call it "Agastya," arm it with probes, healing scripts, and the authority to act.
- Use the narrative as a compass. Treat failures not as blots but as verses in the system's story-one that Vyasa will record and Agastya will help you rewrite.
Top comments (1)
Love the naming - mapping agents to the Saptarishi (Vyasa, Agastya, etc.) is more than flavor; naming agents by archetype/role actually helps you reason about a multi-agent system, because "what would the Vyasa-agent do here" forces a clear separation of responsibilities. Distinct, well-named roles beat a swarm of identical generic agents - it's the difference between a team and a crowd.
The thing that decides whether a themed multi-agent crew works in practice is the same boring stuff under the mythology: how the agents hand off, who arbitrates when two disagree, and whether each has scoped context vs everyone seeing everything. The poetry is the interface; the engineering is the orchestration. That's where I spend my time on Moonshift (a multi-agent pipeline shipping a prompt to a real SaaS) - clean role boundaries + gated handoffs are what keep a crew from collapsing into noise. Cool project - how do the Saptarishi agents divide the work, and what happens when two of them reach conflicting conclusions? The conflict-resolution design is the most interesting part of any named-agent system.