Introduction — AiHummer Docs

AiHummer is an AI-agent platform for business — available as a managed cloud or self-hosted. It ingests messages from employee and customer channels, routes each one to the right agent, runs a function-calling turn with tools and long-term memory, and delivers the answer back to the originating channel — all managed from a web admin UI and an OpenAI-compatible API.

It is a complete product, not a framework or an SDK. A single self-contained service acts as both the control-plane and the turn engine, so a typical deployment is one service plus PostgreSQL.

What you get

Multi-agent orchestration with sub-agents and optional reasoning strategies (plan-steps, reflect, debate, best-of-N, self-heal).
First-class agents with personas, a structured prompt and a per-agent model.
Long-term memory (Einstein) — facts extracted as reviewable claims, then promoted to memory; recall is wrapped in a data-fence against prompt injection.
Knowledge / RAG with citations, plus deep_research for multi-step reports.
Channels — Telegram, VK, Avito, MAX, Bitrix24, SIP telephony and the mobile and desktop app; availability depends on the installed connectors.
A plugin marketplace with one-click, host-native install.
An encrypted credential vault, enterprise SSO (SAML / LDAP / SCIM / OIDC) and Postgres Row-Level Security for multitenant isolation.

How a turn flows

A channel delivers an inbound message to the gateway.
The router resolves the target agent via bindings, @-mentions or a fallback.
The orchestrator assembles a layered, cache-friendly system prompt and drives a function-calling loop over built-in tools, sub-agents and plugins.
Memory and knowledge ground the answer; both arrive as tool results, never as injected instructions.
The delivery service returns the reply to the originating channel, retrying according to the configured policy and reporting a clear failure if it cannot complete delivery.

channel ─▶ router ─▶ orchestrator (tools · sub-agents · memory · RAG) ─▶ delivery ─▶ channel

Foundational principles

These are not marketing lines — every page in this guide stays inside them.

Host-native, not Docker. AiHummer deploys as a release tarball running under systemd from ~/.aihummer (the home directory of the user who ran the installer). There are no containers or orchestrators.
No mandatory paid models. It runs on free/local models and a Codex/ChatGPT-subscription transport. Per-tenant BYOK keys are optional.
Security as a core property. Envelope-encrypted vault, human-in-the-loop approval gates, idempotent side-effects, prompt-injection data-fencing, IP allowlist and audit.
Stability. SemVer with forward-safe, auto-applied database migrations.

[!NOTE] AiHummer exposes an OpenAI-compatible POST /v1/chat/completions endpoint (with SSE streaming). It does not expose /v1/models or /v1/embeddings, and observability is OTLP-push — there is no Prometheus /metrics endpoint.

Who it is for

Companies that want an internal AI employee answering staff over Telegram or Bitrix24, with memory, knowledge and approval gates.
Customer-facing teams putting an agent on a website, a phone line or a mobile app.
Security-, compliance- and sovereignty-conscious deployments that need self-hosting, no Docker, no mandatory external paid model, encrypted secrets, RLS isolation and SSO.
Platform and IT teams that want a complete product — admin UI, multitenancy, marketplace — instead of assembling a framework.

Cloud or your own server: which to pick

There are two ways to get AiHummer. You choose once, in the personal-account onboarding wizard — and that choice decides what you configure next. You do not need to know anything technical up front; here is a simple comparison.

	Managed cloud	Self-hosted (your server)
Who runs the server	We do — you get a ready address `<name>.cloud.aihummer.ru`	You do — install it on your own Linux server
What you need	Just sign up and pay	A Linux server (root, or a rootless install)
Time to launch	A few minutes after payment	One install command + first login
Free trial	10 days free on the entry plan	Community plan free, no cloud
Updates	Automatic, on our side	The instance updates itself via your link
Best for	Anyone who wants a “just works” assistant with no server of their own	Anyone who needs data sovereignty, their own perimeter, compliance

In short: if you have no server of your own, or would rather not run one, pick cloud. If your data must stay inside your own perimeter and you have a Linux server, pick self-hosted. You can change your mind: while the instance is not yet linked, the onboarding wizard’s “switch path” button lets you flip easily.

I want cloud → Registration & sign-in, then Plans and Order & payment.
I want my own server → Requirements and Installation.

Where to next

Want a full step-by-step first run? Start with the Quickstart — it splits into a cloud and a self-hosted track.
New to running your own server? Continue to Requirements and Installation.
Want the mental model first? Read Gateway & turn engine.
Building against the API? Jump to chat/completions.