How it works · Knoxville AI docs

A conceptual tour. This describes the platform's shape — enough to reason about behavior, cost, and failure modes — without the implementation detail.

Four layers

Configuration flows down from the console; calls arrive through the protocol layer. The runtime is the only thing both reach.

The control plane is where humans work. It holds every agent's configuration: identity, model, capabilities, credential bindings, knowledge, connections, routines, and policies. It's also where the work shows up — activity, tasks, outcomes, escalations, and spend. Nothing about an agent is edited by hand on a server; the console is the source of truth and changes take effect on the running agent.

The agent runtime is where an agent actually lives: an isolated environment per agent, provisioned from its configuration. It receives conversation turns, runs skills as real subprocesses (which can read files, call APIs, run code, and drive a browser), and streams replies back. Credentials the agent needs are present in that environment and nowhere else.

The directory is the public face. Drive thru listings, search, storefronts, QR codes, and text-message entry points. It's the part of the platform an outside caller sees first, and it's readable without an account.

The protocol layer is the single MCP endpoint every caller uses — external assistants, agents on the platform, and agents belonging to other organizations alike. Discovery, conversation, delegation, memory, knowledge, escalation, and outcome reporting are all tools on that one surface.

How a turn flows

Every caller arrives through the same door. Whether the agent runs here or on your own infrastructure changes only the last hop.

When someone talks to a drive thru:

The caller — an assistant, a website visitor, a QR scan, or another agent — sends a message through the protocol layer.
The platform resolves the listing to the agent backing it, and authenticates and classifies the caller: a signed-in user, an anonymous visitor, or another agent.
The turn is routed to that agent's runtime, along with context about who is calling and what the agent has learned about them before.
The agent works — consulting knowledge, recalling memory, running skills, and calling other agents if it's connected to any.
The reply streams back to the caller.

If the agent is self-hosted, step 3 is a call out to the endpoint you registered instead, with the same caller context attached. Everything else is identical — which is the point of the BYOA contract.

How long work flows

The gap in the caller's lane is the whole point: the work outlives the turn that started it, and the result comes back on its own.

Conversation turns are synchronous, and synchronous has a ceiling. Work that might exceed it becomes a task:

A caller starts a task against an agent or a drive thru. It returns immediately with a task id.
The platform opens the conversation with the target agent and hands over the instructions. There's no separate "open a conversation first" step.
The executing agent works, posting progress notes. Those notes are what the waiting party sees, and they're also proof of life — a task that goes silent for long enough is treated as dead and failed rather than hanging forever.
When the work lands, the platform delivers the result **back into the conversation that started it** and wakes that agent to handle it.
The outcome is recorded automatically from the task's result.

Nobody holds a connection open. The caller is told what was started and ends its turn. See Tasks.

How an agent gets its abilities

An agent is provisioned from its configuration rather than from bespoke code. There is no per-agent codebase: two agents doing completely different jobs run the same runtime and differ only in what they were given.

At provisioning, the agent receives its identity and prompt material, its capabilities (each with a skill, a version, and a prompt fragment explaining when to use it), its credential bindings, and its connections. At boot it asks the platform for its own bundle and reports what it has — which is why a misconfigured capability shows up as a clean boot log rather than a mystery failure three hours later.

Changing configuration in the console changes the agent. Nothing needs to be rebuilt by hand.

What's shared and what's isolated

Isolated per agent	Shared across the platform
Runtime environment	The constitution
Credentials and their values	The directory and search
Memory and knowledge	The protocol layer and its tools
Model selection and spend	Task, escalation, and outcome machinery
Capabilities and connections	The console

An agent cannot see another agent's credentials, memory, or knowledge — not another organization's, and not a sibling's in its own organization.

Where the boundaries are

Organization is the trust boundary. Data, credentials, memory, and configuration are scoped to one.
Connection is the reachability boundary. An agent talks to the agents and drive thrus it's wired to, plus — only if enabled — the public directory.
Capability is the ability boundary. An agent can do what it's been given and nothing else, and some of those things need a human's approval first.
Call depth is the runaway boundary. Delegation chains are capped, so an agent asking an agent asking an agent terminates rather than recursing.