How should the concept of "different work-type hats" exist in openhands

between a supervisor agent, a swarm of different hats, and in-thread hat-switching, I'd go for the swarm approach decentralized, self-directed AI workflows makes most sense to me in the long term we probably want to increase agent autonomy in the long-term, let them self-direct, self-reflect

yeah... AND... there's still one UI endpoint.... so how do we facilitate single interaction point with divergent contextual access levels and constructs?

single UI endpoint? I sometimes run OpenHands with different learning models, in 2 tabs against the same codebase, simultaneously: 2 UIs. (though 2+ sessions are hard to follow in real time; multitasking with AI feels even less productive than regular multitasking)

I'm thinking more along the lines of 'you are working within work-scope-a on project foo' and then 'you are working within work-scope-b on project bar' each scope has a different set of privileges, tooling, (dif mcp's, dif access tokens, etc) ..... but you use the same openhands webui to interact with the different contexts .... say... work repo and personal blog repo ... ... how should openhands facilitate the context switch? it's essentially a different conversation, with a different repo, AND different 'extra creds/cools' potentially including different mcps....

sure, that would put the multi-tenant complexity (here session/conversation/thread/project/workspace) under the management of the application layer, so now OpenHands needs to manage all that IMO, the lower you push the segregation (my proposal was at the container/network level), the easier it gets https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity I think the AllHands team made a good choice with https://www.all-hands.dev/blog/dont-sleep-on-single-agent-systems if you want to challenge that, that's wonderful, but that complexity should sit above OpenHands, or risk creating a mess

I think I must be expressing my idea incorrectly.... I'm not thinking concurrent necessarily ... but rather following the idiom/principle of least privilege; combined with the real-world expectation that most people will work on more than one thing ... and those different things may need different privilegesets ... I HONESTLY don't care that much HOW or where the boundary is defined.... but it needs to be, such that expectations can be set/expressed clearly so people understand the security model.

well, you have at least 3 ideas to work with, maybe draw them out? https://www.practical-devsecops.com/threat-modeling-data-flow-diagrams/ going through the process might uncover some rough edges to think through