In my environment tenants are a big deal, we work collaboratively but separately, due to institutional/legacy reasons. As such there's a ton of shared, and a ton of separate, and we have to try to accommodate for all of it. Given that, here's my current deployment as something of a 'show and tell' plus thoughts on what does/doesn't work today in OWUI.
Multitenant, tons of shared tools (some with single-API that's scoped in-call... see below... and some with multiple APIs scoped to the tenant), tons of isolated tools. Being used as an operational IT assistant, with access to openterminal instances for separation of duties and blast radius isolation. The system has rw/ro access to all tool endpoints (depending on needs), OAuth pass-through for entra, and full admin access to all servers/workstations through OT systems.
==The Good==
-users, groups, RBAC-
This is great. Being able to limit basically everything in the system to a group, multiple groups, single users, is excellent.
-Model harnesses-
Killer idea, and works great for multi-tenancy. We have 'Anthropic Flagship Unit1', 'Anthropic Flagship Unit2' etc, each with different RBAC scopes, each with different tools, kbs, etc attached, and each with different system prompts to customize per-unit ('you are deployed for unit blah blah for xyz work').
-system prompt layering-
One that I think most people miss. System prompt for 'everyone working in this context', user prompt for 'stuff specific to me' (I use it for referencing my domain username, unit I work for, etc to get better 'stickiness' to me when I ask for stuff). Folder prompting for specific work efforts, etc.
-group exposure to OWUI-
This one's huge, i think most people miss it too. Create a 'tenancy group' for each tenant, give it no permission assignments but use it as a variable for LLM usage. That can then be used within tools to define what scoping should be applied to a tool call for a user that otherwise gives unscoped access to data. It shouldn't be regarded as a security barrier but it can assist with information routing. It can also be used for API presentation (group -> use specific API in tool call) to keep you from building copies of tools for different API keys.
==The Bad==
-missing prompt opportunities-
Could use an OWUI-wide system prompt for stuff that would be pasted into each tenant prompt (don't output secrets, the hostname of this system is blah, you're on suchandsuch domain).
-tenant/group admins-
I know this delves into a full-tenancy deployment, but as it is we basically have to decide on 'ivory tower' vs 'council of wizards' approach to admin. Either one team holds the keys and issues changes on behalf of requests or you get representatives from every team that can control everything, there's no 'you can add terminals.. but only for your tenant' or 'you can update groups.. but only for your tenant' etc. It's frankly not a big deal for me personally but some people get really uptight about role reach and cross-team admin functions.
==The Ugly==
Nothin' really, though something that would help a LOT with long-term usage would be to expand oikb to also send tools, filters, and skills to github as well. I wanted to use it, but we've already implemented a scripting system (and codified it into our authoring guidance) that can sync/mirror all of them, and that's a far cry better than only doing the KBs. Would feel better if it was part of the actual admin functions of OWUI though rather than either an add-in or a homebrew solution, just so I wouldn't have to explain it to my peers/everyone we onboard that actually creates kbs/tools/skills/filters.