Get started
Clone, configure, and run a local stack in under 10 minutes.
q15 (Quietscheentchen) is a self-hosted, Telegram-based AI agent runtime built in Go. You talk to it through Telegram; it runs code, reads and writes files, searches the web, manages a persistent knowledge base, and maintains layered memory across conversations.
It is not a cloud service. You run it in Docker Compose or Kubernetes. Your workspace, memory, and skills persist on your own infrastructure.
sequenceDiagram
participant User
participant Agent as q15-agent
participant Exec as q15-exec
participant Proxy as q15-proxy
participant Model as LLM
participant Internet
User->>Agent: Telegram message
Agent->>Agent: Assemble prompt<br/>(core memory, working memory, history)
Agent->>Agent: Select model<br/>(capability inference, fallback order)
Agent->>Model: Send prompt + tools
Model-->>Agent: Response (text or tool calls)
loop Tool execution
Agent->>Exec: Shell command (gRPC)
Exec->>Proxy: Egress request
Proxy->>Internet: Forward (with credentials if rule matches)
Internet-->>Proxy: Response
Proxy-->>Exec: Response (credentials stripped)
Exec-->>Agent: Command output
end
Agent->>Agent: Persist turn to /memory/history/
Agent->>User: Telegram response
q15 is not a monolith. It is three services, each with a clear ownership boundary.
| Service | Owns | Listens |
|---|---|---|
q15-agent |
Prompt assembly, tool wiring, Telegram I/O, memory, file operations | Telegram (long-poll) |
q15-exec |
Command execution, session lifecycle, Nix package management | :50051 (gRPC) |
q15-proxy |
Credential injection, request mutation, TLS interception | :50052 (proxy), :18080 (PAC) |
q15-agent connects to q15-exec at q15-exec:50051. q15-exec routes all outbound traffic through q15-proxy at q15-proxy:50052. The agent never talks to the proxy directly — the exec service is the egress boundary.
A fourth service, q15-qdrant, stores embedding vectors when the embeddings tool is configured.
Most AI agent platforms run everything in one process: the model, the tools, the credentials, and the network access all share a trust domain. If the model is compromised via prompt injection, the attacker has everything.
q15 splits the harness into three services with hard boundaries:
api.github.com, the proxy attaches the token at the network layer. A compromised prompt cannot exfiltrate secrets the agent never had.q15-exec via Nix, not through a general-purpose host shell. File access is rooted to /workspace, /memory, and /skills.This is harness engineering: the architecture makes a compromised model safe by constraining what it can actually do.
Every stack has persistent volumes:
| Path | Purpose |
|---|---|
/workspace |
Durable project tree and working files |
/memory |
Agent identity, semantic knowledge, working state, history |
/skills |
Installed skill artifacts |
/nix |
Nix store and fetched packages (keeps builds warm across sessions) |
/var/lib/q15/proxy |
Proxy-owned durable state |
/workspace may start empty on first deploy. That is a valid initial state. It is expected to persist long-term and survive restarts and upgrades.
One stack = one q15-agent + one q15-exec + one q15-proxy, running together in Compose or Kubernetes. Optionally a q15-qdrant sidecar for embeddings.
In Kubernetes, the supported topology is one namespace per q15 stack. Each stack contains its own ConfigMaps, Secrets, and persistent volumes. The namespace is the isolation boundary.
Interactive auth is handled separately by q15-auth, an operator tool that runs on your machine, not inside the runtime containers. It produces auth.json, which gets mounted into the agent container.
Get started
Clone, configure, and run a local stack in under 10 minutes.
Prompt Injection
Why prompt injection is the fundamental challenge of AI agents, and how q15 defends against it.
Services
Deep dive into q15-agent, q15-exec, and q15-proxy.