The first version of PractOps had one agent. We called it "the AI assistant." It could help with operations, pipeline tracking, people management, and market research. It was, in theory, everything.
In practice it was a mess. When users asked it a question about hiring, it would sometimes answer in terms of pipeline stages. When they asked about a client, it would blend revenue data with HR context. It wasn't wrong, exactly, all those things are related in a staffing business. But it wasn't reliably useful, which is worse than being wrong in a predictable way.
The insight: scope is a feature
The fix wasn't technical. We didn't retrain anything or change the underlying model. We split the single agent into four, gave each one a clear job, and named them.
The naming was almost accidental at first, an internal shorthand so we could talk about "the ops one" and "the revenue one" without confusion. But something interesting happened when we started referring to agents by name in the UI and in documentation: users immediately understood what each agent was for, and they stopped asking agents questions that were outside their domain.
When you name something, you're making a promise about what it does. That promise creates an expectation. That expectation shapes how people interact with it. The interaction shapes what the agent actually gets good at over time.
How we chose the four domains
Staffing and workforce operations have a natural topology. There are four distinct functions that every firm runs, and they have almost no overlap in day-to-day execution even though they're deeply interdependent strategically:
- Business operations, the machine itself. Workflows, documents, reporting, task routing. This is Stella's domain.
- Revenue and pipeline, from first contact to signed contract. Lead scoring, follow-up, forecasting. Luna owns this.
- People operations, the full candidate and employee lifecycle. Sourcing, onboarding, compliance, performance. Nova handles it.
- Market intelligence, competitive data, industry trends, client context. Orion pulls this together.
These aren't arbitrary. They map to the four departments you'd find at a mid-size staffing firm: ops, business development, recruiting, and strategy. The agents were designed to slot into org structures that already existed.
What the names actually do
Naming is a product decision, not a branding one. Here's what each name does in practice:
They create memorable accountability
When something goes wrong in the pipeline, users say "Luna flagged that." When onboarding slips, they say "Nova missed the compliance check." This sounds like a small thing, but named accountability drives adoption in a way that "the AI flagged it" doesn't. People interact differently with something that has a name.
They enforce scope at the design level
When we're building a new capability, we have to answer "which agent does this belong to?" That question is harder than it sounds, and it forces us to be precise about what each domain actually covers. Features that don't have a clear home get scrutinized. That scrutiny has kept the platform focused in a way that a single all-purpose agent never would have.
The next phase is agent-to-agent collaboration, Orion surfacing a market shift, Luna automatically adjusting pipeline priorities, Nova updating sourcing criteria. The agents already share context. Teaching them to act on each other's outputs is the next leap.
The white-label question
One thing we didn't anticipate: when companies deploy PractOps under their own brand, many of them rename the agents. Stella becomes "Alex." Orion becomes "Scout." That's fine, the structure matters more than the names. What they can't change is the four-domain architecture, and that's the part that actually makes it work.
If you're building multi-agent systems, the lesson from PractOps is this: define the domains before you define the agents. The name comes last. The scope comes first.