Skip to content

Mapping the 5-Layer Model to Local LLM Environments — Open WebUI Workspace vs. Claude Code

Open WebUI and Claude Code answer the same problem — "How do we package a specialized AI as a reusable unit?" — with strikingly similar structures.

About This Document

Using a locally pulled base model (via Ollama or similar) on its own does not give you a "specialized agent for a specific task." You have to manually compose the system prompt, reference documents, tools, and guidelines for every conversation.

Open WebUI answers this with the Workspace unit. It centralizes Models, Prompts, Knowledge, Skills, Tools, and MCP, letting you build and share a "specialized AI" — a bundle of all of them — directly from the web UI.

This document maps that Workspace onto this site's 5-layer model (Doctrine / Agent / Skills / Memory / MCP) and compares it feature by feature to the Claude Code composition of .claude/agents/ + CLAUDE.md + Skills + MCP. Read it as a map for understanding what is becoming the de facto unit for packaging agents as of 2026.

Positioning of This Document

This page is a strategy-layer document that maps the three-layer model from 03-architecture — extended with the Memory layer (08-memory-and-knowledge) and the Doctrine layer (07-doctrine-and-intent) — onto implementation platforms. Where composition-patterns addresses how to combine, this page addresses where to place.

Meta Information
What this page establishesThe mapping between the 5-layer model and Open WebUI Workspace / Claude Code constructs
What this page does NOT coverOpen WebUI install steps, per-feature tutorials (see primary docs at docs.openwebui.com)
Dependencies03-architecture, 07-doctrine-and-intent, 08-memory-and-knowledge
Common misuseEquating Open WebUI Tools with MCP. They differ in location, execution model, and distribution (see below)

Why a Workspace Unit Emerged

Base models are generic — they have no inherent role like "code reviewer," "translator," or "legal researcher." Giving them a role requires bundling the system prompt, reference knowledge, allowed tools, and decision criteria into a single unit.

Developer analogy

A Workspace is close to package.json + ESLint config + tsconfig + README, bundled together in a web project. Each works alone, but only the bundle becomes "this project's dev environment." For an AI agent, the Workspace plays that role.

Mapping to the 5-Layer Model

Each Open WebUI Workspace feature maps to a layer in this site's 5-layer model as follows.

IMPORTANT

Models is not only "the Agent layer" but also the unit that bundles the other four layers. The official docs describe a Model as "a thin wrapper: pick a base model, configure it, and share it with your team" (Models docs). This is isomorphic to the way .claude/agents/<name>.md declares MCP, Skills, and model settings in its frontmatter in Claude Code.

Correspondence Table

5-Layer ModelOpen WebUI WorkspaceClaude CodeRole
DoctrinePrompts (/command templates), Models' System PromptSlash commands (.claude/commands/*.md), CLAUDE.mdConstraints, objectives, judgment criteria
AgentModels (preset bundle), Base Model selection.claude/agents/<name>.md, main ClaudeTask understanding, orchestration
SkillsSkills (Markdown + view_skill).claude/skills/<name>/SKILL.mdStatic knowledge, guidelines
MemoryKnowledge (RAG / Full Context), NotesMemory files, persistent CLAUDE.md contentPersistent memory, reference documents
MCPMCP (Streamable HTTP, v0.6.31+), Tools (Python)MCP servers (stdio / HTTP)External system connectivity
Out of scopeFunctions (platform extension), PipelinesPlugins (marketplace, .claude/plugins)Platform-level extension

Per-Layer Detailed Mapping

Doctrine Layer — Prompts and System Prompt

Open WebUI Prompts fire as slash commands like /summarize and can generate a form with typed input variables. The System Prompt is bound to a Models preset and supports dynamic variables like {{ USER_NAME }}, {{ CURRENT_DATE }}, and {{ USER_GROUPS }} (Prompts docs, Models docs).

These correspond to two distinct constructs in Claude Code.

Open WebUIClaude CodeShared role
Prompts (/command)Slash commands (.claude/commands/*.md)A unit the user invokes to set behavior
Models' System PromptCLAUDE.md, frontmatter body in .claude/agents/<name>.mdDeclaratively fixed constraints that always hold

TIP

Open WebUI Prompts go one step further than Claude Code slash commands by offering typed input variables like {{title | select:options=["High","Medium","Low"]:required}}. This reflects the target audience — non-engineers using a web UI — versus Claude Code's CLI-first audience.

Agent Layer — How Models Bundle Everything

The "Agent layer bundles the other four layers" structure is most visible in the constituent fields of an Open WebUI Models preset.

This corresponds directly to the frontmatter of .claude/agents/<name>.md in Claude Code.

markdown
name: translation-specialist
description: Specialist agent for technical translation and quality evaluation
tools: deepl:translate-text, xcomet:xcomet_evaluate
model: sonnet
---

You are a technical translation specialist.
Refer to the translation-workflow skill.
FieldOpen WebUI ModelsClaude Code Sub-agent
Base model selectionBase Model fieldmodel: frontmatter
System promptSystem prompt fieldBody under the frontmatter
Tool bindingTools / MCP bindingstools: frontmatter
Skills bindingSkills binding"Refer to <skill>" instruction in body
Knowledge bindingKnowledge bindingReference from CLAUDE.md, or via MCP
Access controlRBAC (users / groups)Substituted by Git branch / PR permissions

IMPORTANT

The pattern "Agent layer declaratively bundles the others" matches across both platforms. This is not a coincidence — it reflects the separation principle from 03-architecture, where "the Agent layer owns orchestration," pushed back into the UI design itself.

Skills Layer — A Convergence in Name and Model

Open WebUI introduced Skills as a first-class feature in the v0.6.x line (Skills docs). What's notable is that its implementation model nearly matches Claude Code Skills.

AspectOpen WebUI SkillsClaude Code Skills
FormatMarkdown + YAML frontmatter (name, description)Markdown + YAML frontmatter (same)
ImportDirectly from .md filesPlace SKILL.md
User-triggered invocation$ mention injects full contentExplicit reference by skill name
Auto invocationBound to a Model → manifest injected; view_skill(name) loads the bodyManifest resident; Read loads the body
Context efficiencyLazy loading (body fetched on demand)Same (lazy loading)
DependencyRequires native function callingRequires tool use

Convergence is a signal of "correct design"

Two teams reaching the same "manifest injection + on-demand body load" model independently strongly suggests this is the correct response to the LLM's context constraints. See Skills structure and the sibling site's Part 5: On-demand Context for the underlying reasoning.

WARNING

Open WebUI Skills lazy loading only works when native function calling is enabled. When disabled, only the manifest is injected and the body is never read (Skills docs / Limitations). The same dependency applies in Claude Code: Skills break if Read is disabled.

Memory Layer — Knowledge's Two Modes

Open WebUI Knowledge is the persistent memory feature, centered on RAG vector search. It supports 9 vector DBs (ChromaDB, PGVector, Qdrant, Milvus, etc.) and 5 extraction engines (Tika, Docling, Azure, Mistral OCR, custom) (Knowledge docs).

There are two retrieval modes.

ModeInjectionBest forContext cost
Focused RetrievalHybrid Search (BM25 + vector) → rerank → inject relevant chunksLarge document sets where only specific sections matterLow (depends on chunk count)
Full ContextInject the document verbatimShort references, style guides — anything always relevantHigh (depends on document size)

Behavior change under native function calling

When native function calling is enabled, Knowledge is not auto-injected. Instead, the model uses tools like list_knowledge, query_knowledge_files, and view_file to proactively explore — an Agentic Retrieval mode. This enables aggressive document exploration but, without an explicit "always consult Knowledge" instruction in the system prompt, the model may ignore its existence entirely (Knowledge docs / Agentic Knowledge Tools).

Correspondence with Claude Code

Open WebUI KnowledgeClaude CodeShared trait
Focused RetrievalRAG via MCP (external vector DB)Dynamic injection of relevant chunks
Full ContextPersistent body of CLAUDE.md, @<path> referencesFull text always resident
Agentic Knowledge ToolsProactive exploration via the Read toolModel-led document discovery

TIP

Placing Knowledge in the "Memory layer" is the natural answer to the scatter-gather problem discussed in the sibling site's Part 8: Memory Layer. It compensates for the base LLM's knowledge boundary with an external, persistent vector DB.

MCP Layer — Three Distinct Constructs

This is the most commonly misunderstood part of Open WebUI. Tools, Functions, and MCP are all different things — they differ in location, execution model, and distribution.

TypeLocationExecution modelDistribution5-layer mapping
ToolsWorkspacePython executed inside the Open WebUI serverCommunity Hub or manual importMCP layer (proprietary variant)
MCPWorkspace (v0.6.31+)Streamable HTTP to remote MCP serversServer URL + OAuth 2.1 / BearerMCP layer (standard-compliant)
FunctionsAdmin PanelPython executed in the serverAdmin-onlyOut of 5-layer scope (platform extension)
PipelinesSeparate processOpenAI API-compatible workflowFor expertsOut of 5-layer scope (infra layer)

CAUTION

Open WebUI Tools run "Python code directly inside the server." This is fundamentally different from MCP's protocol-based separation. Importing community Tools carries the arbitrary-code-execution risk noted in the official docs. Prefer standard-compliant Streamable HTTP MCP whenever possible.

Why Native MCP Support Matters

Open WebUI's v0.6.31 native MCP (Streamable HTTP) support is decisive for this site's structural argument.

  • Transport: Streamable HTTP only (stdio / SSE require the mcpo proxy)
  • Auth: None / Bearer / OAuth 2.1 (DCR) / OAuth 2.1 (Static)
  • Automatic Resource Indicators (RFC 8707)
  • RBAC for per-MCP-tool authorization

IMPORTANT

The fact that "MCP is becoming the de facto external-connection standard even in web-UI-based local LLM environments" reinforces the claim from 02-reference-sources that accumulated MCP-ified sources are the real asset. MCP servers built for Claude Code can now be reused from Open WebUI by configuration alone.

Overall Correspondence Matrix

Projects and Agent Design

Open WebUI's Projects (folder-based workspace bundling) groups Models presets, Prompts, Knowledge, and Skills into a single project unit. This is semantically equivalent to Claude Code's project-root .claude/ directory.

ElementOpen WebUI ProjectClaude Code Project
Unit boundaryFolderGit repository root
Agent definitionsModels presets.claude/agents/*.md
Shared instructionsProject-level System Prompt sharingCLAUDE.md
Shared knowledgeShared Knowledge collectionsReferences in CLAUDE.md + MCP
Shared commandsShared Prompts.claude/commands/*.md
DistributionExport → Import (JSON)git clone

TIP

When designing for project-level portability, the "multi-MCP + multi-Skill coordination" patterns from composition-patterns apply directly. On both Open WebUI and Claude Code, the structure remains: "specialized AI = 1 Agent + N Skills + M MCPs + Doctrine".

Design Implications

Three implications follow.

1. The 5-Layer Model Is Platform-Independent

Open WebUI and Claude Code evolved independently and reached nearly identical layer separations. This is structural evidence that the 5-layer model is platform-independent — backing up the claim in 03-architecture that "layers represent separation of responsibilities, not deployment configuration."

2. Skills' Lazy Loading Has Become a De Facto Standard

The "manifest + on-demand body load" model Claude introduced first now ships natively as the view_skill tool in Open WebUI as well. This makes Markdown-based Skills genuinely portable between platforms — the frontmatter name and description fields form a common spec.

3. MCP Has Reached Local LLM Environments

Native Streamable HTTP MCP support means the shuji-bonji MCP servers (rfcxml-mcp, xcomet-mcp, pdf-reader-mcp, and so on) are usable from local LLMs running behind a web UI. MCP investment is no longer a Claude-Code-only investment — it's an investment in the broader ecosystem.

🔗 Deeper: Why Convergence to This Structure?

This page covered the structural mapping (What/How) between Open WebUI and Claude Code. To understand why independent platforms converge on the same layer separation — grounded in the LLM's structural constraints — see the sibling site.

References

  • Open WebUI (2026). "Models — Wrap any model with custom instructions, tools, and knowledge to build specialized agents." docs.openwebui.com — Official Models preset specification
  • Open WebUI (2026). "Skills — Teach your AI how to approach a task with plain-text instructions." docs.openwebui.comview_skill lazy-loading spec
  • Open WebUI (2026). "Knowledge — Give your AI access to your documents and let it find what matters." docs.openwebui.com — Two retrieval modes and Agentic Retrieval
  • Open WebUI (2026). "Prompts — Reusable slash commands that turn complex instructions into one-click forms." docs.openwebui.com — Declarative instructions for Doctrine-equivalent use
  • Open WebUI (2026). "Tools & Functions (Plugins)." docs.openwebui.com — Python server-side execution model
  • Open WebUI (2026). "Model Context Protocol (MCP)." docs.openwebui.com — Native MCP support in v0.6.31+

Previous: Composition PatternsNext: Development Phases

Last updated: June 2026

Released under the MIT License.