denkeeper

A security-first personal AI agent that lives in your chat. Built in Go as a single binary, designed to run anywhere from a Raspberry Pi to a cloud VM.

Denkeeper connects to your Telegram or Discord, routes messages through LLM providers via Anthropic, OpenAI, OpenRouter, or a local Ollama instance, and remembers conversations across sessions using a local SQLite database. It enforces per-session cost budgets, user allowlists, and a tiered permission system — so you stay in control of what it can do and how much it can spend.

Installation

One-liner (Linux and macOS)

curl -fsSL https://raw.githubusercontent.com/Temikus/denkeeper/main/install.sh | sh

To install to a custom prefix (e.g. without sudo):

curl -fsSL https://raw.githubusercontent.com/Temikus/denkeeper/main/install.sh | sh -s -- --prefix ~/.local

The installer detects OS/arch, downloads the correct release archive, verifies the SHA-256 checksum, and places the binary in <prefix>/bin.

Debian / Ubuntu (.deb)

VERSION=$(curl -fsSL https://api.github.com/repos/Temikus/denkeeper/releases/latest | grep '"tag_name"' | sed 's/.*"\(v[^"]*\)".*/\1/')
curl -fsSL "https://github.com/Temikus/denkeeper/releases/download/${VERSION}/denkeeper_${VERSION#v}_linux_amd64.deb" -o denkeeper.deb
sudo dpkg -i denkeeper.deb

Configure and start the service:

sudo cp /etc/denkeeper/denkeeper.toml.example /etc/denkeeper/denkeeper.toml
sudoedit /etc/denkeeper/denkeeper.toml
sudo systemctl enable --now denkeeper
journalctl -u denkeeper -f

RHEL / Fedora (.rpm)

VERSION=$(curl -fsSL https://api.github.com/repos/Temikus/denkeeper/releases/latest | grep '"tag_name"' | sed 's/.*"\(v[^"]*\)".*/\1/')
curl -fsSL "https://github.com/Temikus/denkeeper/releases/download/${VERSION}/denkeeper_${VERSION#v}_linux_amd64.rpm" -o denkeeper.rpm
sudo rpm -i denkeeper.rpm

Docker

docker pull ghcr.io/temikus/denkeeper:latest
docker run -d --name denkeeper \
  -v ~/.denkeeper:/data \
  ghcr.io/temikus/denkeeper:latest

The container reads config from DENKEEPER_CONFIG (default /data/denkeeper.toml). Override with -e DENKEEPER_CONFIG=/path/to/config.toml.

Helm (Kubernetes)

A Helm chart is available in deploy/helm/denkeeper/ with support for Ingress, PVC persistence, secrets management, and security-hardened pod defaults:

helm install denkeeper deploy/helm/denkeeper/ \
  --set secrets.llmAnthropicApiKey=sk-ant-... \
  --set secrets.telegramToken=123456:ABC...

Homebrew (macOS)

brew install Temikus/denkeeper/denkeeper

Verify release signatures

All release archives are signed with cosign (keyless OIDC — no long-lived keys):

cosign verify-blob \
  --signature checksums.txt.sig \
  --certificate checksums.txt.pem \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  --certificate-identity-regexp='https://github.com/Temikus/denkeeper/.github/workflows/release.yml.*' \
  checksums.txt

Docker images are signed and carry SLSA build provenance attestations:

cosign verify \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  --certificate-identity-regexp='https://github.com/Temikus/denkeeper/.github/workflows/release.yml.*' \
  ghcr.io/temikus/denkeeper:latest

Features

• Single binary — no runtime dependencies, no containers required
• Multi-agent routing — run multiple named agents, each with their own persona, skills, LLM model, and permission tier
• Telegram + Discord — chat with your agent from your phone or Discord server, including inline Approve/Deny buttons for supervised actions; both adapters can run simultaneously
• User allowlist — only approved user IDs can interact (per-adapter)
• LLM routing — pluggable provider interface; Anthropic (direct), OpenAI (direct + Azure/vLLM-compatible), OpenRouter (cloud, hundreds of models), and Ollama (local inference) built-in
• Fallback strategies — automatic model/provider switching on errors, rate limits, or low funds
• Cost tracking — per-session budgets with automatic cutoff
• Conversation memory — SQLite-backed, persistent across restarts
• Scheduler — cron expressions, named intervals, and @daily/@hourly shorthand; per-schedule agent targeting and session modes
• Skills — flat markdown files with TOML frontmatter; trigger-based filtering (command:/schedule:), per-agent skill merging, and per-skill max_tool_rounds caps on the tool-call loop
• MCP tools — spawn MCP servers via stdio (subprocess) or SSE/Streamable HTTP (remote), discover tools, and execute tool calls in an agentic loop; auto-restart on crash with configurable backoff; OAuth 2.1 authorization for remote MCP servers; within-turn memoization of identical calls to read-only tools (built-ins always eligible; external servers opt in via idempotent, idempotent_tools, or trust_annotations)
• Web tools — built-in web_search (DuckDuckGo or Tavily) and web_fetch (HTML→Markdown conversion with configurable per-call page size, size/timeout caps, robots.txt/agents.txt respect, and optional Jina Reader fallback for JS-heavy pages)
• MCP security — SSRF protection (blocks localhost, link-local, and cloud metadata endpoints), HTTP header injection prevention, redirect target validation, env var denylist for secrets, and URL/arg redaction in API responses
• Plugin system — subprocess and Docker-sandboxed plugins with capability declarations and Ed25519 signature verification; tools capability wires plugin tools into the agent's LLM loop
• Runtime tool management — add and remove MCP tools and plugins at runtime without restarting; changes are persisted to TOML config
• Agent KV store — per-agent key-value storage with optional TTL, exposed as MCP tools (kv_get/kv_set/kv_delete/kv_list/kv_set_nx); useful for locks, counters, caches, and cross-session state
• Supervisor agents — a supervised agent can designate another agent as its supervisor via supervisor = "agent-name" in TOML; the supervisor sits between auto-approve rules and human approval, returning APPROVE/DENY/ESCALATE for each tool call; supervisor prompt includes skill/schedule context for scheduled invocations; configurable timeout (supervisor_timeout, default 30s) and context message count (supervisor_context_messages, default 5); LLM failures emit a supervisor_error event before falling through to human approval
• Dry runs — preview what a schedule or skill would actually do without letting it do anything: the real persona, skills, and read-only tools run, while every write is suppressed and nothing is persisted, sent to an adapter, or remembered; returns a full transcript with suppressed calls marked, and accepts an as_of clock so a preview of a dated task is reproducible
• Audit log — unified audit trail with buffered emitter, SQLite storage, and 12 event categories (tool_call, skill, channel, approval, schedule, llm, config, session, mcp, safety, supervisor, eval); web UI page with timeline and table views, category/status/agent/time filters, and a source-exclusion filter that hides dry-run noise by default
• Channels — named routing endpoints ([[channels]]) that decouple sessions from adapters; cross-adapter session sharing, ephemeral session mode, /session command for runtime switching; auto-synthesized from agent adapters bindings when absent (backward compatible)
• Safety commands — /stop cancels the current in-flight request, /panic emergency-stops all in-flight requests and pauses the scheduler, /resume clears panic state; available in Telegram, Discord, web UI, and REST API
• Session history management — /clear removes all messages from a session, /compact summarises via LLM and replaces all messages with a single summary; available in Telegram, Discord, web UI, and REST API
• OpenAPI spec — generated via swaggo/swag, served at GET /api/v1/openapi.json (no auth required); the committed spec is kept in sync with the handler annotations by a CI freshness gate
• Web dashboard — embedded Svelte UI (served via the API server) with 17 pages: overview, chat, sessions, approvals, schedules, skills, tools, browser, KV store, costs, agents, API keys, providers, server config, settings, audit log, and channels; includes dark mode toggle and warm light theme
• Voice — speech-to-text and text-to-speech via OpenAI (Whisper + TTS)
• Permission tiers — autonomous, supervised (default), and restricted; configurable per-agent or per-schedule
• Approval workflows — supervised-tier actions (profile updates, skill creation, schedule additions, tool installation) require explicit human approval via chat buttons (Telegram/Discord) or REST API; auto-approve rules in three scopes: config (declared per agent in TOML via auto_approve_tools, immutable at runtime), session (in-memory, 15m TTL), and permanent (SQLite)
• Config MCP server — per-agent in-process MCP tools let the LLM manage skills, schedules, tools, plugins, KV storage, and inspect its own permission tier at runtime
• Deterministic compute (run_javascript) — per-agent in-process tool that runs a short JavaScript snippet (sandboxed goja runtime, no network/filesystem) against JSON input to transform, format, classify, or bucket data off the completion-token path; bounded by [script] timeout and input/output size caps (default timeout = "2s", max_output_chars = 16000, max_input_bytes = 262144); disabled in restricted tier
• External REST API — HTTP server with scoped API key auth, rate limiting, CORS, and TLS support; chat endpoint with real-time token streaming (SSE + WebSocket), session management, approval CRUD, tool/plugin CRUD, LLM provider management, server reload/restart, and API key management
• Dashboard authentication — password login (bcrypt), OAuth2/OIDC SSO (PKCE), session cookies (AES-256-GCM)
• OpenTelemetry observability — Prometheus /metrics endpoint and optional OTLP trace export
• CLI plugin signing — denkeeper plugin keygen/sign/verify commands for Ed25519 plugin binary signing and verification
• CLI password hashing — denkeeper passwd generates a bcrypt hash for dashboard password login
• Personality — ships with a SOUL.md that gives the agent character (editable)

Architecture

Adapter (Telegram/Discord) ─┐
Web Dashboard (WS/SSE) ─────┼→ Dispatcher → Engine (per agent) → LLM Router → Provider (Anthropic/OpenAI/OpenRouter/Ollama)
REST API (/api/v1/chat) ────┘                    ↕                    ↕
                                             MemoryStore          CostTracker
                                             (SQLite)              + Pricing Registry

Scheduler ──────────────────────────────────────┘

The Dispatcher routes incoming messages to named agent Engines based on adapter bindings. Each Engine checks permissions, loads conversation history, builds the system prompt (persona + skills), calls the LLM (with tool-call loop if MCP tools are configured), stores the response, and sends it back through the adapter.

Quick start

Prerequisites

• Go 1.26+ (managed via mise — see .mise.toml)
• A Telegram bot token (from @BotFather)
• An API key for your chosen LLM provider: OpenRouter, Anthropic, or a local Ollama instance
• Your Telegram user ID (from @userinfobot)

Setup

# Clone
git clone https://github.com/Temikus/denkeeper.git
cd denkeeper

# Copy and edit the config
mkdir -p ~/.denkeeper
cp denkeeper.toml.example ~/.denkeeper/denkeeper.toml
# Fill in your token, API key, and user ID
$EDITOR ~/.denkeeper/denkeeper.toml

# Build and run
just build
./pkg/bin/denkeeper serve

Or run directly without building:

just serve

Configuration

Denkeeper uses a single TOML file (default ~/.denkeeper/denkeeper.toml). See denkeeper.toml.example for all options. The config path can be set via --config flag or DENKEEPER_CONFIG env var.

Health check: GET /api/v1/health returns {"status":"ok"} with no authentication required. Use this for Docker HEALTHCHECK or Kubernetes liveness/readiness probes (requires api.enabled = true).

Key sections:

Environment Variables

Secrets and select config fields can be set via environment variables, which take precedence over values in denkeeper.toml. This enables the standard Kubernetes pattern of using a ConfigMap for config and a Secret for credentials.

A Helm chart is available in deploy/helm/denkeeper/ for Kubernetes deployments.

Skills

Skills are markdown files that teach the agent how to handle specific tasks. They use TOML frontmatter enclosed in +++ delimiters:

+++
name = "daily-briefing"
description = "Compile and deliver a daily briefing"
version = "1.0.0"
triggers = ["schedule:daily:08:00", "command:briefing"]
+++

# Daily Briefing

When triggered, compile a briefing with:
1. Weather forecast for the user's location
2. Top 3 news headlines
3. Any pending reminders

Place skill files in ~/.denkeeper/skills/ (configurable via [agent] skills_dir). Subdirectories with a SKILL.md file are also supported. Skills with triggers are only injected when matched; skills without triggers are always included.

Agent-specific skills in <persona_dir>/skills/ override global skills of the same name.

A sample help skill is included in agents/default/skills/.

Every skill change made at runtime — by the agent about itself, over REST, or over MCP — is recorded in an undo journal before it happens, capturing the file's exact prior bytes. The skill_revert MCP tool rolls the most recent change back, so an agent that botches an edit to its own skill can be fixed with one call instead of by hand. Reverting restores the skill file only: it does not undo messages already sent, tool calls already made, or KV keys already written while the changed skill was live.

Multi-Agent

Define multiple agents, each with their own persona, skills, LLM model, and adapter bindings:

[[agents]]
name = "default"
persona_dir = "~/.denkeeper/agents/default"
adapters = ["telegram"]              # wildcard: all Telegram messages

[[agents]]
name = "work-assistant"
persona_dir = "~/.denkeeper/agents/work-assistant"
adapters = ["telegram:987654321"]    # specific chat only
llm_model = "openai/gpt-4o"
session_tier = "supervised"
supervisor = "default"               # optional: auto-review tool calls before human approval

If no [[agents]] section is present, a single "default" agent is synthesized from [agent]/[session].

Schedules

Schedules support three expression formats, per-schedule agent targeting, and configurable session modes:

[[schedules]]
name = "daily-briefing"
type = "agent"
schedule = "0 8 * * *"
skill = "daily-briefing"
agent = "default"                # target agent (default: "default")
session_tier = "supervised"
session_mode = "isolated"        # fresh context each run (default: "shared")
channel = "telegram:YOUR_CHAT_ID"
enabled = true

[[schedules]]
name = "hourly-check"
type = "agent"
schedule = "@every 1h"           # or @daily, @hourly, @weekly
channel = "telegram:YOUR_CHAT_ID"

session_mode = "isolated" creates a fresh conversation context for each run so scheduled jobs don't mix into your regular chat history.

Dry runs — "what would this actually do?"

Schedules and skills both have a preview that runs the real turn with its hands tied. Hit Test now on a schedule row (or Dry run on a skill) in the dashboard, or call the API directly:

curl -X POST localhost:8080/api/v1/schedules/nightly-digest/dry-run \
  -H "Authorization: Bearer $DENKEEPER_API_KEY" \
  -d '{"as_of":"2026-07-06T07:00:00Z"}'

The turn goes through the whole engine — persona, matched skills, tool loop, budget hints. What changes is the execution policy:

• Read-only tools execute for real, so the model reasons about the actual world. "Read-only" is the same idempotency signal the engine already uses for within-turn memoization: the built-in allowlist plus whatever external servers opted into via idempotent / idempotent_tools / trust_annotations.
• Everything else is suppressed and gets [dry-run: write suppressed — <name> not executed; assume success] back, so the model keeps planning against a plausible world. Unknown tools are suppressed too — the allowlist is the only thing that vouches for a call.
• Nothing is persisted. No conversation row, no messages, no telemetry, no memory extraction, no reviewer trigger. The transcript is returned to you and lives nowhere else.
• Approvals are skipped. Suppressed calls execute nothing to approve, and the calls that do run are read-only by definition.
• as_of pins the clock for both places a date reaches the model (the scheduled-message header and the ## Current Date prompt section), so previewing a July task in September doesn't silently drift.

A skill fires three ways and only one of them involves a message, so the skill endpoint takes a mode rather than always asking for one:

Omit mode and it is inferred from the skill's triggers, so the default is always the entry point the skill actually has. Only schedule names the skill (which forces its body to be injected); command and message leave it unnamed so ordinary trigger matching runs — which means a command preview exercises the trigger, not just the body.

Both endpoints also accept a model override, which runs the preview against a model other than the agent's live one and changes nothing about the agent:

curl -X POST localhost:8080/api/v1/skills/pamela/heartbeat/dry-run \
  -H "Authorization: Bearer $DENKEEPER_API_KEY" \
  -d '{"message":"summarise yesterday","model":"moonshotai/kimi-k3"}'

The override clones the router rather than mutating it, so previewing a candidate model can never retarget a live turn already in flight. The response echoes requested_model alongside the model that actually answered, so a transcript is self-describing.

In the dashboard this is the panel's first model slot; the second slot is empty by default, and filling it runs the same turn against both models and shows the deltas (rounds, bad tool args, cost, latency). One sample per side is a smoke test, not a verdict — the panel says so, and points at a full eval for anything you intend to decide on.

Dry runs still cost real tokens, so both endpoints sit behind their parent resource's write scope (schedules:write / skills:write).

Every audit event a dry run emits carries source = "dryrun" and a pseudo-agent like pamela#dryrun — the record is complete, but ?agent=pamela never returns them and the dashboard hides them until you flip Previews → Show dry runs & evals. Turn the volume down with:

[eval]
audit = "summary"   # lifecycle events and errors only; default is "full"

Evals — "is this candidate model actually better for my agent?"

A dry run answers one question once. An eval asks it thirty times and does the arithmetic. Save real turns as test cases from the Chat page's message menu ("Save as test case", optionally pinning the preceding turns as context), then compare your current config against a candidate over the whole set:

curl -X POST localhost:8080/api/v1/eval/runs \
  -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
  -d '{"task_set":"regression","base_agent":"pamela","k":3,
       "variants":[{"name":"incumbent"},{"name":"candidate","llm_model":"moonshotai/kimi-k3"}]}'

The run proceeds in the background on the agent's live engine — real persona, real skills, real tools — under the same policy dry runs use, so reads happen and writes do not. GET /eval/runs/{id}/summary then reports the objective half of the verdict, no judge involved: per-variant rejected and failed tool-call rates, mean rounds, wrap-up count, cost per task, latency, and per-task deltas against the incumbent. A test set is an appreciating asset — the next candidate model starts here rather than at a blank page.

Runs are bounded twice, by spend and by rate. Crossing cost_cap stops dispatching new samples, lets the in-flight ones finish, and keeps the partial results as capped — never a silent truncation. POST /api/v1/panic cancels active runs along with everything else, and resume deliberately does not revive them: a panic is not a pause. A sample that fails takes only itself down; the summary says how many of the expected samples landed and calls the run inconclusive below completeness_floor rather than reading a verdict off thin data.

Task sets export and import as JSONL (GET/POST /eval/task-sets/{name}/export|import), so a curated set can be hand-edited, committed to git, or moved between instances.

Judging — blinded A/B pairs, scored from Claude Code

The objective half can reject a candidate on its own, but it can't promote one: "cheap and quiet" is not the same as "better". When a run finishes it pairs the incumbent and candidate samples for each test case, assigns each pair a random A/B identity that never leaves the server, and queues two judgment items per pair with the presentation order swapped — so position bias splits the vote instead of deciding it. A pair only counts once both orders have been judged, and if the two calls name different sides the pair records as a tie.

The judge is Claude Code over Denkeeper's MCP server, working the queue with eval_pending → eval_get_pair → eval_verdict, then reading eval_summary. Everything that would identify a side — model, provider, variant name, cost, latency, token usage, even the sample's conversation id — is withheld; the payload is built from scratch rather than filtered, so a new field can't leak into it by default. Give the judge a key scoped to eval:read,eval:write and nothing more.

The rubric lives in .claude/skills/judge-eval/SKILL.md, where you can read and edit it: four dimensions in priority order (task_success, tool_path, persona_fit, length), with instructions to cite the specific persona or skill clause behind any deduction. On a new rubric, judge a random ~20-item calibration subset interactively and record your own call alongside the judge's (judge_ident: "operator"); eval_summary reports the agreement rate. Below roughly 80 %, fix the rubric before letting it run headless — a drifted rubric quietly devalues every later run.

GET /eval/runs/{id}/summary then returns the verdict with its work: the gate table (each value, delta, threshold and pass/fail), a one-line reason, the win-rate, and a per-category breakdown. The rule is conjunctive and asymmetric — a candidate is an upgrade only if the judge win-rate reaches win_threshold and no objective gate regressed; a failed gate is a downgrade whatever the judge thought. A candidate that wins overall while regressing on tool-heavy tasks says so out loud rather than hiding inside an average:

downgrade: mean rounds regressed +35.0% against a +20.0% threshold
upgrade: judge win-rate 62% over 45 judged pair(s) meets the 55% threshold, and no objective gate regressed
  ↳ wins overall; regresses on tool_heavy

REST API

The API server and web dashboard are enabled by default (listening on :8080). All endpoints (except /health) require a Bearer token matching a configured API key.

[api]
listen = "0.0.0.0:8080"

[[api.keys]]
name = "my-client"
key  = "dk-your-secret-key"
scopes = ["chat", "sessions:read", "costs:read"]

Available scopes: chat, admin, agents:read, agents:write, sessions:read, sessions:write, costs:read, skills:read, skills:write, schedules:read, schedules:write, approvals:read, approvals:write, tools:read, tools:write, kv:read, kv:write, channels:read, channels:write, audit:read, eval:read, eval:write

Endpoints:

Chat example:

# Non-streaming
curl -X POST http://localhost:8080/api/v1/chat \
  -H "Authorization: Bearer dk-your-secret-key" \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello!", "session_id": "my-session"}'

# SSE streaming
curl -X POST http://localhost:8080/api/v1/chat \
  -H "Authorization: Bearer dk-your-secret-key" \
  -H "Content-Type: application/json" \
  -H "Accept: text/event-stream" \
  -d '{"message": "Hello!", "session_id": "my-session"}'

Pass the same session_id in subsequent requests to continue the conversation. Omit it to start a new session with an auto-generated ID.

MCP Server

Denkeeper can expose itself as an MCP server, letting external MCP clients (Claude Code, Claude Desktop, Cursor, etc.) use its agents, skills, schedules, sessions, and tools directly. The endpoint supports both Streamable HTTP (default) and SSE transports.

Enable in config:

[api.mcp_server]
enabled = true
# transport = "streamable"   # or "sse" for legacy clients
# session_timeout = "30m"
# stateless = false

Client configuration:

Claude Code (~/.claude/settings.json or project .claude/settings.json):

{
  "mcpServers": {
    "denkeeper": {
      "type": "http",
      "url": "http://localhost:8080/api/v1/mcp",
      "headers": {
        "Authorization": "Bearer dk-your-secret-key"
      }
    }
  }
}

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "denkeeper": {
      "type": "streamable-http",
      "url": "http://localhost:8080/api/v1/mcp",
      "headers": {
        "Authorization": "Bearer dk-your-secret-key"
      }
    }
  }
}

Other MCP clients that support Streamable HTTP or SSE transports can connect to http://<host>:8080/api/v1/mcp with a Bearer token in the Authorization header.

The API key must have scopes matching the tools you want to use (e.g. chat, agents:read, sessions:read, skills:read, schedules:read). Available MCP tools: chat, agent_list, agent_info, session_list, session_messages, session_search, session_clear, session_compact, skill_list, skill_get, skill_create, skill_update, skill_delete, skill_revert, schedule_list, schedule_create, schedule_update, schedule_delete, channel_list, approval_list, approval_resolve, tool_list, tool_health, tool_restart, kv_get, kv_set, kv_list, kv_delete, cost_summary, telemetry_summary, panic, resume, panic_status.

Development

just is used as the command runner. Run just to see all available recipes:

just build           # Build the denkeeper binary (requires web/dist/ to exist)
just build-ui        # Build the Svelte web dashboard (requires Node.js)
just build-full      # Build web dashboard then Go binary in one step
just serve           # Start the agent (just serve ./path/to/config.toml)
just web-dev         # Start Vite dev server for dashboard hot-reload
just test            # Run all tests with race detector
just test-v          # Verbose test output
just test-pkg <pkg>  # Test a single package (e.g. just test-pkg internal/agent)
just test-cover      # Tests with coverage report
just test-cover-html # Open coverage in browser
just test-ui         # Web UI tests (Vitest + jsdom + MSW)
just test-integration # E2E integration tests (full in-process server + mock LLM)
just lint            # Run golangci-lint
just lint-fix        # Lint with auto-fix
just fmt             # Format all Go files
just fmt-check       # CI-friendly format check
just vet             # Run go vet
just check           # Run all checks (fmt + vet + lint + test + openapi-check)
just openapi         # Generate OpenAPI spec (requires swag CLI)
just openapi-check   # Fail if the committed OpenAPI spec is stale (same gate as CI)
just tidy            # go mod tidy
just clean           # Remove build artifacts
just loc             # Count lines of source vs test code

Project structure

cmd/denkeeper/       Entry point
internal/
  adapter/           Platform integrations
    telegram/        Telegram bot adapter
    discord/         Discord bot adapter
  agent/             Dispatcher, engine, and conversation memory
  api/               External REST API server
  approval/          Approval workflow manager, store, registry, and callback handler
  config/            TOML config parsing and validation
  configmcp/         Per-agent Config MCP server (skill/schedule/tier/tool/KV tools)
  kv/                Per-agent key-value store with TTL
  llm/               Provider interface, router, cost tracking
    anthropic/       Anthropic direct client
    openai/          OpenAI direct client (Azure/vLLM-compatible)
    openrouter/      OpenRouter client
    ollama/          Ollama local inference client
  persona/           Persona file loader (SOUL.md, USER.md, MEMORY.md)
  plugin/            Plugin manager (subprocess and Docker-sandboxed)
  sandbox/           Pluggable sandbox runtime (Docker and Kubernetes backends)
  scheduler/         Cron and interval scheduling
  security/          Permission engine (tiers) and Ed25519 plugin signing
  skill/             Skill file loader, trigger matching, merging
  tool/              MCP tool server manager
    oauth/           MCP OAuth 2.1 authorization for remote tool servers
  voice/             STT/TTS provider interface
    openai/          OpenAI Whisper + TTS client
  web/               Embedded web dashboard handler (serves web/dist/)
web/                 Svelte dashboard source (npm build → web/dist/)
pkg/bin/             Build output (gitignored)
agents/default/
  skills/            Bundled skills (e.g. help.md)
  SOUL.md            Agent personality

License

Apache 2.0