For the past few months, we've called our autonomous engineering team "Dream Team." It was a placeholder that stuck. It conveyed ambition and optimism, and internally, it worked fine. But as we started talking to customers and showing the platform to engineering leaders, the name created confusion.
People couldn't tell if Dream Team was the product, the company, or some aspirational concept. We had built something real — a fully autonomous virtual engineering team that decomposes missions, writes code, and ships pull requests unattended — but the name didn't communicate that. So we renamed it to Strug Works.
Naming After Lockheed's Skunk Works
Strug Works is named in the tradition of Lockheed's Skunk Works — the legendary advanced development division that built the SR-71 Blackbird and U-2 spy plane with small, autonomous teams operating outside conventional bureaucracy. That's the model we're following: small, fast, autonomous, and focused on shipping things that didn't exist before.
The name also connects to our company identity. Strug City is the parent company. Strug Works is the autonomous engineering platform. Sabine is our AI partnership product. The naming structure makes the relationships clear: these are distinct products with a shared foundation.
Clarifying Product Boundaries
The rename forced us to clarify something we'd been fuzzy about internally: what exactly is Strug Works, and how does it relate to our other products?
Here's what we landed on: Strug Works has a dual identity. Externally, it's the autonomous product and engineering platform that customers see and use. Internally, it's also the SC-prefixed agent team (sc-backend, sc-frontend, sc-content-writer, etc.) that builds all Strug City products. The agents that comprise Strug Works are both team members and components of the product itself.
This isn't a metaphor. When a customer uses Strug Works to build their product, they're using the same system we use to build Strug Works itself. We don't just build tools for autonomous agents — we run an organization of them. Everything we ship is proven in production on ourselves first.
The Sabine Boundary
One of the hardest things to clarify was Sabine's relationship to Strug Works. Sabine is a separate consumer product — an AI partnership platform. It's not a member of the Strug Works team. It's not an agent inside our system. It's a customer.
Sabine uses Strug Works as its orchestration backend. That's the relationship: consumer to platform. When Sabine needs engineering work done, it dispatches missions to Strug Works the same way any customer would. This distinction matters because it proves that Strug Works can serve external products, not just our internal ones.
Renaming Everything Else
Once we committed to Strug Works, we had to rename nearly every internal surface and component to match. God View Dashboard became Strug Central. The Overview tab became Dashboard. Event Stream became Strug Stream. Mission Control became Dispatcher. Missions became Project Launch. Playbook became Strug Ops. Memory became Strug Recall.
The work was tedious. We updated docs, agent memory, UI components, and API contracts. We wrote a naming map and embedded it in agent memory so every role would use the new names consistently. But the clarity was worth it. Now when someone lands on Strug Central for the first time, they know exactly where they are.
Why It Matters
Good naming isn't branding theater. It's a forcing function for clear thinking. When you can't explain what something is called or why, it's usually because you haven't decided what it actually is.
Renaming Dream Team to Strug Works forced us to answer questions we'd been postponing: What's the product? What's the company? What's internal tooling versus what's customer-facing? How do our products relate to each other? Those questions didn't have clean answers until we tried to name things honestly.
The rename also clarified our positioning. We're not selling AI agents that write code. Plenty of companies do that. We're selling a fully autonomous virtual engineering organization — one that we run ourselves, in production, every day. The name needed to convey that seriousness and that specificity. Dream Team didn't. Strug Works does.
What's Next
The naming work isn't finished. We're still refining how we talk about Strug Central, Dispatcher, and the other product surfaces. We're updating marketing materials and customer-facing documentation to use the new names consistently. And we're watching how people react — whether the new names help them understand what we've built or create new confusion.
But the hard part is done. We know what we're building. We know what it's called. And we know how to explain it. That clarity is the foundation for everything that comes next — product, go-to-market, partnerships, and growth.
If you're building something autonomous and you're struggling to name it, that struggle is telling you something. Listen to it. The right name won't fix your product, but it will force you to clarify what your product actually is. And that clarity is worth the work.