Projects Don't Start Empty Anymore

The old version of project setup in AGX had a very specific kind of friction: nothing was technically broken, but the product kept asking you to think at the wrong level.

You’d create a project, land in an empty workspace, and then start building the company one agent at a time. Backend engineer. Frontend engineer. Reviewer. Product person. Maybe a growth writer if you were feeling ambitious. Then came the follow-up work: assign skills, decide who should handle what, remember which agents belonged together, and hope the routing layer made the same mental grouping you did.

It worked, but it felt like wiring a team together with loose cables.

Over the last few days, that changed. The important part isn’t just that AGX added a team picker. It’s that the product finally started treating a team as the thing you compose a project from.

The old problem wasn’t missing features

If you look at the raw work that landed this week, it’s easy to read it as a pile of separate tickets:

• a team template catalog
• team CRUD APIs
• YAML export/import
• a team picker modal
• a review-and-customize flow
• a new Teams page
• a team-centric sidebar
• task routing by team tag
• adopt/replace flows for unassigned agents

That’s accurate, but it’s not the story.

The story is that AGX had outgrown a flat list of agents.

Once you start using the system seriously, you stop thinking in terms of “I have twelve agents.” You think in terms of “I have an engineering team, a product team, and two weird leftovers I haven’t placed yet.” The UI wasn’t reflecting that. The data model wasn’t reflecting it strongly enough. Setup definitely wasn’t reflecting it.

So the model got sharper.

Instead of asking users to manually recreate the same org chart every time, AGX now ships a catalog of eight team templates, including engineering, product, design, infra, growth, research, data, and security. Each one comes preloaded with agents and skill profiles tuned for the kind of work that team is supposed to do.

That means the first meaningful action in a new project is no longer “add an agent.” It’s “pick a team shape.”

A new project now starts with a structure

The change sounds small until you compare the before and after.

Before, project setup looked something like this:

Create project
  -> empty workspace
  -> add agent
  -> add another agent
  -> assign skills
  -> group them mentally
  -> repeat until the project feels usable

Now it looks more like this:

Create project
  -> open Teams
  -> pick Engineering or Product or Design
  -> get a working team immediately
  -> customize from there

That removes a surprising amount of dead cognitive load.

The user no longer has to remember which roles belong together before they can even begin. AGX makes a strong first suggestion. And because the suggestion is represented as real project structure, the rest of the app can act on it instead of treating it like a naming convention the user invented.

The UI had to move around the new idea

The strongest sign that this is a real product change and not just a modal is what happened to the navigation.

The sidebar used to reflect the old worldview: projects contained a fairly flat pile of things, and agents were one of those things. The recent navigation restructure pushed AGX into a team-first layout:

• Overview
• Objectives
• Teams
• Linear
• Scheduled Tasks
• Chat
• Settings

That sounds cosmetic until you notice what’s gone. The flat agent list is no longer the center of gravity. Teams are.

And once the app does that, a lot of awkward edge cases become easier to reason about. If a project already has agents that aren’t in any team, the new Teams view doesn’t pretend that’s fine. It calls them out as unassigned and gives you two explicit paths:

• adopt them into a team
• replace them with a preset

That is a better product decision than silently letting the mess accumulate. It acknowledges the real state of the project and gives it a cleanup path.

Routing got more honest too

This part matters more than it sounds.

One of the changes in the AGX repo this week was task routing by team tag in frontmatter. That means a task can now say, in effect, “this belongs to engineering,” and the routing layer narrows the candidate pool to that team’s roster before it decides who should take the work.

The shape is simple:

---
team: engineering
---

That’s the kind of feature that looks small in a changelog and large in practice.

Before this, “team” mostly lived in the user’s head. You could intend something for engineering, but the system’s actual unit of selection was still a project-wide list of agents. Now the intent is explicit, and the runtime can honor it.

That closes a gap between how humans think about the org and how the software dispatches work inside it.

YAML export is the other half of the story

The other important piece is portability.

AGX’s new team setup isn’t just stored in the runtime database. It can also be exported and imported as YAML. That sounds like a utility feature, but it changes the posture of the whole system.

It means your project structure isn’t trapped inside one running instance. A team setup can become an artifact. Something you version. Something you carry to another project. Something you tune over time until “our engineering team” becomes a reusable operating shape instead of a one-off arrangement assembled from memory.

The vault notes describe this pretty clearly: the DB is the runtime, YAML is the portable artifact, and there is no fake auto-sync pretending those are the same thing. That’s a good boundary. It keeps the runtime simple while still letting the org structure travel.

What changed for the user

The real upgrade here is not that AGX can represent teams now. It’s that the product stopped making the user do translation work.

Before:

• users thought in teams
• the UI showed agents
• routing mostly saw agents
• portability barely existed

Now:

• users think in teams
• the UI starts with teams
• routing can target teams
• configuration can move as teams

That’s what product progress looks like when it’s real. Not “more features.” Fewer mismatches.

A lot of software gets harder to explain as it grows because each new capability adds another layer of exceptions. This week AGX went the other direction. It got easier to explain:

You start a project by adding a team. Teams contain agents. Tasks can target teams. Teams can be exported.

That sentence wasn’t really true a week ago. Now it is.

What’s next

I think this change will matter most on the second and third projects people create, not the first.

The first time through, team presets make setup faster. The second time through, they make patterns reusable. That’s when AGX stops feeling like a blank orchestration surface and starts feeling like a company you know how to instantiate.

And that’s the bigger shift underneath all this work: AGX is getting less interested in helping you manually arrange agents, and more interested in helping you stand up an organization with a shape.