Why split one AI into many

You would not hire one person to be your doctor, your lawyer, and your accountant all at once. Stretch a single expert across every job and the work gets shallow. Nobody can hold that much, that well, at the same time. The same thing happens when you ask one AI to do everything: the more jobs you pile onto a single model, the more it loses the thread.

In the foundational agent track you learned that splitting work across a team of agents is a deliberate tradeoff. Done for the right task, it makes a system better. Done for the wrong one, it just adds cost and confusion. This track answers when that bet pays off by watching a real system that made it, so by the end you could design one of your own. This first lesson is the map: who is on the team, why it is split the way it is, and the one design choice that matters most. We do not read any code yet. That starts next lesson.

The system is TradingAgents, a free, open-source project. It analyzes a company the way an investment firm might: instead of one AI answering “buy or sell,” a team of specialist agents each do one job and pass their work down the line. We are going to study how that team is organized. We are not going to study investing.

This track teaches how a multi-agent AI system is built and coordinated. It uses stock analysis as the worked example. It is for education only. It is not investment, financial, or trading advice, and nothing here is a recommendation to buy or sell anything.

Meet the team

Picture a real investment firm for a moment. Information comes in from many sources. People argue about what it means. Someone makes a call. Someone else checks that the call is not reckless. A manager signs off. The work moves through hands, and each pair of hands is good at one thing.

TradingAgents is built the same way. Its agents fall into five groups, and each group is a different kind of work:

Analysts gather information. There are four of them, and each watches a different source: one reads market data, one reads social and sentiment signals, one reads the news, one reads company fundamentals. Their job is to bring in the raw picture, not to decide anything.
Researchers argue. Two of them. One builds the strongest possible case for the company (the bull), the other builds the strongest case against it (the bear). They are meant to disagree.
A trader turns the argument into a plan. One role. It takes the debate and shapes it into a concrete proposal.
Risk reviewers stress-test the plan. Three of them, each with a different temperament: aggressive, conservative, and neutral. They poke holes from three directions.
Managers judge. Two of them. A research manager rules on the bull-versus-bear argument, and a portfolio manager makes the final call.

With all four analysts switched on, that is twelve agents in total. (The analysts are optional, so you can run a smaller team; the other roles are always there.) But the headcount is not the point. The point is that every agent has one narrow job, and the jobs line up with the natural steps of the work: gather, argue, plan, check, decide.

Why split the work this way

Each of these agents is still the same thing the earlier track described: a model with a focused job. So what does splitting one big job into many small ones actually buy you? Three things, and you can see all three in the team above.

Focus. The news analyst is told to read news and nothing else. Its instructions are short and its attention is not diluted by also having to value a balance sheet. A narrow agent with a narrow job is more reliable than one generalist trying to hold the whole task in its head at once.
Deliberate opposition. The bull and the bear are not a duplicate of each other. They exist specifically to argue opposite sides, because a single agent asked to “weigh the pros and cons” tends to talk itself into a tidy, comfortable answer. Splitting that into two opponents forces both cases to be made at full strength. (We spend all of lesson 3 on why this works so well.)
Replaceability. Because each role is built and instructed separately, you can improve the news analyst, or swap it out entirely, without disturbing the trader. The team is modular by design.

This is the first transferable idea of the track: a good agent team is one job broken into roles, each kept small enough to do well. Before anything else, the design question is “what are the distinct jobs here,” not “how many agents can I use.”

The decision most people miss: spend capability where it counts

Here is the choice that separates a thoughtful agent team from a naive one.

Not every job on the team is equally hard, and the better models cost more money and run slower. So TradingAgents does not put the same model behind every agent. It works with two tiers: a more capable, more expensive model, and a cheaper, faster one. The interesting part is how it hands those out.

Almost every agent runs on the cheaper, faster model. The gathering, the summarizing, the arguing of one side: a fast model does all of that well enough. The more capable model is reserved for exactly two roles, the two judges: the research manager, who settles the bull-versus-bear debate partway through, and the portfolio manager, who makes the final call at the end. Those are the two seats where one agent weighs everyone else’s work and commits to a decision.

That is the idea worth carrying out of this lesson: capability is a budget, and you spend it at the judgment points. A wrong call when you are merely gathering data is cheap to recover from. A wrong call at the moment of decision is the expensive one. So the strongest model goes there, and nowhere else. (And notice: change how many analysts you run, and the headcount changes, but this does not. The capable model always goes to exactly those two judges. That steady rule, not the number twelve, is the real design.)

Why this matters when you use AI

You might never build a trading system, so why is this worth your time?

Because anyone can tell an AI “build me a tool that does X.” The hard part is judging what comes back. If you know what a sound agent team looks like, work broken into focused roles, with the best model spent only at the decision points, then you can look at what an AI hands you and tell whether the structure is right or whether it just looks busy. You can ask for the missing reviewer, or question why every step is burning your most expensive model. Good structure going in is how you get good results coming out. Understanding the shape is what lets you tell good output from bad.

How to follow along

This system is real, free, and open for anyone to read, and you do not need any special software or account to look at it.

TradingAgents was built by TauricResearch (Yijia Xiao, Edward Sun, Di Luo, and Wei Wang), is described in a research paper (arXiv:2412.20138), and is free to read and reuse under the open-source Apache-2.0 license. It lives on GitHub, a free public website where open-source projects share their code. You do not need a GitHub account, and you do not need to know anything about programming or the tool called Git to look around. You just open the link in your browser and read the files like ordinary web pages:

github.com/TauricResearch/TradingAgents (pinned snapshot)

One thing about that link. It points to a pinned snapshot of the project: a single frozen version, marked by a short code (7e9e7b8). Open-source projects change all the time. We pin one snapshot so that what you read in these lessons always matches what you see on screen, even months from now. When a later lesson points you at a specific file, this frozen version is the one it means.

You do not need to open anything for this lesson; it is the overview. Starting next lesson, we read the system together, one piece at a time, always from this same snapshot. If you cannot or would rather not open it, that is fine too: every lesson quotes the parts it discusses directly, so you can follow along from the page alone.

Build your own: the takeaway

When you design your own agent team, this lesson gives you the first two steps.

Decompose the workflow into functions. Write down the distinct jobs the task actually contains: gather, analyze, argue, synthesize, check, decide. Each becomes a role with narrow instructions and a small set of tools. Resist adding roles that do not map to a real job.
Find the judgment points and spend your capability there. Identify the few places where one agent commits on behalf of the others. Give those your most capable model; let the rest run on a cheaper, faster one. In this system there are exactly two; in your own, expect far fewer of them than you would first guess.

Common pitfalls

Counting agents instead of functions. “Twelve agents” is not the design. The design is the set of distinct jobs; the count just falls out of it. Adding agents that do not map to a real function adds coordination cost and buys nothing.
Using one model tier everywhere. Putting your best model on every agent is slow and expensive; putting a weak model on the judge is unreliable. Matching the model to the difficulty of the job is the point.
Assuming more roles means more intelligence. A team is more specialized and more complex than a solo agent, not automatically smarter. Those are different things.

What you should remember

A real agent team is one workflow split into roles by function. TradingAgents divides the work into analysts who gather, researchers who argue, a trader who synthesizes, risk reviewers who stress-test, and managers who judge. The roles line up with the natural steps from raw information to a decision.
Splitting buys focus, deliberate opposition, and replaceability. Each agent is still a model with a focused job; the gain is that every job is small enough to do well.
Capability is a budget you spend at the judgment points. This system runs almost every agent on a cheap, fast model and reserves its most capable model for the two judges. That choice, not the agent count, is the architecture.

The team list tells you who does the work. It does not tell you how they get their information. The analysts are not handed a tidy packet of data to read; they go and fetch it themselves, deciding what to pull and when to stop. That is the next lesson, and it is where we open the system for the first time.