Open WebUI: Scheduling Agents

A developer documented how Open WebUI v0.9.6 lets users define persistent agents through custom models, Python-based tools imported from the Community Tool Library, and markdown skill files, then invoke those agents automatically via schedules or a remote chat interface. The writeup notes that tools must follow a named-object design contract and be injected into the system prompt, and that in testing a weather tool only fired when explicitly mentioned in conversation.

Open WebUI provides a uniform chat interface with media uploads and persistent conversations that connect to an Ollama backend or an OpenAI API-compatible LLM provider. Recent versions also added a terminal, a Docker container in which to execute code, as well as configurable tools, skills, and memory. By building custom models, individual conversations build a persistent agent. This is the final article of my Open WebUI investigation. It takes another turn at agent definition, detailing skill and tool definition, and showing how to invoke agents automatically via schedules and through a remote chat interface. The technical context of this article is Open WebUI v0.9.6 , published on 2026-06-01. The setup and configuration examples should also work with newer versions. While I am fascinated by the capabilities of artificial intelligence tools and applications, crafting blog articles remains a personal skill. Every character, number, and symbol in this article was typed manually, with the exception of verbatim copies from log messages and screenshots. This article originally appeared at my blog admantium.com https://admantium.com/blog/llm42 open webui custom agents and invocations/ . Tools are Python snippets defined by an admin account. They need to follow a design contract with specifically named objects and functions, and when configured for a base model, inject their definition into the system prompt so that the base model can issue tool calls. While there is the option to implement a custom tool following the official documentation https://docs.openwebui.com/features/extensibility/plugin/tools/development , tools can also be imported from the Community Tool Library https://openwebui.com/search?sort=top&t=all&page=1 . Here is an example of adding a tool that shows the current weather. The first step is to find an appropriate tool and get its files. On the community marketplace: Get button an account is required . Alternatively, the Python file can be downloaded from the linked GitHub repository https://github.com/iChristGit/OpenWebui-Tools/blob/main/Tools/weather.py . The second step is to define the tool in the Open WebUI instance. With an admin user account, Workspace = Tools needs to be opened. When the tool was downloaded from the community page, clicking on Import and selecting the downloaded JSON file suffices. If the Python source code file is used, then clicking on + New Tool and pasting the file content is required. As explained in my earlier articles, base models and custom models require a strict definition of their capabilities and available tools, and therefore the new weather tool needs to be added. Follow these steps: Workspace , then Models To test this new weather tool, I created a new model named assistant , based on GPT-5.4, and added the tool. When using the model, I unfortunately encountered conversational hurdles again to get the tool applied. Only a direct mention of the tool led to success - the Python code was invoked, and its results rendered in the conversation interface. Skills are markdown declarations with detailed instructions. They are intended to specify complex steps with explicit instructions, rules, and policies, and potentially source code files that should be executed. Skill repositories are abundant, and skills.sh https://www.skills.sh/ provides an easy entry point. Search for skills that support GitLab interactions; I encountered git-commit https://github.com/github/awesome-copilot/blob/main/skills/git-commit/SKILL.md and github-pr-workflow https://github.com/YPares/agent-skills/blob/main/github-pr-workflow/SKILL.md . Here is an excerpt of the skill file. Source: https://github.com/github/awesome-copilot/blob/main/skills/git-commit/SKILL.md name: github-pr-workflow description: Working with GitHub Pull Requests using the gh CLI. Use for fetching PR details, review comments, CI status, and understanding the difference between PR-level comments vs inline code review comments. GitHub PR Workflow Key Concepts Comment Types GitHub PRs have two different types of comments : 1. PR-level comments - General discussion on the PR shown via gh pr view --comments 2. Inline code review comments - Comments attached to specific lines of code requires API Important : gh pr view --comments does NOT show inline code review comments Scripts | Script | Purpose | |--------|---------| | gh-pr-info <PR REPO | Comprehensive PR info : summary, CI checks, and unresolved review and inline comments | The script auto-detects the repo from the git remote, or accepts REPO as a second argument format: owner/repo . Key features : - Uses GitHub's GraphQL API to reliably filter out already resolved/addressed comments. - Excludes collapsed/hidden review threads. - Excludes minimized comments marked as spam/off-topic/resolved . - Excludes dismissed reviews. - Shows only what still needs attention. Common Commands Get complete PR info with UNRESOLVED comments only gh-pr-info <PR REPO ✅ Everything you need: summary, checks, reviews, unresolved comments The declaration of custom skills in Open WebUI follows similar steps to those of tools. Follow these steps: Skills , and either Import to select the downloaded file, or + New Skill and paste the file content in the editor window Access , and ensure that Public is selected in the appearing drop-down menu -see the following screenshot: The skill needs to be configured for the model too. After adding the new skill to a Python Engineer model, I tried to get the skill invoked. Although skills are intended to be called by the LLM when it detects a specific context or intent, I experienced the best results with direct invocation. In Open WebUI, direct keyword invocation occurs when the command starts with $ . Here is an example chat output in which the Python project from my previous article about is continued. The prompt instructed the model to systematically commit the changes. https://admantium.com/blog/llm40 open webui admin configuration/ I’ll configure the repo-local git identity, inspect the repo state, then create the planned conventional commits one by one and show each command with output. Approved. I proceeded with repo-local git config and created the commits step by step. Plan executed - Set local git identity - Inspect repo state - Initialize git repo if needed - Create 4 logical commits: - chore: initialize repository structure - build: add Python API dependencies - feat api : add FastAPI app with config endpoint - feat config : add model config data Running a git log command in the folder shows the successful application of these commands. php commit a01ddf84128e6f09276c449d94b62da1ff9064ba HEAD - master Author: python-engineer <agent4223@python.org Date: Sun Jul 5 14:21:42 2026 +0000 feat config : add model config data commit 53991af08e9d57b1b89503c9ac0ddcd39e1519e0 Author: python-engineer <agent4223@python.org Date: Sun Jul 5 14:21:42 2026 +0000 feat api : add FastAPI app with config endpoint commit 4905c33d72afd5a95929a2313c331b36da83ca08 Author: python-engineer <agent4223@python.org Date: Sun Jul 5 14:21:42 2026 +0000 build: add Python API dependencies commit d2ea8ce702ff159b1438949d26f83e56f2d7d55d Author: python-engineer <agent4223@python.org Date: Sun Jul 5 14:21:42 2026 +0000 chore: initialize repository structure Models with custom tools and skills can be invoked in four different ways. The native Open WebUI chat interface is bound to the selected model. Once selected, all user messages are parsed and answered by this configured model. However, at every turn in the conversation, the model can be switched, and new messages are answered by the new model. This opens a myriad of questions surrounding conversational flow. Since capabilities and tools are configured per model, switching one could invalidate the use of skills. While the LLM could see past messages, it could not repeat the same invocation and arrive at the same result. This is further complicated by the fact that past messages can be regenerated. Automations allow model calls on defined schedules. They are accessible from the user menu. Follow these steps: Automations + New Automation button To run a command every 5 minutes, the time modifier would be RRULE:FREQ=MINUTELY;INTERVAL=5 . Here is a screenshot showing how this invocation is defined: Invocations of an automation appear as normal chats in the chat list. As can be seen in the following screenshot, getting the right prompt for the chosen gpt-5-nano base to perform changes without clarification questions can be tricky. Instead of creating an Open WebUI agent via base model declaration, there is also the option to use just the chat interface and connect to an agent system. Three options are explained in the official documentation: OpenClaw https://github.com/openclaw/openclaw , Hermes https://github.com/nousresearch/hermes-agent , and Open WebUI Computer https://github.com/open-webui/computer , which promises uniform API-based access to operations on a computer. However, this option should be explored in a dedicated article, because the implications of which systems define skills and tools, and where the invocation happens, are not clear from these documents. There is no native integration to connect Open WebUI to a communication channel. But during my research, I encountered the following GitHub projects. Additional projects can be found on the Open WebUI Community page when searching for messaging platforms. Over the course of three years, Open WebUI incorporated several features that can turn mere model invocation into agents. Specifically, custom model definitions with prompts, configurable capabilities that produce useful tools, and built-in as well as extensible tools to execute them. Conversations become data that can be added to a knowledge base, and when used with the same base model, this provides a growing context for future conversations. Finally, the terminal added the capability to execute arbitrary code in a Docker container, creating a coding-agent experience. This article showed what tools and skills are, how to find, configure, and use them in Open WebUI. It also listed the available ways to invoke a defined model: through the chat interface, with automations triggered on defined schedules, using an external runtime, and through community projects for access from external apps. But are these features sufficient to create true agents? And how does this experience compare with other agent systems? Future articles may explore these questions.