Self-hosted · runs on your own Ubuntu server
AI agents for the phone, on your own server.
Sidekick Agents is a self-hosted platform for designing voice and chat agents as flows. They answer calls through your own PBX, use the models and speech services you choose, and hand a live call to a person when it matters.
- Runs in Docker on Ubuntu
- Works with any SIP PBX
- Local or cloud models and speech
Build
Draw the agent as a flow.
A flow is made of steps. Some are run by a model, some say fixed words, and some follow rules that need no model at all. You decide which is which.
Two kinds of way out
A stage ends on a rule, evaluated without a model, or on a description that a model judges.
Versions that never change
A draft is validated before it is published. A published version stays as it is, and you can roll back to an earlier one.
Every step on the record
Each conversation is recorded step by step and can be replayed. It survives the process that was running it.
Telephony
Answer the phone through your own PBX.
The platform brings its own SIP gateway and joins the phone system you already run. Your numbers stay with your PBX.
It speaks
Heard and spoken
A voice worker hears the caller, takes turns, lets the caller interrupt, and reports exactly what the caller heard. Speech recognition and voices that run locally ship with the platform.
Measured on a development machine, with the local speech that ships with the platform: a caller hears the answer about three seconds after they stop speaking, on a laptop’s CPU. That is one measurement, not a benchmark.
People
Hand a call to a person. The AI leaves, or stays.
A flow’s Handover step rings a person or a team. What the agent does next is your choice.
And back again
The person can hand the call back to the agent.
No dead ends
Nobody answering, a busy line and a declined call each continue the flow.
Models and speech
Any model, any speech service. Local ones too.
Connect the language models and speech services you already use. Or run both on your own hardware, so that nothing leaves your network.
Tools and knowledge
Things to do, and things to know.
An agent is only as useful as what it can reach. Give it tools to act with and documents to look things up in.
Knowledge bases
Documents an agent looks things up in before it answers a question of fact: pasted text, Markdown, a web page fetched for you, or a PDF or Word file. What a document says reaches a model as something found, never as instructions.
Approval before a tool runs
A tool can wait for a person to approve it. The flow carries on when they have decided.
Requests that stay outside
Requests an agent makes cannot be pointed at private addresses, and a stored key is only ever sent to the host it was entered for.
Agent to agent
Other agents can talk to yours, through a gate you keep.
One MCP endpoint, where each agent you offer appears as a tool. Clients come in with a gateway key or by signing in, and each is held to what its record allows. The same agents answer over the Agent2Agent protocol.
- Which agents it may talk to
- How fast it may ask
- How many conversations it may have open
- How many tokens it may use in a day
Every request is on a record that cannot be altered.
Self-hosted
It runs on your server. So does your data.
Everything runs in Docker on one Ubuntu server that you control. There is no hosted service to send your calls to.
Workspaces kept apart by the database
Row-level security on every workspace table. The application’s database role cannot see across workspaces.
Credentials encrypted and bound
Stored credentials are encrypted with AES-256-GCM and bound to the hosts they may be sent to.
Only the author gives instructions
What a caller, another agent, a tool or a document says never reaches a model as instructions. Only what the flow’s author wrote does.
One guard on outbound requests
No private addresses unless a platform administrator allows them. The resolved address is the one connected to, and redirects are checked again.
Nothing dialled of its own accord
The platform rings only destinations a workspace set up by name, under per-trunk rules on where and how often.
Services that prove who they are
Services identify themselves to each other with short-lived tokens, with one signing key for each pair.
Start with a workspace of your own.
Create an account, connect a model, and make your first agent from a template.