I'm excited to see where this project goes!
One small comment/question while you're still laying down architecture... I noticed the config expects a single model definition (model, url, key). But in whatever the emigo equivalent of Agent mode is, won't you want to be calling into different LLMs for different purposes? It seems like there should be a set of LLMs that need to be defined.
In my own personal agents I've adopted the pattern of having a dictionary of "actions" (e.g."apply-code", "analyze") that map to LLM definitions (model, url, key). This mapping can be configured by the user. Then in the code you can make LLM requests customized by capability. Some tasks are fine under a free or small local model, whereas other tasks need something beefier. With models changing so quickly ideally this should be easy to experiment with (swapping out models).
Also, you really want to be able to configure multiple sets of LLMs. You might have one set that works well for coding and another set that works well for other kinds of writing. You might have a "local" preset that contains a set of models running locally, and a "gemini" preset that contains Gemini as the core intelligence with whatever pairs well with it for applying edits, searching your codebase, etc., And a super tricked out SOTA preset for tasks that you're willing to potentially pay an API premium to get right.
This also leads to the need for LLM specific prompt customization. You might instruct sonnet to apply edits in one way and QwQ another way.
Lots of ways you could model all that in elisp but good defaults, ease of swapping out and working with (switching between) model sets are key.
I'm excited to see where this project goes!
One small comment/question while you're still laying down architecture... I noticed the config expects a single model definition (model, url, key). But in whatever the emigo equivalent of Agent mode is, won't you want to be calling into different LLMs for different purposes? It seems like there should be a set of LLMs that need to be defined.
In my own personal agents I've adopted the pattern of having a dictionary of "actions" (e.g."apply-code", "analyze") that map to LLM definitions (model, url, key). This mapping can be configured by the user. Then in the code you can make LLM requests customized by capability. Some tasks are fine under a free or small local model, whereas other tasks need something beefier. With models changing so quickly ideally this should be easy to experiment with (swapping out models).
Also, you really want to be able to configure multiple sets of LLMs. You might have one set that works well for coding and another set that works well for other kinds of writing. You might have a "local" preset that contains a set of models running locally, and a "gemini" preset that contains Gemini as the core intelligence with whatever pairs well with it for applying edits, searching your codebase, etc., And a super tricked out SOTA preset for tasks that you're willing to potentially pay an API premium to get right.
This also leads to the need for LLM specific prompt customization. You might instruct sonnet to apply edits in one way and QwQ another way.
Lots of ways you could model all that in elisp but good defaults, ease of swapping out and working with (switching between) model sets are key.