Overview

AiFlow is a self-hosted, single-tenant AI workforce platform built on an ownership-first philosophy, for building voice, video, and text AI agents. A single deployment can host many independently configured Agents, each with its own persona, voice, knowledge base, tools, and phone number. AiFlow also includes an Orchestrator layer, which lets an Agent hand off a task to a separate, non-realtime component running its own choice of model (Gemini, Anthropic, OpenAI, and over 100 others) for multi-step or multi-model work that doesn't need to happen live on the call. See Orchestrators for the full picture.

This page covers the handful of ideas worth understanding before the rest of this site's guides make full sense.

How an Agent is reached

An Agent can be reached four ways:

• Embedded widget: a snippet dropped into a website opens a voice or text chat with the agent.
• Inbound phone call: a caller dials a phone number mapped to an agent.
• Event trigger: fires proactively when your system reports an event that matches a rule your admin team configured.
• Connected mailbox: the agent watches a real inbox for new mail and decides how to respond.

Each of these channels is covered in its own guide. See Agents & channels for how they relate to the agent_id or slug you'll see in almost every endpoint path.

Design principles that shape how you integrate

Two decisions behind AiFlow are worth knowing up front, since they directly affect how you write an integration against it.

Self-hosted, single-tenant

Each AiFlow deployment belongs to one client and runs on that client's own infrastructure with its own database. There's no shared, multi-tenant AiFlow API to sign up for, which is why every example on this site uses the placeholder https://api.your-domain.com instead of a real host: your organization's deployment lives at a URL your own team controls. See Authentication for what that means for your base URL and credentials.

Every capability is additive and opt-in

A feature you don't use, a tool that isn't enabled, a trigger that isn't configured: none of it touches your integration. Adding a new capability never changes an agent's default behavior, because each one arrives as a config flag, an enabled tool, or a newly created rule, and each of those defaults to off or absent. You can build against just the parts of the API you actually need, without worrying that some unrelated feature elsewhere in the deployment will change how your calls behave.

Next

• Agents & channels: what an Agent is, and why its id shows up everywhere.
• Triggers & events: how a posted event turns into a call, a message, or nothing at all.
• Orchestrators: multi-model, multi-agent task delegation, and what it means for the Agent you're integrating with.