Open-source support is two products, a desk and an agent

The desk holds the thread, the agent holds the rules

Support software answers two questions. One is where a message lands and who sees it next. The other is what happens when the answer is not in a help article: the lookup, the refund, the fix. Open source has products for both questions, and they are rarely the same project.

Chatwoot is a desk: an MIT-licensed, self-hosted customer support platform with one inbox for website chat, email, WhatsApp, Facebook, Instagram, Telegram and SMS, a built-in help center and reports (github.com/chatwoot/chatwoot). Its AI agent is Captain, and Captain is sold separately from the community code.

Sim is a workspace under Apache 2.0, where a team builds, deploys and monitors AI agents and workflows visually, with 270+ integrations and a choice of model (github.com/simstudioai/sim). A team assembles the support agent there from models, tools and integrations.

TGO is the platform case: an open-source AI agent customer service platform with multi-agent orchestration, a RAG knowledge base, website and WeChat channels, human handoff and an agent workspace (github.com/tgoai/tgo). Kortix is the fourth shape, the agent layer that works beside a desk a team already runs, and it is the recommendation for that layer.

What the MIT license covers

Chatwoot is the reason the question gets asked. The desk installs on a server the team already pays for. It holds website chat, email, WhatsApp, social messages and a help center in one queue, and adds reports on top. For many support teams that is most of the software they need, and the bill is a server plus the maintenance.

The license stops where the AI starts. Chatwoot's AI agent, Captain, is not in the Community Edition: it needs a Premium or Enterprise self-hosted license, and Chatwoot bills nothing for Captain credits on self-hosted because you bring your own OpenAI key and OpenAI bills you for usage (Chatwoot user guide).

That is a fair trade for a desk that answers from help articles. The trade reads differently when the agent is the part that reads the billing account and the repository. The paid tier then covers the work the purchase was for. Chatwoot Cloud bills the AI inside the plan: every paid plan carries a monthly Captain credit allowance (300 Startups, 500 Business, 800 Enterprise) and extra credits cost $20 per 1,000 (chatwoot.com/pricing).

Sim splits at a similar seam. Sim's self-hosted install is the platform, and Sim's own chat surface is a Sim-managed service, with the setup wizard connecting a Chat API key for it. A team that self-hosts the workspace still sends its customers to a surface Sim operates.

TGO carries both layers in one repository, under a license with a condition: TGO's license is a modified Apache 2.0, one instance is for one company, so a multi-tenant deployment needs a commercial license from the producer, and the console logo and copyright stay in place (TGO license). Three brands behind one support install would need that license.

Each of these is a reasonable way to fund the work. The layer that touches the customer account is the one a support team should not have to buy a license for. For a support lead the question is narrower than which product costs less. Which layer holds the customer's account, and does it sit behind a license or on a surface the vendor runs?

The support address becomes a session

A support agent needs an inbox to read and a reason to start. In Kortix both are manifest entries. The inbox is a connector, and the reason is a trigger, which fires on a schedule, a webhook or an App event. For a support inbox the webhook is the useful one: the helpdesk posts a signed request to the trigger's own URL, and the project secret named in on.webhook.secret signs it (automations).

No person starts the work; the queue does. Each fire begins an agent turn in a fresh session, so every message gets one, with the subject and the sender filled into the prompt.

Kortix's own support inbox in Plain is connected to an agent running on Kortix. Every inbound thread spawns its own isolated session with scoped access to the systems a support issue can touch: the product's knowledge, the codebase, and Stripe. It investigates, resolves what it can, and stops at a human for sensitive actions (Kortix customer support use case).

The rule that holds a write

A trigger decides when the agent starts. A policy block decides what it may finish. Both live in the same file at the root of the project repository.

1policy:2  default_mode: risk3policies:4  - match: gmail.send_email5    action: require_approval6    conditions:7      - arg: to8        match: "*@example.com"9  - match: gmail.send_email10    action: block11approvals:12  ttl: 4h

Three keys do the work. policy sets the mode for a call that no rule matches. policies holds the rules themselves. approvals sets how long a held call waits. Approval gates you set. Off until you set them, so a project with no policy block runs every call its connectors allow.

A rule matches a tool path such as gmail.send_email with action: require_approval or action: block, and conditions limits it to calls whose arguments match. In that block, a send to any address at example.com waits for a person, and every other send on that tool is refused. approvals.ttl: 4h gives that person four hours to decide. Without the key, a held call waits 24 hours.

The rule sits in the repository, so a change to it shows up in a diff beside the agent prompt it governs. A reviewer can read it again a year later, and revert it.

Three teams, three starting points

A team already on Chatwoot keeps the desk and puts the agent layer beside it, connected to the same inbox. The check before that move is a license question: which Chatwoot tier includes Captain on a self-hosted install, and whose invoice carries the model usage.

A team starting from nothing chooses the desk on support features and the agent on reach. The hosted vendors against the open-source route are on the comparison of AI customer service agents. That is the shorter read while the desk is still open.

A regulated team or an on-prem team has the constraint already. Where the agent runs, which credentials it holds and how the network reaches it are covered in self-hosting an open-source support agent.

One check runs before any of those signatures. Take a ticket from last month that ended in a refund, and ask each vendor for the rule that would have held it. An answer in the form of a file in your own repository is the one to sign beside.