Platform Overview

Agentcy is a self-hostable AI agent platform. At the center is a knowledge graph. Around it are connectors that fill the graph and expose live tools, an LLM-driven chat layer that uses those tools, and a scheduler + channels that run agents on a cadence or on events.

This page is the mental model. If you want the code-level view, read System Architecture.

The six things you'll touch

1. Knowledge Graph — a Neo4j graph of everything your connectors ingest. Partitioned by Realm so infrastructure and design don't collide.
2. Connectors — 26 built-in sources (GitHub, AWS, K8s, Slack, SQL, …) plus extensibility via OpenAPI, MCP, and custom crates. Every connector can ingest data into the graph and expose live tools to agents.
3. Chat & Agents — streaming conversations with LLMs (OpenAI, Anthropic, Gemini, Ollama, vLLM, LM Studio). Agents use the catalog meta-tools to discover connector tools on demand rather than stuffing them all into context.
4. Ingestion Pipelines — declarative jobs that pull from connectors, normalize into graph nodes, and schedule resyncs. See Ingestion Pipelines.
5. Tasks, Workers & Workflows — a scheduler for recurring agent runs, a job queue for heavy work, and the orchestrator for multi-step workflows. See Tasks, Workers & Workflows.
6. Channels & Triggers — WhatsApp, Slack, and webhooks that turn inbound messages/events into agent runs. See Channels & Triggers.

How they fit together

 Inbound (events)                                   Outbound
 ───────────────                                    ────────
  WhatsApp ──┐                                 ┌── Replies to WhatsApp
  Slack ─────┤                                 ├── Slack messages
  Webhooks ──┤       ┌─────────────────┐       ├── Artifacts (files, videos)
  Cron ──────┼──────►│  Agent runtime  │──────►├── Graph writes
  UI chat ───┘       │  (chat loop +   │       ├── Connector tool calls
                     │   tool catalog) │       └── Memory & notes
                     └────────┬────────┘
                              │ reads/writes
                     ┌────────▼────────┐
                     │  Knowledge      │
                     │  Graph (Neo4j)  │
                     │  + Memory       │
                     └────────┬────────┘
                              │ fed by
                     ┌────────▼────────┐
                     │  Ingestion      │
                     │  pipelines      │
                     │  (26 connectors)│
                     └─────────────────┘

Every arrow in and out of the agent runtime is governed by Zero-Trust Policies if you enable them, with a full audit log.

A typical session

1. You connect GitHub and Kubernetes from the Connectors page. Both get a first sync that fills the graph with repos, PRs, deployments, pods.
2. You ask in chat: "Why is the checkout service throwing 500s?"
3. The agent sees the message, uses search_connector_tools to find kubernetes.logs_for_service, calls it, reads the graph to find related deploys, cross-references GitHub PRs merged in the last hour.
4. It proposes a fix: "The last deploy bumped the checkout image but DB_POOL_SIZE was not set — PR #412 reverted the default." — with links back to the graph and PR.
5. You mark a Task to re-run this diagnosis every 30 minutes. It now runs headlessly; results arrive in Slack if it finds the issue.

That's the loop: ingest → query → act → schedule.

What's optional

The minimum install is agentcy-api + PostgreSQL + Neo4j + Redis + an LLM provider. Everything else is opt-in:

Subsystem	Off by default?	What it adds
Workers	off	Background job execution out of the API process
Orchestrator (OpenFang)	off	Multi-agent workflows, visual workflow editor
Voice	off	STT/TTS (Deepgram, ElevenLabs, Google, Azure)
Policies	off	Rego-based allow/deny on every tool call
CIAB	off	Coding-agent sandbox (local process or EC2)
Channels — WhatsApp	off	Baileys gateway auto-spawned on first use
Channels — Slack	off	Socket Mode listener

Toggling each is one env var or one setting in the UI. See Environment Variables.

Security posture

• Auth — Local (email+password, bcrypt+HS256) or OIDC (Auth0, Supabase, Keycloak, any JWKS-publishing issuer). See Local Auth and OIDC.
• Tenancy — every org has its own config, connectors, graph realm, channel credentials, memory, and policies. Cross-org reads are architecturally impossible (queries always filter by org_id).
• Approvals — any connector tool can require human approval before it runs. Defaults are conservative (read = allow, write = approve).
• Policies — optional Rego layer. Deny rules run for every REST call and every tool invocation. Every decision is audited.

See Zero-Trust Policies and Audit Log.

Next steps

• New here? Jump to Quickstart and get something running in 5 minutes.
• Building against the API? Start with the REST API reference and Chat API guide.
• Hosting it yourself? Pick a Docker Compose, Desktop, or Railway install.