Featured image of post Open WebUI: Scheduling Agents
Open WebUI
LLM Agents

Open WebUI: Scheduling Agents

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.

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.

Custom Tools

Definition

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.

Adding Custom Tools to Open WebUI

While there is the option to implement a custom tool following the official documentation, tools can also be imported from the Community Tool Library.

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:

  • Search for the tool in the community marketplace.
  • Click on the Get button (an account is required).
  • Download the JSON file.

Alternatively, the Python file can be downloaded from the linked GitHub repository.

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.

Model Configuration

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:

  1. Go to Workspace, then Models
  2. Select an existing base model, or define a new one
  3. The tools section lists all imported or self-defined tools; activate them for the target model

Tool Invocation

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.

Custom Skills

Definition

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 provides an easy entry point. Search for skills that support GitLab interactions; I encountered git-commit and github-pr-workflow.

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

Adding Custom Skills

The declaration of custom skills in Open WebUI follows similar steps to those of tools. Follow these steps:

  1. On the skill repository page, open the skill file in markdown format, and either save the file or copy its content
  2. In Open WebUI, click on Workspace => Skills, and either Import to select the downloaded file, or + New Skill and paste the file content in the editor window
  3. In the top-right corner, click on Access, and ensure that Public is selected in the appearing drop-down menu -see the following screenshot:

Model Configuration

The skill needs to be configured for the model too.

  1. Go to Workspace, then Models.
  2. Select an existing base model, or define a new one.
  3. In the Skills section, all defined skills should appear. Activate them by selecting their respective checkbox.

Skill Invocation

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.

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.

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

Model Invocation

Models with custom tools and skills can be invoked in four different ways.

Chat Interface

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.

Scheduled

Automations allow model calls on defined schedules. They are accessible from the user menu. Follow these steps:

  • Click the user icon, then click Automations
  • Click the + New Automation button
  • Provide a suitable prompt, and program the schedule with an RRULE, an iCalendar-specific format

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.

Agent Runtime

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, Hermes, and 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.

External Apps

There is no native integration to connect Open WebUI to a communication channel. But during my research, I encountered the following GitHub projects.

  • openwebui-telegram: This repo provides a custom Telegram bridge -it polls Telegram server endpoints for messages, and when receiving them, contacts the configured Open WebUI API endpoint for chat completions. Messages are parsed back and forth between these two APIs
  • open-webui/bot: An experimental project that wraps Open WebUI’s channel feature and implements a bot interface. However, there is no direct connection to a messaging service or platform
  • open-webui-utils: A repository that contains two Open WebUI tools for outbound message integration, one for Telegram and one for Discord

Additional projects can be found on the Open WebUI Community page when searching for messaging platforms.

Conclusion

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.