Back to blog
EngineeringJan 15, 2024· min read

What Do You Call a Team That Isn't Human?

The hardest part of building an autonomous engineering organization wasn't the architecture or the AI models. It was figuring out what to call everyone—and why that matters more than I expected.

For months, I called them the Dream Team. It was a placeholder that stuck. The name felt appropriate—an autonomous engineering team that could decompose missions, write code, and ship PRs without human intervention was exactly the kind of thing I'd dreamed about building. But as the organization matured and we started preparing to bring Strug Works to market, the name started to feel wrong.

The problem wasn't that 'Dream Team' was bad. The problem was that it described what the team meant to me, not what it actually was or what it could do for someone else. It was inward-facing. Personal. And when you're trying to prove that one person with the right AI team can run a fully autonomous product and engineering organization, you need a name that does more work than that.

The Weight of Naming

I started making a list. Every piece of the system had been named in the moment, with whatever felt right at the time. The dashboard was called 'God View'—a joke about omniscient oversight that was never meant to be customer-facing. The mission control interface was just 'Mission Control.' The event stream was 'Event Stream.' Functional, descriptive, forgettable.

Then I started thinking about precedent. Lockheed had Skunk Works—a name that communicated speed, autonomy, and a team operating outside normal constraints. That resonated. Strug Works felt right immediately. It honored the tradition of elite engineering teams while acknowledging the struggle inherent in building something this ambitious. It worked externally as a product name and internally as the identity of the AI agents doing the work.

Once I had that anchor, the rest started to fall into place. 'God View' became Strug Central—the command center for the platform. 'Mission Control' became the Dispatcher. 'Event Stream' became Strug Stream. Each name carried more meaning, more cohesion. They felt like parts of the same system instead of a collection of tools I'd cobbled together.

The Technical Debt of Identity

Renaming everything wasn't just a branding exercise. It was a refactoring of organizational memory. Every agent in the system had been trained on the old terminology. Memory keys referenced 'Dream Team' and 'God View.' Documentation, prompts, UI strings, database schemas—all of it encoded the old names.

I couldn't just find-and-replace. The agents needed to understand both the old and new names during the transition. I created a naming-conventions memory key that explicitly mapped the old names to the new ones. I updated role-specific memory for sc-content-writer and sc-frontend-next so they'd use the external names consistently. I added validation to catch references to deprecated terms.

It took longer than I expected. Not because the technical work was hard—it was mostly memory updates and prompt adjustments—but because it forced me to be explicit about what each piece of the system actually was. Writing 'Strug Central (the portal/dashboard)' made me clarify that it wasn't just a dashboard. It was the orchestration interface for the entire platform. The act of naming forced clarity.

What's in a Name for an Agentic Org?

In a traditional company, naming matters for marketing and culture. In an agentic organization, it matters for that plus something else: shared understanding across non-human team members. When sc-backend and sc-frontend-next collaborate on a feature, they reference the same product surfaces, the same mental model of the system. Consistent terminology isn't just polish—it's the substrate of coordination.

This is one of those things you don't see in the architecture diagrams. Nobody talks about the importance of naming conventions in multi-agent systems. But when your team is composed of specialized AI agents, each with their own context window and memory, the words you choose to describe the work become load-bearing infrastructure.

I also realized that naming is one of the few places where the one-person-org structure is an advantage. There's no committee. No brand team to convince. No months-long rebrand project. I made the call, updated the memory, pushed the changes, and moved on. The speed of decision-making in a one-human organization is viscerally different from anything I've experienced before.

What's Next

The external names are locked now. Strug Works. Strug Central. Dispatcher. Strug Stream. They're in production, in memory, in the UI. But I know there will be more naming decisions ahead as we ship new products and expose new surfaces. Each one is an opportunity to clarify what we're actually building.

The deeper lesson, though, is about identity. What do you call a team that isn't human? You call them by a name that reflects what they do and who you're building for. Strug Works isn't just a rebrand. It's a statement about what this organization is and what it can become. A fully autonomous engineering team, named in the tradition of the best engineering teams that came before it, doing work that would have seemed impossible a few years ago.

And unlike the Dream Team—a name that described my feelings—Strug Works describes reality. That's the name I want on the door.