Modes vs Agents

[nikhilgikiai]

A bunch of feature requests about memory, storage of tasks etc have led me to this discussion - I see modes often assume they will have access to their actions from other tasks. While building local memory etc have all been suggested and tried in many ways, but given that Cursor brought background-agents preview, this project might benefit a lot from deciding whether/if to approach this. I find myself often trying to fill in for modes not being agents, and I am hoping this is commonly felt.

[nikhilgikiai]

I realise this is highly opinionated so here is an example of stuff I consider a part of the difference:

[nikhilgikiai]

Augment code context engine is a step in this direction, i feel the community will benefit if core Roo devs have opinions on that.

[nikhilgikiai]

More thoughts here:

Roo Code (prev. Roo Cline) gives you a whole dev team of AI agents in your code editor.

To me this sounds like the identities of agents in the team should be fixed. Right now, the composition of this team in terms of identities of agents (modes) is non deterministic, it is a consequence of one's task management setup in rools or through the content of one's repo. But the orchestrator should just be the orchestrator.

At some point i experimented with a system of level0, level1 orchestrators, where the first level just creates (new_tasks for) other orchestrators, etc. I tried to then map those orchestrator levels to things like product milestones, and tried to build cost management into task branching and returning.

All that should not be possible, the orchestrator should be one. similarly for all other modes. of course i do achieve this through a combination of mode-specific rules and maybe some mode specific docs in my repo.

[nikhilgikiai]

Rools was a typo but i will leave it there :D