AI: Clarification on the new AI agents in the current master branch: Junior, Explore, Code Reviewer, and Context Reviewer

[safisa]

Discussion

Hi,
I need some clarifications regarding the new AI agents introduced in the current master branch: Junior, Explore, Code Reviewer, and Context Reviewer.

• Are these new agents experimental?
• Are these new agents expected to replace the current ones soon?
• Some of the new agents have similar functionality to existing built-in agents! This can be confusing.
• The list of built-in agents has become quite long! Do we, as Theia extension developers (Theia framework), need to expose all these agents?

[github-actions[bot]]

Hi @safisa, thanks for starting this discussion! 👋

The Theia community will take a look soon. In the meantime, you might find helpful information in:

• 📖 Theia Documentation
• ❓ FAQ
• 💬 Previous Discussions

---

💙 Eclipse Theia is built and maintained by a community of contributors and sponsors. If Theia is valuable to your work, consider sponsoring the project. For professional support, training, or consulting services, learn more about available options.

[sgraband]

Hey @safisa,

Yes they are experimental. We are currently trying to answer the exact questions you have asked, by trying out a few things 🙂
We do not yet know which route we will take with the agent design and therefore are currently test driving it. It might be, that some of those agents will be removed again or that they will replace some existing agents. We will definately reevaluate this before the next release. I will gladly give you more detailed answers, if you are interested.

Could you maybe specify where you see similarity between these new agents and the existing agents? Which do you feel like they overlap? Lastly, could you share with us, what you mean by exposing the agents as a Theia extension developer and what your concern about a long list list of Agents is?

Thanks in advance and thank you for raising this.

[safisa]

Hi @sgraband ,

First, thank you for your prompt response.

I’ll begin with your last question. I was referring to our web app studio, which is based on the Theia extension. I had asked if we would retain the entire list of built-in agents. However, as I understand from your response, the list will be modified before the 1.70 release, which is what I had hoped for.

Regarding the first question, I haven’t actually tried the new agents. I only read their descriptions and felt that they overlap with the Architect and Coder agents, as they appear to perform similar tasks. Therefore, I find this confusing and unclear about when to use which agent.

Instead of introducing new agents, why not create new skills that the current agents can use when necessary? The same applies to the GitHub agent, which is not among the new agents you’ve added. I believe this agent should also be a skill. Similarly, the code review skill could be introduced. The context reviewers’ purpose is not entirely clear, and it might also be a skill.

The Junior and Explore agents have confusing names, and I believe the Coder and Architect have better names. They can also perform the same job, although they can be enhanced to handle extended or improved prompts. Additionally, the plan/architect job might be better suited as a skill rather than a specific agent.

Therefore, I suggest focusing on skill authoring, which would result in better design rather than offering a long list of agents, similar to Claude Code's design.

Thanks

[JonasHelming]

Thank you for your suggestions.

There is a conceptional difference between skills and agents: Agents have their own context when delegation is happening. This allows to handle a sub task in a dedciated context window. As for example if Coder needs some information from github, it can delegate a request to the Github agent and get a consolidated request. It does not need to handle all the querying in between. This saves context.
Of course you are right that you can achive the same things with skills, this is really a design decision, depending on the use case and for many things, it probably makes sense to have even both options. Please feel free to contribute things you find missing.

What i would recommend to you: If you have a product based on Theia, you should have a mechanism to control the agents that you include into it. With this, you can make a opinionated decision on what you include into your product. All before mentioned agents are actually part of the Theia IDE, not the Theia Platform.

Finally, about Junior and most of the new agents: They belong together in a special way, I will let Simon comment on this.

[sgraband]

Hey @safisa,

I see where you are coming from. However, please note that while you are free to use the agents provided in the Theia Framework, you are not required to include them in your custom tool at all. As you already mentioned, there are multiple approaches to handling the behavior we are currently trying to achieve.

The goal of the agents in this repository is not to fit all tools built on the Theia Framework, but rather to support the use cases we envision for the Theia IDE. (Theoretically, we could move them there, but then there would be nothing left to test in this repo 😉.)

So if you feel that a different direction using skills is better suited for your tool, we would encourage you to customize or create your own agents. We will never be able to make the agents in this repo match everyone’s expectations. (That said, your input is still very valuable to us.)

Apart from that, I want to explain the reasoning behind these agents and why I believe they are not duplicated and that their existence is justified (whether this should be implemented as skills or agents is a separate discussion 🙂):

• Coder: Existing agent for coding tasks.
• Architect: Existing agent for planning and searching the workspace.
• Explore: New agent that can be reused by other agents to explore the workspace. This does overlap with the Architect’s previous functionality, but the Architect has been updated in the next prompt to delegate workspace exploration to the Explore agent instead of handling it directly. This concept is inspired by Claude Code. The main advantage is keeping the context size small (this will be a recurring theme across these new agents). I also don’t find the name confusing - it aligns with Claude Code terminology.
• Code Reviewer: As the name suggests, reviews code produced by the Coder and provides feedback.
• Context Reviewer (name not ideal, I agree): Similar to the Code Reviewer, but for plans. It reviews plans and checks whether the Architect created a valid plan according to the user’s input.
• Junior: New agent designed to support more advanced AI coding workflows. While the Coder can already implement and test changes, it requires another agent (Architect) to create a plan first. Junior simplifies this flow by orchestrating the existing agents. You can think of it as a project manager that delegates tasks. The flow is: Junior asks Architect to create a plan → the plan is reviewed by the Context Reviewer → Coder implements the plan step by step → Code Reviewer reviews the changes → AppTester tests the changes → finished. This flow may include feedback loops between agents when issues are found. This is fundamentally different from how the Coder operates and has the advantage of context isolation. It allows handling much larger tasks without running into context limitations due to delegation.

I hope this helps clarify things. Again, we are not saying that these new agents are the definitive solution—we want to experiment and continue the discussion. But from my perspective, there is very little duplication, and each agent serves a distinct purpose.

[JonasHelming]

One note "we would encourage you to customize or create your own agents" => or even better, contribute to the existing ones. If you do not want sub agents, please feel free to contribute skills and prompt adaptations directly to Theia Coder. We need to of course align in what we finally provide as defaults in the IDE, but it would be very nice to get input on the standard agents, too!!

[sgraband]

Of course! Just my opinion: I do feel like Skills do not belong built into the Theia IDE, as they are a user concept in my eyes and migth conflict with user skills if they are built into the tool. Claude Code does also not come with skills by default.

This does not need to be discussed now of course, but i just wanted to clarify on please feel free to contribute skills from my POV.

[JonasHelming]

Yes, we should be precise on the terms here. Skills = a mark down file in the skill directory.
When loaded in Theia it comes a prompt fragment.
So I agree we should probably not package Skills.
However, what i really meant were prompt fragments packaged as prompt fragments or slash commands and/or exposed as capabilites

[safisa]

Hi @JonasHelming, @sgraband,

Thanks so much for the detailed response—I really appreciate it!
So far, I’ve been using all the built-in agents in the platform as they are, and I’ve also added new agents with special tools that help us with our use cases and custom files we want the AI to update.
I haven’t had a chance to look at the new agents yet, but I noticed they seem similar to some of the goals of the previous agents just from their descriptions.
I’ll take a look and test them and also try out other approaches in the next few weeks.
Thanks again.