Call Center & Human Handoff

The call centre is the part of InfraVoice where live calls reach people. An AI agent answers, and when the conversation needs a human — a refund, an escalation, a signature — the call is handed to a real person without the caller being hung up on or asked to dial again.

Three things make that work: projects (the routing unit — numbers, AI agents, humans, ring/queue/wrap-up rules), human agents (your people, who ring only while the agent portal holds a live socket), and the handoff (ring → accept → connect audio → leave).

Base URL: https://your-infravoice-host/api/v1 Auth header: Authorization: Bearer usf-… (your organization key, from Account → Organization key) Workspace: nearly every call takes ?workspace_id=…. Your org key defaults to your primary workspace, but pass it explicitly — it is what scopes and isolates every read. Telephony: the call centre places real calls on your own Twilio account. Configure it once in Setup before anything else will work.

Endpoints

Everything on this page, in one place. Two services answer here and they do not answer in the same format — one response parser for the whole page will break.

Everything on this page takes your usf- organization key. Configuration, assignments, live monitoring and history are all yours to drive from your own backend. Ringing and audio between a caller and a human agent are handled by the Agent Portal itself — you set up who can be rung and read what happened, and the platform runs the call.

Settings and projects

Human agents

Live call flow

Queues and monitoring

Calls, history and audit

Health probes live at /api/v1/call-center/health and /api/v1/call-bridge/health (plus /healthz, /ready, /live on each), unauthenticated, returning {"status":…,"service":…}.

Setup

A working call centre is five ordered steps. Do them in this order — a project without Twilio settings cannot dial, and an agent without a project assignment will never ring.

1. Connect Twilio

Twilio credentials are configured once per workspace, not per agent.

curl -X PUT "https://your-infravoice-host/api/v1/call-center/settings?workspace_id=WS_ID" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "twilio_account_sid": "ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "twilio_auth_token": "your-auth-token",
    "twilio_api_key": "SKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "twilio_api_secret": "your-api-secret",
    "twilio_twiml_app_sid": "APxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "default_caller_id": "+15551234567",
    "webhook_base_url": "https://your-infravoice-host"
  }'

PUT /settings has a stricter role gate than anything else here. Owner or admin only; a manager who can create projects and agents still cannot write Twilio credentials. New credentials take effect on the next call — nothing needs restarting. Invalid Twilio identifiers or a malformed caller ID are rejected with 400 INVALID_INPUT.

Writable fields — all optional; send only what you're changing.

Secrets are never echoed back. GET /settings returns boolean presence flags instead — which is how a settings UI shows "configured" without ever holding the secret:

{
  "success": true,
  "data": {
    "twilio_account_sid": "ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "twilio_api_key": "SKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "has_auth_token": true,
    "has_api_secret": true,
    "twilio_twiml_app_sid": "APxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "default_caller_id": "+15551234567",
    "webhook_base_url": "https://your-infravoice-host",
    "auto_record": true,
    "allow_transfer_to_human": true
  },
  "error": null,
  "timestamp": "2026-07-26T10:00:00Z"
}

If the workspace has never been configured, GET returns {"workspace_id":"…","message":"no settings configured"} inside data rather than a 404 — check for the Twilio fields, not for an error.

2. Point your TwiML App at the dialer webhook

In the Twilio console, open the TwiML App whose SID you just saved and set its Voice URL to:

https://your-infravoice-host/api/v1/call-bridge/twiml/voice     (HTTP POST)

This is a URL you configure, never one you call. Get it wrong — most often by dropping the /api/v1/call-bridge prefix — and Twilio receives an HTML 404, the agent's browser leg dies after about a second, and you see Twilio error 16011.

Every other Twilio callback (inbound, connect, call-status, agent-leg-status, conference-status, recording-status) is generated and registered by the platform on the calls it creates. You neither configure nor call those.

3. Create a project

The project's phone_numbers are what tie inbound PSTN traffic to this routing configuration.

curl -X POST "https://your-infravoice-host/api/v1/call-center/projects" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "WS_ID",
    "name": "Support",
    "slug": "support",
    "phone_numbers": ["+15551234567"],
    "ring_timeout_seconds": 25,
    "max_queue_size": 20,
    "max_wait_seconds": 300,
    "wrap_up_seconds": 15,
    "monitor_calls_per_lead": 8,
    "transcription_enabled": true,
    "fallback_ai_agent_id": "AI_AGENT_ID"
  }'

4. Attach the AI agent and the humans

PROJECT_ID=...   # data.id from step 3
 
curl -X POST "https://your-infravoice-host/api/v1/call-center/projects/$PROJECT_ID/ai-agents" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ai_agent_id":"AI_AGENT_ID","description":"First-line answer bot"}'
 
curl -X POST "https://your-infravoice-host/api/v1/call-center/agents" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "WS_ID",
    "display_name": "Maria Gomez",
    "agent_code": "maria",
    "email": "maria@example.com",
    "max_concurrent_calls": 1,
    "skills": ["billing"],
    "languages": ["en", "es"],
    "priority": 10,
    "role": "member"
  }'
 
curl -X POST "https://your-infravoice-host/api/v1/call-center/projects/$PROJECT_ID/human-agents" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"human_agent_id":"HUMAN_AGENT_ID","priority":10}'

5. Have the agent log in

Maria opens the agent portal and signs in. The portal opens the live socket described in Presence and ringing and sets her status to available. Only then is she reachable — an agent row in the database with no live socket does not ring.

curl "https://your-infravoice-host/api/v1/call-center/agents/online?workspace_id=WS_ID" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY"

{ "success": true, "data": { "online": { "HUMAN_AGENT_ID": true } }, "error": null }

Projects

A project is the routing unit. Everything the router needs to handle a call — which numbers, which AI, which humans, how long to ring, what to do when nobody answers — hangs off one project row.

Project fields

GET /projects/{id} returns the same shape inside the envelope:

{
  "success": true,
  "data": {
    "id": "9c1b…",
    "workspace_id": "WS_ID",
    "name": "Support",
    "slug": "support",
    "phone_numbers": ["+15551234567"],
    "ring_timeout_seconds": 25,
    "max_queue_size": 20,
    "max_wait_seconds": 300,
    "wrap_up_seconds": 15,
    "monitor_calls_per_lead": 8,
    "transcription_enabled": true,
    "fallback_ai_agent_id": "AI_AGENT_ID",
    "status": "active"
  },
  "error": null,
  "meta": null,
  "timestamp": "2026-07-26T10:00:00Z"
}

Assignments

Assignment is what turns a project from configuration into a working team. priority orders candidates within the project. One exception overrides it: an agent whose role is lead is ranked last resort no matter how high their priority — leads exist to catch escalations, not to absorb the front line.

GET /projects/{id}/human-agents returns the assignment joined with the agent, which is what a staffing screen needs:

{
  "success": true,
  "data": [
    {
      "id": "asg_…",
      "project_id": "9c1b…",
      "human_agent_id": "HUMAN_AGENT_ID",
      "priority": 10,
      "is_active": true,
      "display_name": "Maria Gomez",
      "agent_code": "maria",
      "agent_status": "available",
      "role": "member",
      "max_concurrent_calls": 1
    }
  ],
  "error": null,
  "meta": { "total": 1 },
  "timestamp": "2026-07-26T10:00:00Z"
}

GET /projects/{id}/available-agents returns the same shape narrowed to agents currently eligible — the same candidate list the router builds, before it applies wrap-up and concurrency filtering. It is the fastest way to answer "why did nobody ring?".

Legacy queue records

The /call-center/queues/* endpoints are the older V1 configuration model. Queue fields mirror the project ones: name, description, routing_strategy, max_wait_time_sec, max_queue_size, ring_timeout_sec, wrap_up_time_sec, priority, required_skills[], is_active.

Build on projects, not queues. Queues are kept for existing configurations. Projects are the current routing unit and are what the router actually reads. If you are starting today, create projects and ignore these endpoints. (Live queue depth is a different thing entirely — see Live controls.)

Human agents

A human agent is a person who can take calls: a record, a role, a set of skills, and a concurrency limit.

role is not cosmetic. A lead gets the Live Monitor in the agent portal and is ranked last-resort in routing — escalate-only tiering. Give it to the people you want catching what the front line couldn't, and to nobody else. Skills and languages, by contrast, order candidates; they do not create hard filters on their own, so keep the vocabulary small.

PUT /agents/{id} takes the same fields, all optional, plus status and is_active. Setting is_active: false is the clean way to take someone out of rotation — a deactivated agent never rings, on any project, without you having to unpick their assignments.

curl -X PUT "https://your-infravoice-host/api/v1/call-center/agents/$AGENT_ID" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_active": false}'

Presence and ringing

This is the single most common support question. There are two different notions of "available", and they are not the same thing.

1. The stored status column — what PUT /agents/{id}/status writes and what a roster screen displays. It is sticky: it survives a browser crash and will happily say available for someone who closed their laptop an hour ago. It is deliberately not admin-gated, so agents can set their own status.
2. Live presence — maintained by the agent portal's WebSocket. The server pings every 25 seconds and refreshes presence on the protocol-level pong, so presence survives a browser throttling its timers in a background tab. This is what routing actually reads, and what GET /agents/online reports.

Prefer GET /agents/online for any online/offline indicator; use the stored status for the agent's own intent (Available / Break).

An agent receives a ring offer only when all of the following hold:

On top of those four, the router applies two live filters: an agent already at max_concurrent_calls is skipped, and an agent inside their project's wrap_up_seconds window is skipped until it expires.

The practical debugging order when someone "isn't ringing": check GET /agents/online first (is the socket up?), then GET /projects/{id}/available-agents (is the router willing to consider them?), then their status and role.

Reporting

GET /agents/stats and GET /agents/attendance both accept ?from= and ?to= as RFC3339 timestamps or plain YYYY-MM-DD dates, default to the last 30 days, and treat to as inclusive of that whole day.

curl "https://your-infravoice-host/api/v1/call-center/agents/stats?workspace_id=WS_ID&from=2026-07-01&to=2026-07-26" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY"

Both are computed live — stats from the call segments themselves, attendance from the session event log — so they always agree with call history rather than drifting from it.

The AI-to-human handoff

Four steps in a fixed order, and the ordering is not incidental: the caller must be anchored into the conference before the agent's leg is dialled, so the agent never lands in an empty room and the caller never hears silence. The first two steps are performed by the platform — you configure who is eligible; the AI and the Agent Portal do the ringing and accepting. The audio steps are yours to drive if you are building your own experience.

AI decides to escalate
        │
        ▼
the platform rings the project's candidates
        │
        ▼
one agent accepts in the portal; the ring cancels everywhere else
        │
        ▼
POST /call-bridge/calls/{id}/add-agent-leg    audio actually connects
        │
        ▼
POST /call-bridge/calls/{id}/leave  end the call, or hand back to the AI

1. Ring

The AI triggers this itself when its transfer condition is met — you configure that on the agent (see the Agents API) and assign human agents to the project. A supervisor can also start it from the Live Monitor's Assign and Take buttons, which ring exactly one chosen person instead of the whole pool.

Direction is inferred from who is handing over to whom: ai_to_human, human_to_ai or human_to_human. The call record is created if it doesn't exist yet, so the handover and its audit event always have something to hang off. Watch it happen with GET /call-center/monitor/live and read the result afterwards from the call's handovers and segments.

2. Accept

The agent accepts in the portal. Exactly one agent wins the claim; the ring is cancelled on every other agent's socket, the winner is marked busy, the ring timeout is disarmed, and an agent_answered event is recorded on the call.

Accepting does not connect audio. It reserves the call. The next step is what the caller actually hears.

3. Connect audio

POST /api/v1/call-bridge/calls/{call_id}/add-agent-leg — raw JSON, no envelope.

curl -X POST "https://your-infravoice-host/api/v1/call-bridge/calls/$CALL_ID/add-agent-leg" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"agent_id":"HUMAN_AGENT_ID","agent_identity":"agent_HUMAN_AGENT_ID","workspace_id":"WS_ID"}'

{ "call_id": "…", "status": "agent_added", "conference": "conf_…" }

What this does, in order: anchors the caller into the conference (ending the AI media stream), claims the call so only one human leg can exist, dials the agent's browser into the conference, and opens the human segment — which is what makes the stint show up in call history and lets the recording attach to it. A provably dead incumbent leg is taken over rather than blocking the call forever, so a crashed browser doesn't strand the caller.

4. Leave

POST /api/v1/call-bridge/calls/{call_id}/leave is how a human finishes. It has two very different behaviours and the default surprises people.

return_to_ai defaults to true. An "End call" button that POSTs to /leave with an empty body will bounce your caller back to the AI and create a surprise extra AI segment on the call. If you mean end, send {"return_to_ai": false} explicitly. Every time.

curl -X POST "https://your-infravoice-host/api/v1/call-bridge/calls/$CALL_ID/leave" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"return_to_ai": false, "workspace_id": "WS_ID"}'

Response status is one of agent_left, agent_left_caller_returned_to_ai, call_ended or no_active_leg. Either path releases the agent's busy state and starts their wrap-up window, and clears the single-leg claim so a later transfer round can ring again. It also marks the exit as intentional, which is what stops the platform's crash-rescue logic from redirecting a caller who was deliberately hung up on. Hand-back is possible at all because the agent's conference leg is created with end_conference_on_exit=false — the human can walk away without dropping the caller.

Changing the AI agent's own configuration is a draft until you publish it. If your escalation work involves editing the AI agent — its prompt, its transfer behaviour, its providers or tools — saving only updates a draft version. Live calls keep using the last published version until you call POST /api/v1/agents/{id}/versions/publish. Call-centre changes on this page (projects, agents, assignments, settings) are different: they take effect immediately, with no publish step.

Bookkeeping handovers

POST /api/v1/call-center/handovers records that a transfer happened. Body: {call_id, direction, from_segment_id, to_human_agent_id, to_ai_agent_id, reason, context_snapshot{}}.

This endpoint moves no audio. It does not ring anyone and does not touch the live call — it only records that a handover happened, for your own audit trail. Moving a live call is done by the AI's transfer condition or by a supervisor in the Live Monitor. The call_id must already exist, or the create fails on a foreign key.

There is also an older single-shot orchestration path, POST /api/v1/call-bridge/handover, which snapshots conversation context, creates the handover record and rings the target in one request: {call_id, direction, to_human_agent_id, to_ai_agent_id, reason, conversation_id} → {handover_id, call_id, direction, status, context_messages}. Supply conversation_id and it pulls the transcript so far into the handover's context snapshot. New integrations should prefer transfer + add-agent-leg, which give you control over each step.

Live controls

Hold, mute, transcription and the supervisor views — everything you touch while a call is still up. The call-bridge endpoints here return raw JSON.

Mute is how a "silent AI" works. Muting the ai participant leaves the AI connected — it keeps listening and transcribing while the human talks, and can be un-muted the moment the human hands back. Removing it instead would lose the thread.

A 200 on hold/resume does not prove the hold applied. If the conference or the participant isn't known yet — typically because the leg hasn't finished joining — you get 200 with "status": "deferred". Treat deferred as "not yet", not as success. A 404 means this replica doesn't know the call.

Use /end for a call the agent originated. For a transferred call, prefer /leave with return_to_ai:false — it goes through the release and wrap-up path properly. Both mark the exit as intentional, so neither trips the crash-rescue logic described above.

Abandoned transfers are reclaimed automatically. Registering a transfer creates bridge state that normally lives until the call ends — but if nobody ever accepts (the caller hangs up while it rings, or no agent takes it), none of the events that would clean it up ever fire. A background sweeper reclaims those after about 15 minutes, and any bridge at all after 6 hours. It confirms with Twilio that the leg is really gone first, so a genuinely long call is never affected. The practical consequence for an integration: call_id for an abandoned transfer stops resolving once it is reclaimed, and the call-bridge routes above start returning 404. Treat that as "this call is over", not as an error to retry.

Supervisor views

GET /dashboard returns total_agents, available_agents, busy_agents, away_agents, active_calls, queued_calls, completed_today, avg_talk_time_ms, avg_wait_time_ms, total_handovers and abandoned_today. available_agents is derived from live presence rather than the stored status column, so it reflects reality. A background sweeper closes calls stuck in an active state for more than 30 minutes, so active_calls doesn't inflate forever after a crashed leg.

GET /monitor/live powers the team-leader view — one row per in-progress call:

{
  "success": true,
  "data": [
    {
      "call_id": "…",
      "conversation_id": "…",
      "direction": "inbound",
      "status": "in_progress",
      "caller_number": "+1555…",
      "caller_name": "Ana Ruiz",
      "current_handler_type": "ai",
      "current_ai_agent_id": "…",
      "current_human_agent_id": null,
      "initiated_at": "2026-07-26T10:02:11Z",
      "checklist": { "done": 2, "total": 5, "summary": "Verified identity…", "updated_at": "…", "items": [] }
    }
  ],
  "error": null
}

checklist is omitted entirely until the analysis worker has produced something for that call, so treat it as optional. Poll this alongside GET /call-center/agents/online and you have the full supervisor picture: what's in flight and who's actually there.

Assign and Take — pulling a live call to a chosen person — is done from the Live Monitor in the dashboard, or by a team leader in the Agent Portal. It rings exactly one person instead of the pool.

The browser softphone

POST /api/v1/call-bridge/token with {identity, workspace_id} mints a one-hour Twilio Voice grant so an agent's browser can hold call legs, and POST /api/v1/call-bridge/calls/outbound with {workspace_id, human_agent_id, to_number, from_number, recording_enabled, transcription_enabled} dials out from it.

Both act on your Twilio account and bill you. Request them only from your own backend or the agent portal — never expose them to untrusted callers, and never mint a token for an identity you haven't authenticated yourself.

Calls and history

GET /calls accepts ?status, ?direction, ?from, ?to, ?search, ?limit, ?offset, and returns meta.total for paging.

curl "https://your-infravoice-host/api/v1/call-center/calls?workspace_id=WS_ID&status=completed&direction=inbound&from=2026-07-01&limit=25" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY"

Reading one call

Use GET /calls/{id}/detail. One request gets you the call, every segment, every handover, the agents' notes and the recordings — exactly what a review screen renders, and it saves five round trips:

{
  "success": true,
  "data": {
    "call": { "id": "…", "direction": "inbound", "status": "completed", "caller_number": "+1555…" },
    "segments": [ { "handler_type": "ai" }, { "handler_type": "human", "human_agent_id": "…" } ],
    "handovers": [ { "direction": "ai_to_human", "reason": "billing dispute" } ],
    "notes": [],
    "recordings": [ { "storage_type": "s3", "url": "https://…" } ]
  },
  "error": null
}

A transferred call is several segments of one call, not several calls: AI, then human, then possibly AI again. If all you hold is a conversation id from one of those legs, GET /calls/by-conversation/{conversationID}/segments gives you the whole chain from any link in it. It returns an empty list, not a 404, when that conversation was never part of a multi-segment call.

Two timing facts worth knowing before you build a UI on this:

• /transcripts is written after the call, once, by the post-call analysis worker. An empty list right after hang-up is normal, not a bug — poll or fetch it later.
• Recording URLs are re-signed on read, so playback keeps working long after the original signed URL would have expired.

Playing a recording

Check storage_type on each recording. Archived recordings play straight from their signed URL. But when storage_type is twilio, the media URL needs Twilio account credentials and will not play in an <audio> tag — the browser gets an auth prompt instead. Fetch it through GET /api/v1/call-bridge/calls/{call_id}/recording-audio?rsid=RE… and hand the player a blob.

The rsid must be the recording SID (RE followed by 32 alphanumerics) and is strictly validated — a malformed one is a 400. The upstream media URL is built from the call's own account plus that SID, never from anything else you send. Responses are Cache-Control: private, max-age=600.

Wrap-up and audit

After a call, an agent stamps an outcome. That's PUT /calls/{id} with a disposition_code_id and disposition_notes:

curl -X PUT "https://your-infravoice-host/api/v1/call-center/calls/$CALL_ID" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"disposition_code_id":"DISP_ID","disposition_notes":"Refund issued, ticket #4471","customer_satisfaction":5}'

The same endpoint also accepts status, current_handler_type, current_human_agent_id, current_ai_agent_id, provider_call_sid, conference_sid and linked_conversation_id — all optional. Disposition codes themselves are workspace configuration under /call-center/dispositions.

Send "disposition_code_id": "" to clear a stamped code. That matters for deletes: DELETE /call-center/dispositions/{id} returns 409 IN_USE while any call still references the code, so clear it from those calls first.

POST /call-center/call-events appends to the same timeline the platform writes to:

curl -X POST "https://your-infravoice-host/api/v1/call-center/call-events" \
  -H "Authorization: Bearer usf-YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "call_id": "'"$CALL_ID"'",
    "workspace_id": "WS_ID",
    "project_id": "'"$PROJECT_ID"'",
    "event_type": "notes_added",
    "human_agent_id": "HUMAN_AGENT_ID",
    "details": {"ticket_id": "4471"}
  }'

call_id and event_type are required; omitting either is a 400.

event_type is a closed vocabulary, not a free-text label. It is constrained at the database level, so an unlisted value returns 400 INVALID_EVENT_TYPE and writes nothing. Put your own system's identifiers in details — that field is free-form JSON and is what a CRM ticket id, order number or external event name belongs in.

The accepted values are:

call_initiated · call_queued · call_dequeued · queue_position_changed · queue_max_wait_expired · agent_ringing · agent_answered · agent_rejected · agent_timeout · agent_busy · agent_disconnected · ring_timeout_expired · call_connected · call_ended · caller_disconnected · hold_started · hold_ended · tts_hold_played · mute_toggled · transfer_initiated · transfer_completed · transfer_failed · recording_started · recording_stopped · voicemail_started · voicemail_saved · wrap_up_started · wrap_up_ended · notes_added · disposition_set

The timeline is append-only — events cannot be edited or removed, which is the point of an audit trail.

Errors

The envelope service (/call-center) returns {"success":false,"error":{"code":"…","message":"…"}}. Call-bridge returns {"detail":"…"}. Handle both if you touch both.

Three non-obvious successes are worth repeating, because each one has caused a production bug:

• accept returns 200 with "status":"already_taken" when another agent won. It is not an HTTP error. Branch on the body.
• hold / resume return 200 with "status":"deferred" when the participant isn't known yet. Not an error, not a success either.
• leave defaults to return_to_ai: true. Sending an empty body from an "End call" button hands your caller back to the AI.

Two more shapes that look like errors but aren't: GET /agents/me returns data: null, not a 404, when the caller has no agent profile (and it only means anything with a user login — with an org key the subject is the organization owner), and GET /settings on an unconfigured workspace returns a message inside data rather than a 404.

Finally: workspace scoping is enforced per resource. Every by-id read resolves the resource's workspace and rejects cross-tenant access. Passing workspace_id explicitly on list endpoints is the habit to build — the default only ever resolves to your primary workspace.

Ready to build? Start with settings and one project, put a single agent in it, and watch GET /projects/{id}/available-agents flip to non-empty when they log in. Everything else on this page is a variation on that loop.