Agent

Description

An agent is the runtime system that autonomously performs work using a workflow plus an available tool harness. In the current repo model, agents are not standalone definitions; they are instantiated from Agent Pool, which supplies scaffold and configuration.

The main dimensions that shape an agent are lifecycle, location, and capability. Agents are empowered by both the underlying model and the harness attached to them. Those properties make agents central to both swarm coordination and cost or quality optimization.

See Agent Architecture for the current runtime component diagram and mapping to harnesses, telemetry, and execution ledger concepts.

Lifecycle

Agents may be ephemeral or long running, can run locally or in the cloud.

Ephemeral

Ephemeral agents are spun up to accomplish a specific task and then cleanup. To this effect they are similar to a Kubernetes Job. Subagents spawned by a larger agent are considered to be ephemeral.Ephemeral agents are usually spun up based on external stimuli like a ticket being created with specific goals

Long Running

Long running agents(LRA) have significant differences over ephemeral. LRA are imbued with a higher degree of agency and abilities and lower level of access to their system. They likely live on a long running VM as they are responsible for storing and administrating their own system and lifecycles.

Long running agents usually use mechanisms like Dreaming whereby long term memory is readdressed by the agent and stored by itself.

LRA are primarily useful as AI assistants that are given open ended tasks and accumulate skills and tools over time.

Their execution model adds security challenges and difficulty in deterministic responses. When not in use, a full VM is an expensive memory overhead.

Location

Agents may run locally or in the cloud, and the choice is architectural rather than incidental (see Agent Architecture for the local-first vs cloud-first deployment modes). Local execution is a fast, cheap development and resilience tier; cloud execution is the system of record for production delivery because it produces durable, auditable, isolated runs (see Execution and Feedback). The runtime should treat shared state as optional and model every cross-agent dependency as an explicit edge in the Execution Ledger.

Capability

An agent’s capability is the product of three things: the underlying model (selected by Smart Routing), the harness that wraps it (and the quality of its Agent-Computer Interface), and the skills, tools, and context it is provisioned with. A large fraction of effective capability lives in the harness and interface, not the model alone so capability is something the system configures, not just something it selects a model for.

Scope and Horizon

The strongest operational lesson for agents is scope small. Long-horizon work is best delivered as many short, well-scoped sessions rather than one marathon run, because quality decays over long sessions and context rots as it grows. An agent should take a unit of work it can complete and verify within one healthy context window, checkpoint its progress to durable memory, and let a fresh session resume from there. This is why ephemeral, task-scoped agents are the default execution shape and long-running agents are reserved for open-ended assistant roles. See Runtime Context Management.

Agent Pool - The factory that instantiates agents from configuration.
Cohort - Defines relationships and communication pathways between agents.
Agent Architecture - Runtime components and deployment modes.
Orchestrator - Dispatches to and tracks agents.
Runtime Context Management - Why scope-small and short sessions matter.
Coordination Model - How multiple agents collaborate safely.