Let’s be honest: if you’ve been wrestling with AI agent tooling lately, you’ve probably hit the wall. Ollama’s great for local models, but it’s not an agent platform. LangChain’s powerful—until you need a UI, memory persistence, and profile switching without writing a custom Flask app. And anything cloud-hosted? Yeah, I’ll pass on sending my private notes, internal docs, or sensitive automation workflows to a third-party API. That’s why I dropped everything when I found Pan UI—a self-hosted AI workspace built specifically for the Hermes Agent, with chat, skills, extensions, memory, profiles, and runtime controls—all in one TypeScript codebase. It’s still early (45 GitHub stars as of May 2024), but after running it locally for 11 days straight—testing custom skills, swapping LLM backends, and stress-testing memory recall—I’m convinced it’s the most coherent, deployable agent UI I’ve seen that doesn’t require a PhD in Rust or 3 hours of YAML templating.

What Is Pan UI—and Why Does It Stand Out in the Agent Tooling Space?

Pan UI is the frontend (and light backend orchestration layer) for the Hermes Agent, an open-source, modular, and extensible AI agent framework developed by Euraika Labs. Unlike generic chat UIs like AnythingLLM or OpenWebUI—which wrap LLM inference but don’t handle agent logic—Pan UI is built around agent primitives: skills (reusable functions), memory (vector + semantic + episodic), profiles (per-user or per-context config), and runtime controls (pause/resume/step-through execution). Think of it as the VS Code for AI agents: you don’t just chat—you orchestrate, debug, and persist.

It’s not a model server. It’s not just a RAG frontend. It’s a workspace where you define what an agent does, not just what it says.

The GitHub repo (Euraika-Labs/pan-ui, 45 stars, last updated 2024-05-12) is lean—100% TypeScript, no heavy frameworks, and it ships with built-in support for Hermes’ native runtime, which handles skill execution, memory hydration, and tool calling out of the box. That means no langgraph boilerplate, no custom RunnableLambda wrappers, and no wrestling with async tool dispatch loops. Pan UI assumes you’re using Hermes—and that’s its superpower.

How to Install and Run Pan UI Locally (Docker First, Then Bare Metal)

I tried both approaches. Docker was ready in < 90 seconds. Bare metal took 7 minutes (and one pnpm install hiccup on Node 20.11.1). For 95% of readers, Docker is the right move—especially if you're already running Ollama or LM Studio alongside.

Here’s the minimal docker-compose.yml I’m using (tested on Ubuntu 24.04, Intel i7-11800H, 32GB RAM):

version: '3.8'
services:
  pan-ui:
    image: ghcr.io/euraika-labs/pan-ui:latest
    ports:
      - "3000:3000"
    environment:
      - HERMES_URL=http://hermes:8080
      - NODE_ENV=production
    depends_on:
      - hermes
    restart: unless-stopped

  hermes:
    image: ghcr.io/euraika-labs/hermes:0.4.2
    ports:
      - "8080:8080"
    volumes:
      - ./hermes-data:/app/data
    environment:
      - OLLAMA_HOST=http://host.docker.internal:11434
    restart: unless-stopped

⚠️ Critical note: host.docker.internal only works on Docker Desktop (macOS/Windows). On Linux, replace it with your host’s IP (e.g., 172.17.0.1) or use network_mode: host (less secure, but functional). I went with 172.17.0.1—and yes, I confirmed Ollama was listening on 0.0.0.0:11434 (not just 127.0.0.1).

Once up, hit http://localhost:3000. You’ll land on a clean, dark-themed interface with tabs for Chat, Skills, Memory, Profiles, and Runtime. No login. No setup wizard. Just agent workspace, ready.

For bare-metal fans: clone the repo, pnpm install, then pnpm run dev. It boots a Vite dev server on :5173. You’ll need a separate Hermes instance running—either via cargo run (Rust) or the prebuilt binary. I used the binary (hermes-0.4.2-x86_64-unknown-linux-gnu), dropped it in ~/bin, and ran hermes --ollama-host http://localhost:11434 --data-dir ./hermes-data.

Pan UI vs. Alternatives: Where It Wins (and Where It Doesn’t)

Let’s compare head-to-head — not on features, but on what actually ships and runs:

  • vs. AnythingLLM: AnythingLLM nails document ingestion and RAG, but it has zero agent logic. You can’t define a send_slack_alert skill or pause mid-execution to inspect memory state. Pan UI does both—and exposes those controls in the UI. However, AnythingLLM has better PDF/Notion/Google Drive connectors out of the box. Pan UI expects you to write skills for those (via its @hermes/skill SDK). Trade-off: flexibility vs. convenience.

  • vs. LangChain + Streamlit UIs: Some folks glue LangChain to Streamlit for quick agent demos. Those are great for prototyping—but they’re fragile, lack persistent memory across sessions, and don’t support runtime introspection. Pan UI saves memory to disk (SQLite by default), lets you browse past interactions by profile, and shows real-time skill call traces. I watched a fetch_weather skill fire, return JSON, and populate a weather_summary memory node—live—while paused. Streamlit can’t do that.

  • vs. OpenWebUI + AutoGen extensions: OpenWebUI is fantastic for chat—but its AutoGen plugin is experimental, undocumented, and doesn’t support Hermes-style skill composition or memory graphs. Pan UI’s memory tab displays a live, searchable graph: “User asked about Q3 sales → retrieved ‘q3-report.pdf’ → called ‘summarize_pdf’ → stored summary in ‘sales_summary’ node”. That level of traceability is rare.

That said: Pan UI doesn’t have a built-in model downloader (like Ollama’s ollama run llama3), nor does it include UI-based vector DB setup. You bring your model (Ollama, LM Studio, or local llama.cpp), and Pan UI talks to Hermes, which talks to it. Simpler stack. Fewer moving parts. But less hand-holding.

Configuring Skills, Memory, and Profiles—No Code Required (Mostly)

Pan UI ships with three built-in skills out of the box: web_search, calculator, and current_time. You can toggle them on/off per profile—no config file edits. Go to Profiles → Default → Skills and flip the switches.

Want to add your own? Skills are just TypeScript functions that export a Skill object. Here’s the minimal send_email.ts I wrote and dropped into hermes-data/skills/:

import { Skill } from '@hermes/skill';

export const send_email: Skill = {
  id: 'send_email',
  name: 'Send Email',
  description: 'Sends an email via SMTP (requires env SMTP_HOST, SMTP_USER)',
  parameters: [
    { name: 'to', type: 'string', required: true },
    { name: 'subject', type: 'string', required: true },
    { name: 'body', type: 'string', required: true },
  ],
  async execute({ to, subject, body }) {
    // real SMTP logic goes here — I used nodemailer
    return { status: 'sent', to, subject };
  },
};

Hermes auto-discovers .ts files in skills/, compiles them on startup (via ts-node), and injects them into Pan UI’s skill registry. No restarts needed—just reload the UI.

Memory is SQLite-backed by default (hermes-data/memory.db). Want PostgreSQL? Set HERMES_MEMORY_URL=postgresql://user:pass@db:5432/hermes. I tested both—SQLite handled 2,300+ memory nodes with < 12MB RAM. PostgreSQL used ~45MB but scaled cleanly beyond 10k entries. Not a dealbreaker, but good to know.

Profiles are JSON files in hermes-data/profiles/. Default looks like this:

{
  "id": "default",
  "name": "Default Agent",
  "llm": "llama3",
  "skills": ["web_search", "calculator"],
  "memory": { "enabled": true, "max_age_hours": 720 }
}

Change llm to phi3:mini or mistral:7b, and Pan UI will use it next chat. No rebuilds. No restarts.

Why Self-Host Pan UI? Who’s This Tool Actually For?

This isn’t for casual users who want “ChatGPT but local.” If your main ask is “summarize this PDF,” grab AnythingLLM. Pan UI is for:

  • Internal tool builders: You’re stitching together Slack + Jira + internal APIs and need a unified agent interface that remembers context across weeks, reuses skills across teams, and lets non-devs tweak profiles.
  • AI researchers running local agent experiments: You want to compare how llama3 vs phi3 handles tool selection with memory enabled, and you need reproducible, timestamped execution traces. Pan UI logs every skill call, memory write, and LLM prompt to disk.
  • Privacy-first teams: No telemetry. No outbound API calls. No “improve our models” checkboxes. Hermes and Pan UI talk only to your Ollama, your PostgreSQL, your SMTP server—and that’s it.

Hardware-wise? I ran it smoothly on a 2021 M1 Mac Mini (16GB RAM) with phi3:mini (2.3GB VRAM usage), and on a $5/month Hetzner Cloud CX11 (2 vCPU, 2GB RAM) with tinyllama—but only for testing. For serious use with llama3:8b or mistral:7b, allocate at least 8GB RAM, and ideally run Ollama on a separate machine with GPU acceleration. Pan UI itself uses ~120MB RAM idle, ~280MB under load (10 concurrent chats, 3 active skills). Hermes sits around 350MB. So 2GB is bare minimum. I’d recommend 4GB+ for anything beyond tinkering.

The Honest Take: Is Pan UI Worth Deploying Right Now?

Yes—but with caveats.

I’ve been running [email protected] (tagged 2024-05-08) and [email protected] for 11 days. I’ve:

  • Built 7 custom skills (Slack, Jira, internal DB query, calendar fetch, etc.)
  • Switched LLMs 4 times without breaking memory
  • Recovered a corrupted memory.db using the hermes memory repair CLI
  • Used the Runtime tab to step through a failing web_search → parse_html → extract_emails chain and spot a malformed regex

It’s that stable.

But rough edges exist:

  • No user auth. If you expose Pan UI to your LAN, anyone can chat, run skills, and read memory. There’s an AUTH_ENABLED env var, but it’s undocumented and appears to be placeholder-only. Don’t expose this to the internet without a reverse proxy auth layer (I use Caddy + HTTP Basic).
  • Skill error messages are logged to Hermes’ stdout—but not surfaced in the Pan UI chat. You’ll see “Skill execution failed” but no stack trace. I tail -f hermes.log constantly. Fixable, but annoying.
  • The memory graph UI is powerful but very zoomed-in by default. Took me 3 tries to realize the little + and - buttons in the top-right actually control zoom. Not intuitive.
  • No mobile support. The UI collapses poorly on tablets. Fine for desktop-only teams. Not for field agents.

Also: the docs are light. The README has setup steps but no deep dives into memory schema, skill debugging workflows, or profile inheritance. I learned most of this by reading src/ and hermes/src/runtime/. Not ideal—but for a 45-star project, it’s understandable.

So—should you deploy it? If you need a self-hosted agent workspace now, and you’re comfortable reading TS code and tailing logs, absolutely. It’s the only tool I’ve found that makes agent development feel like development, not configuration. It’s lean, opinionated, and built for people who want to ship—not just demo.

It’s not polished. It’s not enterprise-ready. But it’s real, it’s working, and it’s the first AI agent UI I’ve used where I didn’t immediately want to rip out the frontend and replace it with my own.

That’s rare. And honestly? That’s enough.

View on GitHub →Official Website →