{"slug": "open-webui-scheduling-agents", "title": "Open WebUI: Scheduling Agents", "summary": "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.", "body_md": "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.\n\nThis 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.\n\n*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.*\n\n*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.*\n\n*This article originally appeared at my blog [admantium.com](https://admantium.com/blog/llm42_open_webui_custom_agents_and_invocations/)*.\n\nTools 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.\n\nWhile 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).\n\nHere is an example of adding a tool that shows the current weather.\n\nThe first step is to find an appropriate tool and get its files.\n\nOn the community marketplace:\n\n`Get` button (an account is required).\nAlternatively, the Python file can be downloaded from the linked [GitHub repository](https://github.com/iChristGit/OpenWebui-Tools/blob/main/Tools/weather.py).\n\nThe 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.\n\nAs 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:\n\n`Workspace`, then `Models`\nTo test this new weather tool, I created a new model named `assistant`, based on GPT-5.4, and added the tool.\n\nWhen 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.\n\nSkills 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.\n\nSkill 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).\n\nHere is an excerpt of the skill file.\n\n```\n# Source: https://github.com/github/awesome-copilot/blob/main/skills/git-commit/SKILL.md\n\n***\nname: github-pr-workflow\ndescription: 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.\n***\n\n# GitHub PR Workflow\n\n## Key Concepts\n\n### Comment Types\n\nGitHub PRs have **two different types of comments**:\n\n1. **PR-level comments** - General discussion on the PR (shown via `gh pr view --comments`)\n2. **Inline code review comments** - Comments attached to specific lines of code (requires API)\n\n**Important**: `gh pr view --comments` does NOT show inline code review comments!\n\n## Scripts\n\n| Script | Purpose |\n|--------|---------|\n| `gh-pr-info <PR> [REPO]` | **Comprehensive PR info**: summary, CI checks, and unresolved review and inline comments |\n\nThe script auto-detects the repo from the git remote, or accepts `[REPO]` as a second argument (format: `owner/repo`).\n\n**Key features**:\n- Uses GitHub's GraphQL API to reliably filter out already resolved/addressed comments.\n- Excludes collapsed/hidden review threads.\n- Excludes minimized comments (marked as spam/off-topic/resolved).\n- Excludes dismissed reviews.\n- Shows only what still needs attention.\n\n## Common Commands\n# Get complete PR info with UNRESOLVED comments only\ngh-pr-info <PR> [REPO]             # ✅ Everything you need: summary, checks, reviews, unresolved comments\n```\n\nThe declaration of custom skills in Open WebUI follows similar steps to those of tools. Follow these steps:\n\n`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:\nThe skill needs to be configured for the model too.\n\nAfter 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 `$`.\n\nHere 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/)\n\n```\nI’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.\n\nApproved. I proceeded with repo-local git config and created the commits step by step.\n\nPlan executed\n- Set local git identity\n- Inspect repo state\n- Initialize git repo if needed\n- Create 4 logical commits:\n  - `chore: initialize repository structure`\n  - `build: add Python API dependencies`\n  - `feat(api): add FastAPI app with config endpoint`\n  - `feat(config): add model config data`\n```\n\nRunning a `git log` command in the folder shows the successful application of these commands.\n\n``` php\ncommit a01ddf84128e6f09276c449d94b62da1ff9064ba (HEAD -> master)\nAuthor: python-engineer <agent4223@python.org>\nDate:   Sun Jul 5 14:21:42 2026 +0000\n\n    feat(config): add model config data\n\ncommit 53991af08e9d57b1b89503c9ac0ddcd39e1519e0\nAuthor: python-engineer <agent4223@python.org>\nDate:   Sun Jul 5 14:21:42 2026 +0000\n\n    feat(api): add FastAPI app with config endpoint\n\ncommit 4905c33d72afd5a95929a2313c331b36da83ca08\nAuthor: python-engineer <agent4223@python.org>\nDate:   Sun Jul 5 14:21:42 2026 +0000\n\n    build: add Python API dependencies\n\ncommit d2ea8ce702ff159b1438949d26f83e56f2d7d55d\nAuthor: python-engineer <agent4223@python.org>\nDate:   Sun Jul 5 14:21:42 2026 +0000\n\n    chore: initialize repository structure\n```\n\nModels with custom tools and skills can be invoked in four different ways.\n\nThe 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.\n\nAutomations allow model calls on defined schedules. They are accessible from the user menu. Follow these steps:\n\n`Automations`\n`+ New Automation` button\nTo run a command every 5 minutes, the time modifier would be `RRULE:FREQ=MINUTELY;INTERVAL=5`.\n\nHere is a screenshot showing how this invocation is defined:\n\nInvocations 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.\n\nInstead 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.\n\nThere is no native integration to connect Open WebUI to a communication channel. But during my research, I encountered the following GitHub projects.\n\nAdditional projects can be found on the Open WebUI Community page when searching for messaging platforms.\n\nOver 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.", "url": "https://wpnews.pro/news/open-webui-scheduling-agents", "canonical_source": "https://dev.to/admantium/open-webui-scheduling-agents-3e1a", "published_at": "2026-10-22 05:30:00+00:00", "updated_at": "2026-10-22 05:40:27.299133+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-products"], "entities": ["Open WebUI", "Ollama", "OpenAI", "GPT-5.4", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/open-webui-scheduling-agents", "markdown": "https://wpnews.pro/news/open-webui-scheduling-agents.md", "text": "https://wpnews.pro/news/open-webui-scheduling-agents.txt", "jsonld": "https://wpnews.pro/news/open-webui-scheduling-agents.jsonld"}}