Agent Server on Ulai Docs

Overview

Mon, 01 Jan 0001 00:00:00 +0000

What it is

The Ulai Agent Server is a single Go binary (orchestrator) that runs one side of a voice conversation. It joins an Ulai SFU room as an ordinary participant, connects an AI backend to that room, and manages the conversation until somebody ends it.

Everything it owns is timing-critical:

The audio chain — pre-clean, denoise, near-field foreground isolation, neural VAD.
Turn detection — who has the floor, and when that changes.
Barge-in — cutting the agent mid-sentence when the caller speaks, and accounting for how much of the turn was actually heard.
The silence ladder — nudges when a caller goes quiet, and a hangup when they stay quiet.
The end-call contract — the evidence a model must produce before it is allowed to hang up on a human.

What it is not

It is not a place where anything is stored. There is no database, no agent table, no recording bucket and no credential file. A call’s configuration arrives in the request that starts it, and everything worth keeping leaves on the event stream for somebody else to write down.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Configuration is split by a single rule:

If it decides how a call runs, it travels with the call. If it decides how the process runs, it is an environment variable.

That split is why the environment list below is so short, and why the same binary can serve agents belonging to different customers at the same time. The per-call half is documented under the agent profile.

The process prints its whole configuration at boot, including which variables are set but not read — usually a rename:

Interfaces

Mon, 01 Jan 0001 00:00:00 +0000

The image exposes two ports and nothing else. There is no web UI, no admin endpoint and no configuration API — the agent server is driven entirely by the agent client.

Port	Protocol	Who connects	Expose it?
`50052`	gRPC	the agent client	Loopback or private network only
`8000`	HTTP	your monitoring	As needed

Port 8000 — health

One endpoint:

curl -s http://localhost:8000/health # → ok

A liveness check, not a readiness one. It returns ok as soon as the process is up, including when no calls are running — which is the normal state. It does not tell you whether calls succeed; the log does that.