An Agent That Only Runs in Chat Is Not a Platform

A headless entry point accepts a request, identity, and execution context while allowing the websocket argument to be absent. It still compiles the manifest, filters tools, loads context, applies budgets, executes the graph, and records observability. Only transport-specific progress events disappear.

Adding this invocation to continuous integration exposes assumptions that ordinary chat tests miss. A user identifier may be assumed to represent a person. A progress callback may assume a socket exists. A memory read may assume an interactive viewer. Each failure identifies a policy or transport concern that has leaked into the runtime, which is why adding voice later so often becomes a rewrite.

Voice, scheduled jobs, CLI verification, and agent delegation should not bypass the access, tool, context, and budget gates used by chat. Reusing only the model prompt while rebuilding execution around each client produces inconsistent authority: the same agent is careful in the browser and reckless on a schedule.

The valuable abstraction is therefore a governed invocation contract whose clients differ in transport and interaction timing but not in how permissions and evidence are computed. A generic completion function does not provide that.

A prototype that is still testing whether anyone wants the workflow may reasonably begin inside one interface. Premature transport abstraction can slow learning. The trigger for a headless seam is the first non-chat caller, or the first runtime rule that must be duplicated.

The seam also has maintenance cost. Interactive and headless paths can drift if they initialize context differently or emit different completion records. A shared contract needs parity tests that invoke both modes with the same identity and compare admitted tools, loaded context, and final artifacts. Without those tests, headless-first is a folder name.

Choose a job currently completed through chat. Run it from a command-line client with no browser state, no socket, and an explicit service identity. Verify that the same policy gates run and that the result persists in the same form.

If the audit requires copying prompt assembly, tool binding, or memory logic into the CLI, the chat application still owns the product. The target state is simpler: clients submit work; the runtime admits and executes it; artifacts and evidence outlive the client.