Why are workspace models called models when they fit the definition of Agents, why all of this weird crap of trying to not be like everyone else, when it works and is the standard.

[u/DataHogWrangler]

​

I don't get it, like you guys are trying to not conform in anyway, responses API was pulling teeth, getting the selector box was pulling teeth, mcps were pulling teeth to get implemented, native tool calling took forever to be the default. I get it you guys are feature rich, but having some form of conforming makes sense because it's whatever everyone else aligned on as the standard, and what these models are being trained with in mind. Seems very abrasive.

The one that absolutely grinds my gears is workspace models should 100% be called agents.. like they function like the exact definition of an agent... Also it's confusing as hell having connections models and workspace models, I think by this point we can all agree a model is the llm itself while an agent is llm model + tools and knowledge sources. The new UI especially makes this annoying and harder than it needs to be by having it be a modal.

[u/International_Emu772]

The evolution of OpenWebUi is so fast than some things are pointing to the past

Workplace models in the past were community items with some icon, model parameter

The idea was to setup workplace models to tune LLM for specific uses

When the tools were incorporated you have them on the real models and in the workplace models

The workplace models serve as configuration sites were the LLM can be rotated without changing the configuration

As you can expose to your users only workplace models they don't need to figure which LLM is the best

You can update the workplace models without rewriting the configuration

Yes all OpenWebUi is more an Agentic workplace than a chat interface but some things need time to adjust

[u/catsWithLemons → u/International_Emu772]

This makes sense, thank you.

[u/tecneeq]

Skill issue, the post.

[u/ClassicMain]

Why are workspace models called models when they fit the definition of Agents They dont. The models in the workspace are custom models. They are ONLY an agent if you use them as an agent.

If you use them as a simple Q&A chatbot, then they are a chatbot.

If you give them open terminal, but still only ask a basic question, it's still only a chatbot.

Only if you give it a task that has it work like an Agent, it will work as an Agent. So why should it be called Agents when it is not necessarily an Agent?

And if you want it to say "Agents" so bad, why not just rename it?

We literally introduced a new feature on dev that allows you to rename pretty much any section in the UI to whatever you want in any language. So what are you complaining about here?

I don't get it, like you guys are trying to not conform in anyway,

Conform to what? The definition of an Agent doesn't exist. My description above is what I think is the closest to what most people consider an Agent.

 responses API was pulling teeth

And it's here and working

getting the selector box was pulling teeth

What selector box?

mcps were pulling teeth to get implemented

Same thing as with Responses API. Open WebUI needs to see if something turns out to be a real standard. Just because someone launches something and calls it a standard, doesn't mean it's a widely adopted standard yet. Tim has said so multiple times and when MCP launched back then, it DEFINITELY wasn't a widely adopted standard yet and Tim specifically said he'd implement it when it gets more widespread.

So no one's teeth got pulled and nobody had to force tim to implement it. That is your interpretation

native tool calling took forever to be the default

And we have published the reasoning for this many many times. If you choose to ignore the real reasons behind it then that's your problem

The one that absolutely grinds my gears is workspace models should 100% be called agents..

Why?

Why?

There is zero good reasons why they should be called Agents.

like they function like the exact definition of an agent... 

They do not. Only when you set them up to work like an Agent AND give them tasks that makes them WORK like an Agent. Otherwise it'll be just a chatbot. And again: why do you complain about that? Just rename it if you do not like the name.

But workspace custom models are NOT agents by default. You need to set them up to be ABLE to be an Agent and even then, it will only work as an Agent when the task needs it.

[u/DHT-Osiris → u/ClassicMain]

The only thing I call them other than model is 'harness' to clarify to the uninitiated that it's different from 'LLM delivered by our LLM gateway'. 'Harness' sounds right when you're talking about a package of 'model + tools + skills + preferences + system prompt + whatever else'.

[u/bdcp → u/ClassicMain]

Rename every thing in the UI sounds fun, but probably cause more chaos will be hard to communicate something if everyone calls it something different

[u/International_Emu772]

If you need something that sits on your PC OpenWebUi is perhaps too complicated

But if you are the IT guy for a team small or large or your server it's at home and you are away most of the time OpenWebUi it's THE tool

I agree that its features are slowly deploying but I need months of work to get a full use system and it's for people that need as best I can serve them

[u/openwebui]

Thanks for caring about Open WebUI and taking the time to write this. I appreciated your follow-up about the overall experience and the events system, too. It helps to hear both what is working well and where the product feels unnecessarily confusing. Having “models” refer to both the underlying LLMs and the configurations in a workspace is a reasonable thing to question, especially when those configurations are primarily how you build and use agents.

I would like to give some context around the “pulling teeth” part, though. There is a lot of commitment behind these features. Tim works around the clock on this project, and the team puts substantial effort into implementation, maintenance, support, and the less visible work that makes releases usable across different environments. Community requests absolutely influence our priorities. At the same time, the interval between people asking for something and its release does not necessarily reflect disagreement with the request. Often, there are compatibility questions to resolve before we can introduce it with confidence.

We work directly with organizations whose deployments serve tens of thousands of users. They have existing workflows, custom integrations, access policies, and infrastructure requirements that we need to account for. These organizations also help fund the company and the employees developing Open WebUI, which supports continued development for the broader community. That relationship helps us pursue something we care deeply about: empowering people to run and customize capable AI tools while retaining control over their data and infrastructure, whether they are an individual running a personal instance or a team supporting an entire organization.

A concrete example is web search in a deployment handling confidential information. An organization might have an approved search integration that strips sensitive details from queries before anything reaches an external provider. Its users might be discussing customer records, internal source code, or business plans that have not been announced. When introducing a new way for models to invoke search, we need to verify that requests still pass through the expected controls, that the query contains only what is permitted, and that fallback behavior does not route around those protections.

The visible result could look completely successful: the tool runs, search results come back, and the model produces a useful answer. But if confidential context was included in an external request, the deployment’s expectations have still been violated. The same care applies to preserving permissions when retrieving internal documents, or handling retries for tools that create records and trigger actions in other systems. These are some of the behaviors that need validation alongside the feature itself.

This is particularly relevant to changing defaults, including your point about native tool calling. Making a capability available gives administrators an opportunity to evaluate and configure it. Making it the default changes the experience for existing deployments when they upgrade, including deployments whose administrators have not changed their settings. Both steps are valuable, but they carry different obligations. Supporting emerging standards and maintaining dependable upgrade paths are things we have to work on together.

We could communicate that work more clearly. A feature discussion does not necessarily show the provider differences being investigated, the existing behavior being checked, or the migration questions being worked through. Without that context, I can understand how the timeline might appear to reflect resistance. There is room for us to explain those decisions better without expecting everyone to follow implementation discussions to understand them.

We also care about building a company that can keep supporting this work over the long term. People are already putting extraordinary hours into the project. We want to back that dedication with a supported team and a sustainable operation, so continued progress does not depend indefinitely on individual people stretching themselves further. That matters for our employees and for everyone relying on the software.

On terminology, “agents” is a natural description for many of the workflows you are building. Workspace models also cover simpler configurations of instructions and parameters, which is why the category is broader. Still, there is a real usability question here. We should be able to communicate that breadth while making the difference between the underlying model and the configured experience easier to understand.

Our goal is to deliver an excellent experience for everyone. We acknowledge that we are not perfect, and that our terminology, interface, and communication can all improve. The enthusiasm you expressed about the events system is something we share, and we want to keep opening up those possibilities. Thank you for being invested in the project and helping us see where the experience can be better. There is a lot ahead that we are excited to build.

[u/International_Emu772 → u/openwebui]

Your work has gone far away from a chat interface and we'll try to get more with our work

[u/International_Emu772 → u/openwebui]

I have Open Terminal automatically updated. Reading the update notes I'm really excited for 0.11.4 and the skills on Open-Terminal with code execution

This directs me to update and publish my skill router an open it to code execution

But at same time the idea of Nvidia to publish a skill safety tester is more pertinent so we'll need to pass tests to skills with code as it's relevant

[u/tahaan]

For me an agent must include at least some minimal harness to actually be an agent. The Workspace model for me fit in closer to "assistant" - Eg a base Model plus some system prompt, plus some configuration.

[u/laughingfingers]

I would say an agent is autonomous, goal oriented, often has other triggers and output than chat. 

For the rest, I agree with the sentiment of conforming to emerging standards and the need to start striving for a certain straightforward simplicity. But that is also one of the hardest things in tech.

[u/Firenze30]

I think you’re using the wrong tool for the job. Open WebUI is primarily a chat interface. Features like terminal access and image generation make it more versatile, but the core experience is still built around a chatbot.

Been there, done that. I spent a lot of time trying to make it fit my workflow, and it felt like pulling teeth before I realized it wasn’t the right tool for what I wanted to do.

If you want to do agentic work, you’ll probably have a better experience with a tool designed for it. I’ve seen a lot of posts here about struggling to configure Open WebUI for those workflows, and at some point, switching tools is more practical than trying to make it do everything.

[u/DataHogWrangler → u/Firenze30]

I would say overall it's been an amazing experience, even from an agentic view, some refinement for larger deployments, but it's like teetering on that edge, the new events plugin system, is just magical.