跪拜 Guibai
← Back to the summary

TeamAgentX Turns AI Coding Into a Group Chat Where Agents Hand Off Tasks Like a Dev Team

Foreword

It's been a while since I last published an article. Recently, I've been developing a multi-agent intelligent collaboration software — TeamAgentX.

The project has basically taken shape, so I want to share it with everyone in this article: why I built it, how it differs from our everyday use of ChatGPT, Claude Code, Codex, and WorkBuddy, and whether multiple AIs can truly collaborate like a real team.

The project is open-source and free to use; you need to configure your own LLM key.

Official website: https://teamagentx.com

Project repository: https://github.com/dbfu/teamagentx

Why Build TeamAgentX?

Over the past year, I've heavily used Coding Agents like Claude Code and Codex.

They are already very powerful.

Before, implementing a feature required analyzing requirements myself, designing the database, writing the backend, writing the frontend, testing, and fixing bugs.

Now, often you just need to tell the Agent:

Help me implement this feature.

Then it can read the code, modify files, execute commands, and run tests on its own.

But the more I used them, the more I clearly felt one problem:

No matter how strong a single Agent is, it's essentially still one person working.

A complex task actually contains the work of many different roles:

Requirements analysis, architecture design, frontend development, backend development, code review, testing, researching, writing documentation...

If all these things are done by the same Agent, several problems arise.

First, the context becomes longer and longer.

Second, one Agent simultaneously taking on roles like "designer, developer, reviewer" can easily end up writing something and then proving itself right.

Third, complex projects are hard to parallelize.

Fourth, and this is a very real problem:

Expensive.

If all tasks use the strongest model, token consumption will be very high.

So I started thinking about a question:

Can we assemble an AI team, just like a real software company?

For example:

The architect can use a more capable model, while a large number of execution-oriented tasks are handed off to lower-cost models.

Humans only need to be responsible for proposing goals and making key decisions.

This was the initial idea behind TeamAgentX.

It Looks More Like an "AI Feishu Group"

TeamAgentX doesn't adopt the complex flowcharts found in traditional workflow products.

I ultimately chose an interaction method that almost requires no learning:

Group chat.

You can create a group and then pull different AI assistants into the group.

For example, create a "TeamAgentX Development Group":

Each assistant can have its own:

Model, system prompt, skills, tools, and long-term memory.

The entire group corresponds to one project and a shared working environment.

From a product model perspective, I hope it's closer to:

One project = one group, a group of AIs = one project team.

This is also one of the biggest differences between TeamAgentX and traditional single-Agent products.

The Simplest Way to Use: Just @ an Assistant

For example, you can say in the group:

@Architect Help me analyze the user login module and design a revamp plan.

The architect will read the project code and then start analyzing.

If it's just a simple task, it ends here.

But if it's a complex task, the really interesting things are just beginning.

After the architect finishes the analysis, they can hand off different tasks to other assistants.

For example:

The frontend login state management needs adjustment. The backend token refresh mechanism also needs redesigning.

Then hand the tasks off to the frontend and backend engineers respectively.

These two assistants will continue working.

After completion, they can be handed off to the testing or review assistant for further verification.

In other words:

Tasks don't always need a human to manually pass the baton; Agents can continue the task handoff among themselves.

TeamAgentX has currently upgraded this handoff from simply parsing @name in chat text to structured mention_agents tool calls. This means when an Agent decides "who to hand what task to," it explicitly registers the target assistant and specific task, rather than having the system guess from natural language afterward.

The Hardest Part of Multi-Agent Isn't the "Multi"

When I first started this project, I thought the biggest difficulty would be:

How to make multiple Agents run simultaneously.

Later I found out that wasn't it at all.

The real difficulty is:

How to prevent multiple Agents from running wild.

For example, it's easy for this to happen:

Architect @Engineer.

Engineer finishes and @Tests.

Tester finds a problem and @Engineer again.

Engineer modifies and @Tests again.

Without a control mechanism, two Agents could easily keep calling each other.

Even one Agent dispatching five or six Agents at once, and those five or six continuing to dispatch downwards, quickly becomes an exponentially expanding Agent network.

Tokens will also explode instantly.

So TeamAgentX spent considerable effort later solving one problem:

Collaboration must be able to converge.

Currently, the system establishes a complete task lineage for an Agent collaboration session and limits dispatch depth, single fan-out, and the dispatch budget for the entire task chain, while also allowing a limited number of reasonable callbacks to prevent infinite loops between Agents.

This part might seem unremarkable, but I think it's actually the key to whether multi-Agent can truly be used in real projects.

An Interesting Design: Whoever Dispatches Tasks Is Responsible for Closing the Loop

Suppose the architect dispatches two tasks simultaneously:

@Frontend Engineer: Complete the login page revamp @Backend Engineer: Complete the token refresh interface

At this point, the two engineers can execute their respective tasks.

But they won't infinitely expand outward.

Once both tasks are completed, the results will be summarized back to the assistant who initiated this parallel task batch.

That is:

Whoever breaks down the tasks is ultimately responsible for closing the loop.

After the architect receives the results from the two engineers, they decide:

Continue development?

Hand over to testing?

Or is the task complete?

This way, the entire multi-Agent network is no longer a group of AIs chatting randomly, but gradually forms:

Decomposition → Execution → Summarization → Verification → Completion

This kind of collaborative structure.

Each Agent Can Use a Different Model

This is a point I consider very important in TeamAgentX.

Current large models have a very clear characteristic:

The stronger the model, the more expensive it is.

But not all tasks in software development require the strongest model.

For example, requirements analysis, system architecture, and complex bug localization indeed warrant using a stronger model.

But some clearly defined execution tasks:

Writing CRUD, supplementing unit tests, organizing documents, searching for information...

Can completely be handed off to lower-cost models.

Therefore, TeamAgentX allows each assistant to configure its model and skills individually. The standard team designs in the repository are themselves organized around the principle of "controller/QA uses high-reasoning models, while engineers and research assistants choose other models based on the task."

So you can absolutely assemble a team like this:

Architect

Uses a high-level model.

Responsible for:

Requirements analysis, technical proposals, task decomposition, and difficult problems.

Full-stack Engineer × 3

Uses relatively lower-priced models.

Responsible for:

The vast majority of coding tasks.

Testing / Review

Chooses mid-to-high-level models based on project conditions.

Responsible for:

Testing, code inspection, and final acceptance.

The goal here isn't simply to "use more Agents."

It's:

Let expensive models do the thinking, let cheap models do the executing.

The ultimate aim is:

Complete more complex tasks with fewer tokens.

Through testing, using this approach can reduce token costs by 50%.

Agents Don't Just Chat, They Can Actually Operate on Projects

The assistants in TeamAgentX are not ordinary chatbots.

They have now integrated different Agent execution methods like Claude and Codex, and can also call tools, read project files, modify code, and execute tasks through a unified execution layer. The server side also maintains an execution queue for each group and each Agent, supporting task queuing, interruption, and resumption.

For example, you can directly bind a project group to:

/projects/teamagentx

Then put several AI engineers into this group.

Later, you can say in the group:

Add a batch delete function to the user management module.

The architect can read the code first.

Engineers can directly modify the code.

The test assistant can execute tests.

The review assistant can then check the changes.

So this group doesn't just save chat history.

It actually corresponds to:

Project + Files + Agents + Tasks + Memory.

I Also Gave Each Agent Independent Memory

Multi-Agent has another very troublesome problem:

Context pollution.

For example, the same "Full-stack Engineer" might exist in three project groups simultaneously:

Project A is React.

Project B is Vue.

Project C is Flutter.

If the contexts of the three projects get mixed together, all sorts of strange problems can easily occur.

So in TeamAgentX, although an assistant can join multiple groups, its runtime context and long-term memory in different groups are isolated.

When the same engineer enters different projects, it's equivalent to having different project memories.

The history of Project A won't directly pollute Project B.

At the same time, the system also supports summarizing and consolidating long-term conversations into memory, preventing all historical messages from being endlessly stuffed back into the context as the project timeline grows longer.

This is also a direction I increasingly agree with:

What truly matters for AI development tools in the future isn't just how smart the model is, but how to manage context.

Why Didn't I Make It a Traditional Agent Workflow?

Many multi-Agent products now like to be made in this form:

Requirement
 ↓
Product Manager
 ↓
Architect
 ↓
Engineer
 ↓
Testing
 ↓
Done

Essentially, it's still a fixed DAG.

This approach is very suitable for stable, repetitive business processes.

But developing software isn't like that.

In real development, it often goes:

Architect
  ↓
Engineer
  ↓
Testing
  ↓
Problem found
  ↓
Engineer
  ↓
Architect
  ↓
Re-adjust the plan

Even in the middle, you might suddenly need to look up information or have a second engineer verify another approach in parallel.

So I ultimately didn't make TeamAgentX a pure workflow tool.

I prefer:

Workflows are just rules; the group chat is the runtime environment.

Humans can jump in at any time.

Agents can also hand off tasks at any time.

When the AI goes in the wrong direction, I can directly interrupt it in the group:

Don't continue with this plan, switch to Plan B.

Then the entire team continues working.

This is closer to a real team, not an assembly line. TeamAgentX's product documentation also defines this form as "group-chat-style" collaboration: the group is responsible for carrying the project context, and roles collaborate dynamically through tasks and handoffs, rather than having the entire DAG pre-defined.

The Collaboration Process Must Be "Visible"

I've always had a concern about many fully automated Agent products:

You tell it a task.

Then the page displays:

Agent is working...

A few minutes later, it suddenly gives you a result.

What happened in between is basically invisible.

For real software development, I think this is insufficient.

So TeamAgentX now tries its best to expose the Agent's running process, including:

Tool calls, execution status, task queues, context, scheduling records, and task handoffs between different assistants.

The scheduling decisions within the system are also recorded, so you can see why a certain assistant was triggered, where the task came from, and who it was ultimately handed to.

I hope that in the future, opening TeamAgentX won't feel like:

"AI is thinking."

But rather:

"My team is working."

You can see who is doing what, who is waiting, who completed a task, and where blockages are occurring.

Not Just a Development Tool

Although TeamAgentX's biggest use case currently is still as a Coding Agent, it essentially doesn't restrict Agents to just being programmers.

In theory, you can absolutely form other teams.

For example, a content team:

Topic Selection Assistant
 ↓
Research Assistant
 ↓
Writing Assistant
 ↓
Review Assistant

Or a product team:

Product Manager
Architect
UI Design Assistant
Development Assistant
Testing Assistant

You can even create different types of AI teams for operations, data analysis, customer service, etc.

Because what TeamAgentX fundamentally manages are four things:

Models, Skills, Assistants, and Groups.

The model determines its brain.

Skills determine what it can do.

The assistant determines who it is.

The group determines why these people work together.

The official website has some built-in group templates that can be directly downloaded and imported for use.

How I Use TeamAgentX

I've talked a lot above, now let me introduce a few common group chats I created using TeamAgentX.

Development Team

This is the development team I created for requirements analysis, solution design, development, testing, and deployment/release, driving products from ideas to rapid implementation.

It's divided into the following assistants:

Math Classroom

I previously made a website that uses AI to generate explanatory videos based on math problems. Now I've remade it in TeamAgentX. I input a problem, and it automatically generates an explanatory video and posts it to my wife's Douyin account, one video automatically every day. It's already posted 50 videos, currently has 923 followers, and the video traffic is pretty good. Posting videos has basically no cost; after inputting the problem, it automatically generates the video and posts it to Douyin.

Introduction to the assistants in the Math Classroom group:

TeamAgentX Client Release CI/CD

I used TeamAgentX to create a TeamAgentX Client Release CI/CD group, used for automatically packaging the client, uploading to third-party platforms, updating the server version, and sending Feishu notifications. Normally, you could use some CI/CD platforms for this, but in the second step of uploading the client to the platform, the platform I use doesn't support API uploads, so I can only use AI to simulate browser operations for the upload.

Token-Saving Group

Recently, I've felt that the quota for the GPT Plus plan is getting smaller and smaller. A week's worth of GPT-5.6-Sol High gets used up in a day. Recently, GPT-5.6 Luna dropped in price by 80%, so I plan to use GPT-5.6-Sol High as the architect to assign tasks and verify results, and GPT-5.6 Luna to execute specific tasks. This can significantly reduce token costs while ensuring task quality. I tested it, and for the same task, using this approach can reduce token costs by 50%.

Prompt for the Senior Architect:

You are the team architect, using a high-capability model, responsible for requirement understanding, solution design, task decomposition, coordination of execution, and final acceptance.

Core rules:

* Prioritize decision-making and delegation, do not personally do a lot of execution work.
* General development, code searching, CRUD, testing, and simple bugs should be prioritized to full-stack engineers.
* Parallelize when possible, serialize when there are dependencies.
* Clearly define goals, scope, and acceptance criteria when assigning tasks.
* By default, only look at the engineer's result summary; delve into the code only when risks, conflicts, or failures arise.
* Personally intervene only when engineers fail consecutively or when complex issues involving architecture, security, databases, or concurrency arise.
* Don't forcibly break down tasks just for the sake of multi-Agent.
* Ultimately responsible for checking module consistency and whether requirements are met.

Prompt for the Full-stack Engineer:

You are an execution-oriented full-stack engineer, responsible for completing development tasks assigned by the architect.

Core rules:

* Only process code needed for the current task, do not aimlessly scan the entire project.
* Implement according to the established plan, do not arbitrarily change architecture, interfaces, or data structures.
* Solve ordinary problems independently, including development, debugging, testing, and type errors.
* Do not modify code unrelated to the task, do not perform unnecessary large-scale refactoring.
* When encountering architectural conflicts, security risks, major database modifications, or consecutive failures, promptly hand over to the architect.
* Proactively run tests, builds, linting, or type checks after completion.
* Reports should only include: completed content, modified files, verification results, risks, and whether architect intervention is needed.
* Can request assistance from other Agents, but do not infinitely re-delegate tasks.

Finally

Due to space limitations, I will write detailed articles later to share these group chats I've made. Everyone can follow along.

The project is currently open-source, and PRs and issues are welcome.

Official website: https://teamagentx.com

Project repository: https://github.com/dbfu/teamagentx