More interactive Agent mode

[stefanofornari]

I recently started using Gemini CLI and I am impressed by the user experience and its workflow. I really like the interactivity that keeps you in control of what goes on while taking advantage of the underlying AI.

In Jeddict, currently the agent experience is quite different as it applies the changes to the file directly without any interaction. This actually caused some bad experiences for me, as some files were completely changed not in the way I wanted. Additionally, at the moment, it handles only updates on files. Gemini CLI, for instance, is able to build projects, run tests, etc.

Jeddict's Agent mode is a great starting point, but I'd like to work on it to make it similar to the CLI's approach. Before (or in the meantime) I write a lot of code which may not be welcome in the project, I'd like to get feedback on which approach to take.
Let's start at a very high level: which modes should we have and for which purpose? Currently we have two modes: question and agent. The former is meant to ask questions related or not related to a project and just show the answers. The latter instructs the AI to propose actions and applies them once provided by the AI. As far as I can tell, the difference is very much just about that—in how the AI is instructed to reply.

But do we really make this distinction in our minds when we develop? What do you think? Personally I don't. Working in query mode, I usually interact with the AI making various prompts and asking questions, and I can even ask it to propose applying changes to a given file. Usually to do that I need to inspect the diff (and here I must say Jeddic does a great job!). Then, if the changes are fine, I apply them to the code.

If I work in Agent mode, everything will be basically the same, only Jeddict applies the changes as soon as they are provided by the AI. As I said, this is quite dangerous, as you would realise that something was changed only later, maybe because something has been broken. But if we had a way to review the changes the AI suggested and interactively choose whether to apply them or not, then we'd have the best of both worlds: if you deny the change it would be like query mode; if you accept the change it would be like agent mode.

I've already written too much :) There is more to explore, but let's not put too much on the table to start with.
What do you think?

1. Do we need/want two separate modes (Query/Agent)?
2. Is an interactive agent a good idea vs. a fully automated one?
3. Do we actually maybe need more modes?

Thanks in advance for reading and for your feedback If you are interested in where I am starting from you can checkout this branch.

[jGauravGupta]

Thanks a lot for sharing your feedback and the comparison with Gemini CLI — it’s really valuable input.

The main reason I initially separated Query and Agent modes is that the Agent isn’t fully stable yet. Sometimes AI suggestions are incomplete when the requested change is too big.

That said, I completely agree that an interactive agent is the right direction. I also think having both manual apply and revert options is quite important for safety.

Is an interactive agent a good idea vs. a fully automated one?

I believe interactive is better at this stage. Once the workflow becomes more stable, we can add a “fully automated” toggle in settings for users who prefer that.

Currently, the agent prompt is:

Your task is to generate or modify code based on a user query. The output must include a list of file actions (create, update, delete) with the full file path (relative to the project base directory) and the corresponding file content.
Directly after the code block, include an `action` block in this format:
``action
path=relative/path/to/file
action=create|update|delete
``

I also think moving to git patches instead of plain code blocks, as this might make the workflow more transparent and easier to apply/revert.

So in short:

• Query/Agent separation was a temporary measure.
• Interactive agent (with review/revert) seems the way to go.
• Fully automated mode can come later as an option.
• Git patch format could be explored for more stability

[jGauravGupta]

Also, have a look at #170 — it demonstrates implementing an AI Agent using an MCP server, which could be useful inspiration for us.

As we explored, there are different ways for the agent to interact with the user. Because of this, I think having separate modes still makes sense. Each mode can serve a different purpose and give users the flexibility to choose the workflow they’re most comfortable with.

[stefanofornari]

Hi Gaurav,
thanks for sharing, good stuff. Also, thanks for the feedback, I am happy to see we are aligned. I do agree as well we may need more modes in the future. I am thinking, for instance, of a TDD mode, which follows a TDD workflow when generating code. Let's see where we can get.

In the mentioned branch, I am showing a diff view instead of the source code so that you can easily pick the changes you like and save. For now it is for updates only, as soon as I have implemented also new and deleted files, I will submit a PR. Do you think we should have a branch on the main repository?

[jGauravGupta]

Hi Stefano,

That sounds great — showing the diff view and letting users selectively apply changes is exactly the kind of interactivity we need 👍.

Regarding the branch: yes, please go ahead and open a PR. Having it directly in the main repo will make it easier for others to try it out and give feedback early.

I’m also exploring another experimental agent mode using patches, so changes can be easily applied and reverted. We can then refine together..

Thanks again for pushing this forward — really looking forward to your PR!

[jGauravGupta]

Hi @stefanofornari ,

Excited to share my latest PR #174 — it enhances Agent Mode with the new IdeTools Agent, making the workflow more dynamic, stable, and easier to extend.

[stefanofornari]

WOW! this is great stuff and very much welcome. I have reviewed the PR and made a few comments. I will merge this branch in mine to try it out and see how the interaction comes out. With which providers have you tested?

[jGauravGupta]

I’ve tested it with OpenAI GPT-4.1-mini so far. One area that still needs improvement is path handling — occasionally it sends a shorter relative path (e.g., a/b/c/Example.java) instead of the full one (e.g., src/main/java/a/b/c/Example.java).

I also plan to add logging of all actions directly in the chat window, so users can stay aware of what’s happening in the background.

[stefanofornari]

Hi @jGauravGupta ,
finally I have managed to create a PR to interactively work with the agent, Have a look at #178 . This is really just a first step, which we will need to integrate in the new Tooling approach. See some considerations in the PR's description

[stefanofornari]

Hi @jGauravGupta,
both in case of using action blocks and tools, we need to change the way prompts and responses are handled because they are going to be only partially managed by the user. I'd envision something like this:

Key points:

• JeddictBrain implements all the back-and-forth with the AI model based on an input task (the initial prompt for a user or a generated prompt from Jeddict); this does not have any direct UI dependency and interaction, which makes it much easier to test and reuse (we should actually move it into a subproject)
• When a task is submitted, the brain carries it on doing what required to complete the work: improve the prompt (Prompts in the diagram), providing the list of tools (Tools in the diagram), or else (...); it then starts and carries on the conversation with the AI model until it says the task is completed. In doing so, it may require interactions with the user or a UI, which will be done through some pluggable input-output pattern.
• currently IMHO the design of JeddictChatModelBuilder/ChatModel/AssistantChatManager is a bit unclear. As far as I understand JeddictChatModelBuilder should create ChatModels, but instead it is also a superclass of ChatModel; ChatModel suggests something that has to do with models, but at the end it just provides some prompts; AssistantChatManager mixes UI, controlling and model functionality making it quite difficult to understand and extend.
• The above design would solve these issues b:
  • separating UI/Chat processing/Tooling/Prompting concerns
  • making chat processing independent by the specific UI
  • providing a proper place for prompting generation/manipulation

Let me know what you think and, in case you like the approach how you would move on.

[jGauravGupta]

Looks great 👍 — the diagram makes the separation very clear. With JeddictBrain owning the exec loop and handling tools/prompts independently of the UI, the design becomes much cleaner and testable. This aligns well with the refactoring I think the project really needs.

[jGauravGupta]

IntelliJ now includes two agents — Claude Agent and Junie.
https://blog.jetbrains.com/ai/2025/09/introducing-claude-agent-in-jetbrains-ides/

Similarly, Jeddict could explore integrating with multiple AI agents in the future, giving users the flexibility to switch between them in chat.

[stefanofornari]

@jGauravGupta, when you have done with #198 , kindly have a look at this: stefanofornari#20
It shows a key effort in refactoring JeddictBrain and I'd like to have your (and anyone else) feedback before going further.

[jGauravGupta]

Hi @stefanofornari,

With the NetBeans 28 release due soon, Jeddict needs to ensure proper agent QA. I’m currently using GPT-mini-4.1 on Windows, and it’s doing a wonderful job for me (although its regex-based tooling isn’t great). I’m looking forward to your views on the Linux environment.

I understand that not all models work well with the agent — we should document this clearly for end users, specifying whether a model is completely non-functional or just not intelligent/workable enough.

I also think we should keep the Action-based implementation as a separate agent: #178
.
Let the end user decide which option they want to choose.

Wdyt?

[stefanofornari]

With the NetBeans 28 release due soon, Jeddict needs to ensure proper agent QA. I’m currently using GPT-mini-4.1 on Windows, and it’s doing a wonderful job for me (although its regex-based tooling isn’t great). I’m looking forward to your views on the Linux environment.
I understand that not all models work well with the agent — we should document this clearly for end users, specifying whether a model is completely non-functional or just not intelligent/workable enough.

I am not able to do real-work testing yet because until I am not able to review the AI changes before they are applied, I am not comfortable switching to it. What I have tried out is that all Perplexity models do not support tools today, Mistral models have partial support and many OpenAI models do not support it. I am not sure we have resources or time to try out everything, I would focus on the code for now.
Maybe what we can do is to document what we know it works and then refer to: https://docs.langchain4j.dev/integrations/language-models/
Also, I am not sure it is a matter of Windows/Linux, have you got any specific concerns?

I also think we should keep the Action-based implementation as a separate agent: #178
Let the end user decide which option they want to choose.

I still do not buy this approach. Users won't even understand the difference between Query and Agent. I still think it is our job to hide this complexity to the user. What I'd like to do after the refactoring is to use langchain4j capabilities to create a router agent that based on a simple interaction with the model, routes the prompt to a tool-enabled agent vs a non-functional agent. The latter will be properly instructed by us to produce actions. This approach has many advantages:

1. it is fully transparent to the user
2. the user experience is smoother
3. as soon as a model supports tools, it automatically uses them (we may keep a way to force not to use tools)

What I am realising, thought, is that instead of a tools/not tools choice we should have direct/interactive choice:

1. direct, tools or actions are applied immediately
2. interactive, tools/actions have a sort of permission flag that determines if an execution requires approval from the user; or even the set of tools can be different
   The idea is that if you are comfortable with the AI producing your code without major review on your side (e.g. build a fully working prototype), you go with the direct agent. If you want to do a TDD session, you go with the interactive agent. The former will use tools to directly change the code, the latter will use tools that require permission and diff views before applying code changes.

[stefanofornari]

Another good source of information: Berkeley Function-Calling Leaderboard

[stefanofornari]

Something to explore:

• Introduce a generic agentic planner and reimplement all agentic patterns through it. It's been introduced in langchain4j 1.9.0
• LangChain4j
• Reference Implementation in Java using LangGraph4j
• LangGraph4j - Implementing Human-in-the-Loop at ease
• Agent Client Protocol
• About streaming for agents

[stefanofornari]

Interactive mode has been implemented with #265 and will be released in the next version (>3.3). You can also trying it out checking out the latest main branch, feedbacks are very welcome!

The next step is to "toolify" the models that do not support tool with the goal of widening the set of LLMs that can be used to work interactively on the code and, in most cases, more cost efficiently. The models that do not support tools may be less expensive and the number of tokens involved in the communication lower. This is tracked in #276 and I will have a PR ready soon.

fyi @jGauravGupta