PLXY AI Call Center

Less tool switching. More conversations that finish. PLXY is an enterprise AI call center that sits between the Cambodia Telco SIP trunk and the 3CX PBX agent pool: the bot speaks first, understands with ASR + LLM, fills the slots your business needs, and hands the caller to a human agent only when a human is worth the wait.

Everything an operations team touches lives in one studio — the scenario you design, the campaign that dials it, the call you watch live, and the report that tells you where callers drop off.

Why PLXY

• The conversation is a document, not code. A scenario is a versioned JSON document (schema v2) that the studio edits, the api validates, and the worker executes — the same contract, validated once and executed exactly as validated, so what you drew is what a caller hears.
• Versions are immutable. Saving creates a new version; publishing is a separate, explicit step; restoring appends a snapshot rather than rewriting history. A flow never changes without a reviewable trail.
• Production telephony without exotic parts. Stock FreeSWITCH 1.10, SIP/RTP in, SIP to 3CX out, warm transfer, recordings — the audio model runs on components your VoIP engineer already knows.
• Tenancy you cannot forget to enforce. PostgreSQL 18 row-level security scopes every row to its tenant at the database, beneath every line of application code.

The product, in one tour

1. Projects — the workspace: pick a project, and every list in the studio scopes to it.
2. Callbots — a phone-number-facing bot: DNIS routing, scenario schedules, the active scenario.
3. Scenario Studio (v2 canvas) — seventeen node types, retry lanes, sub-flows, global handlers, undo/redo, edit locks with a named holder, validation findings on the offending node.
4. Node & template libraries — reusable node templates, entities, intent guides, tags, transfer destinations, API definitions, LLM metadata, summary prompts.
5. Campaigns — contact lists with variable columns, schedules, pacing, and per-contact outcome.
6. Calls — every leg with its transcript, recording, tags, and the scenario version that ran it.
7. Live Monitoring — today's calls as they happen, per-call live view over WebSocket.
8. Reports — operation statistics, conversation analysis, node flow/drop-off, activity log.
9. Administration — tenants, users, managers, roles, audit trail, login history, AI settings.
10. Usage — what the AI providers cost you, per tenant and per day.
11. My Page — profile, password, and the session's own trail.

Core capabilities

Capability	What it means operationally
Schema-v2 scenario engine	17 node types incl. DIALOGUE slot-filling, LLM/LLM+ turns, BRANCH on variables, FORK/JOIN, sub-flow calls
Two transition lanes	next advances, retry re-prompts the same node — bounded by re-prompt and execution budgets
Edit locking	One editor at a time, named in the banner; admins can take over; saves without the lock are refused
Validation gate	The api refuses invalid versions; the studio pins each finding to the node it is about
Campaign engine	Outbound dialing with contact variables flowing into the scenario as
Warm transfer	The bot leg ends into a 3CX extension with context, not a cold drop
Compliance & recordings	Consent handling, per-call recordings, immutable audit events with an outbox
Provider SPI	ASR/LLM/TTS behind an interface — swap cloud for on-premise without touching scenarios

What you deploy

PLXY ships as two Docker stacks, so the telephony half can sit on a DMZ host of its own while the application half stays on your internal network. Everything is a container: there is no host JDK, Maven or Node to install anywhere.

Stack	Contains	Runs on
Callbot	The studio, the control plane, the scenario engine, PostgreSQL	Your internal host
Gateway	Call control and the telephony engine (SIP trunks, RTP, transfers)	A DMZ host, or the same one

They deploy to separate Docker Swarms and exactly three ports cross the boundary between them — joining the DMZ host to the internal cluster would mean opening Swarm's own control and data planes across it. Every credential is a Docker secret; nothing sensitive travels through the environment.

The Deployment Guide walks it end to end, from a clean host to a call that completes.

Access & permissions

Authorization is default-deny and runs on three axes, evaluated in order: function level (do the held roles permit this action?), tenant scope (row-level security at the database), and project scope (membership + whether the roles write at all). One vocabulary of three roles — held in any combination — says both what kinds of thing an account touches and which projects, and whether it may change anything. In practice:

You hold	You can	You cannot
STUDIO_MONITORING	Open scenarios, campaigns, calls, reports in your projects — read-only	Save, publish, take an edit lock
STUDIO_PROJECT	Design scenarios, take/hold edit locks, save versions, run campaigns — in your projects	Take over another editor's lock, see other projects
STUDIO_ADMIN	Everything above in every project, plus take over locks	Cross tenant boundaries — nobody can

The full model — each role's grants, the evaluation flow, and what each one sees in the studio — is in Roles & Access.

Getting started

Docker is the only requirement. The images are published and self-contained, so a host needs nothing else installed — no JDK, no Maven, no Node.

Begin at Start Initialzr: answer a short form about your hosts, your carrier and your 3CX, and it generates both environment files and the exact command sequence for each host. It runs in your browser and sends nothing anywhere.

# 1. On the host that will run the application stack
docker swarm init

# 2. Create this deployment's secrets, then bring the stack up
./deploy/swarm/secrets-init.sh callbot prod
./deploy/swarm/deploy.sh       callbot prod

# 3. On the telephony host (the same machine is fine for a pilot)
./deploy/swarm/secrets-init.sh gateway prod
./deploy/swarm/deploy.sh       gateway prod

Run the same commands with staging in place of prod to rehearse a release first — same images, same stack files, its own secrets.

Open the studio, sign in with the seeded administrator, and change its password immediately — the Deployment Guide covers first sign-in, the firewall rules between the two hosts, and connecting your carrier trunk and 3CX.

Every setting is an environment variable or a Docker secret; Configuration lists them by stack, and the carrier trunks themselves are configured in the studio rather than in a file, so adding a carrier needs no redeploy.

Where to go next

Section	What it answers
Start Initialzr	Generate your environment files and commands from a form
Deployment Guide	From a clean host to a call that completes
Configuration	Every environment variable, stack file and Docker secret
User Manual	How to use each screen of the studio
Scenario Studio	Designing conversations: nodes, lanes, slots, publishing
Roles & Access	Who can do what, and how a request is decided
API Reference	The REST surface for integrations
Q & A	The questions that come up in practice