Actus

Spatial execution runtime for agents and system actions at scale

Author
Affiliation

SSCCS Initiative

Actus is a spatio-temporal runtime that executes acts, directly and through agents. The name joins act and us: the runtime exists to carry acts. An act is any unit of execution, from reading context, editing files, running commands, resolving symbols, and fetching resources, to driving an agent through a task. An agentic process is one kind of act, the first implemented kind and not the only one: direct acts run inside the server, and control acts let one agent dispatch another through a policy-gated surface.

Actus is a thin server process with no graphical interface. It owns conversation state, working context, and the lifecycle of each agent process, while the agent keeps its own planning and its model. Clients reach one uniform headless service over HTTP with streaming, so they never touch an agent process or its protocol directly. Agents are external programs located by path and reached over a defined contract, never linked into the runtime. Long-lived conversational agents and one-shot command agents both attach behind the same adapter interface, and a new agent kind can be added without changing the server core.

Each agent is described by one configuration entry: its kind, its model endpoint, how it is launched, its approval policy, its working directory, and any additional tool servers it should expose. Without a configuration file, the runtime derives a default agent from command line flags and environment variables. When one agent dispatches another, an explicit policy list guards the request, so agents can compose without any single one holding unbounded authority.

Actus is part of the SSCCS stack. Under kineTics, the universal execution and transduction controller of the stack, actus is the hub for the agent executor type and is positioned to become its reference implementation. Actus is licensed under Apache-2.0 and never links or bundles agent code, so its published image stays independent of any agent implementation and its license.

Architecture

Figure 1: Actus: a server layer owns threads and context and bridges external clients to one or more external agent processes behind a uniform registry. A sessionful agent is the base instance; one-shot command agents attach per request.

The architecture follows a layered separation of concerns:

  • HTTP API Layer: Exposes actus over REST with streaming support for real-time delivery, guarded by bearer-token authentication. Clients interact through a uniform interface without managing the agent process directly.

  • Session State and Persistence: Manages conversation threads per agent across reconnections. Each thread keeps its message history on disk, so a sessionful agent resumes after connection drops or server restarts. Threads of one-shot agents record which session dispatched them, so a chain of dispatches stays traceable.

  • Agent Registry and Bridge: The channel between actus and agent processes. The sessionful adapter keeps a long-lived protocol connection and manages reconnection and the agent process lifecycle; the one-shot adapter starts the declared program per request with a launch probe, a per-agent working directory, and request-scoped cancellation. Each agent carries its own tool approval policy and any tool servers it should expose.

  • Direct Acts: Filesystem and git acts run inside the server: file search and mention, symbol search, project rule discovery, URL fetch behind an SSRF guard, and git status, diff, and log.

Design Principles

Stateless client, stateful server. Clients send individual messages without managing conversation history. The server tracks thread state, injects prior context, and presents a coherent narrative to the agent on each turn.

Headless by default. The agent runs without any graphical interface. This removes desktop environments, display servers, and browser runtimes, making the system deployable on servers, containers, edge nodes, and embedded devices.

Protocol isolation. The server owns the agent lifecycle and communication protocol. Clients interact only through HTTP, insulated from changes in the underlying agent protocol or implementation.

Thin runtime with process-separated agents. The runtime links no agent implementation. Agents are external processes located by path and reached over a contract, so the Apache-2.0 actus image never carries agent implementation code and an agent can be swapped without changing the server.

Acts over agents. The agent family is one kind of act. Direct acts run without any agent, and control acts let one agent drive another, so the runtime surface stays an act surface rather than an agent shell.

Status and Direction

Actus is Apache-2.0 licensed, pre-release, and in active development. The contract with the base system agent works end to end: the agent connects over WebSocket and serves threads, tools, and cancellation. Per-agent thread persistence, bearer-token authentication, per-agent tool approval, tool-server injection, auxiliary one-shot agents, and the meta-agent control surface are in place. Deterministic conformance runs without a language model in CI: a stub tier exercises the surface with a mock agent, and a pull-based real-agent tier runs the same suite against the prebuilt agent image once that image is published.

Packaging follows the thin runtime: a multi-stage Dockerfile builds a test image for CI and a slim runtime image for publishing. Published images are cut on version tags (a versioned image plus latest) or as manual dev snapshots, so ordinary development commits publish nothing.

Current direction:

  • kineTics alignment. Actus is the hub of the agent executor type under kineTics. As kineTics defines further executor types (signal, hardware, human-machine, bridge), the act kinds actus routes today extend toward them behind the same contract.
  • Auxiliary agents. The one-shot command agent family is implemented. Existing command line agents are the first candidates to attach in this mode.
  • Meta-agent control. A sessionful agent can dispatch auxiliary agents through a policy-gated control surface. Live verification of the surface waits on the headless agent data directory fix so that injected settings and tool servers reach the agent process.
  • Agent data directory. The headless agent entry point is being updated to honor its data directory argument, so actus-injected settings and tool servers reach the process; live verification follows.

Actus is a project of the SSCCS Initiative. Inquiries: actus@ssccs.org.