Glossary
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Definition
An agent runtime is the infrastructure that executes an AI agent's work: it loads the agent's identity and task context, runs the loop of model calls and tool calls, enforces time and iteration limits, handles failures, and records what happened. The runtime is distinct from the model that reasons, the framework used to write the agent, and the orchestrator that decides which agent runs.
- Responsibility
- Execution, limits, recording
- Not the same as
- Model, framework, orchestrator
- Polaris runtime
- polaris-runtime on Fly.io
The four layers people collapse into one
Conversations about agent architecture get confused because four separate things are all called the agent. The model provides reasoning and lives behind an API. The framework is the library you wrote the agent with. The orchestrator decides which agent handles what and in what order. The runtime is the process that actually executes a single job on real hardware with a real filesystem and real credentials.
The distinction is practical rather than pedantic. Almost every operational failure, whether a job that hung, a run that cost too much or a credential that leaked into a log, belongs to the runtime layer, and cannot be fixed by changing model or framework.
What a runtime is responsible for
Compiling identity and context
Assembling the agent's instructions, its skill files and the specific task's context into the input for the run, before the first model call.
Running the loop
Alternating model calls and tool calls until the agent finishes or a limit is reached, with a bounded number of rounds so a confused agent cannot loop forever.
Enforcing limits
Wall-clock timeouts, iteration caps, and the boundary of which tools and credentials this run may use.
Recording the run
Counting the observable effort, posting progress, attaching produced files, and writing the result back to durable storage. Nobody watched the run, so the record is the only account of it.
Commonly confused with
| Term | What it is | The difference |
|---|---|---|
| Model / LLM | The reasoning engine behind an API | Stateless per call. It cannot claim a job, write a file, or enforce a timeout. |
| Agent framework | A library for defining agents, tools and loops | Development-time. The runtime is what is running in production at three in the morning. |
| Orchestrator | The layer choosing which agent handles what | Decides assignment and sequence. The runtime executes one job to completion. |
| Cloud development environment | A remote environment for a human developer | Assumes a person is typing in it. A runtime assumes nobody is watching. |
How Polaris implements it
Polaris runs a worker service on Fly.io called polaris-runtime. It polls the agent_jobs queue, claims one job, compiles the worker's identity from its instructions and skill files plus the task context, then runs a tool loop with live web search and a bounded number of rounds under a wall-clock timeout. During the run it ticks acceptance-criteria items, posts progress comments, attaches generated files, and computes the human-equivalent hours for the work log.
Credentials for connected tools are stored server-side and used by the runtime. A browser never sees them, which is the security reason for putting execution on a machine rather than in the client.
Related terms
Task queue
The thing that lets a request survive the process that made it.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Agent orchestration
Deciding which agent does what, in what order, and what happens when one fails.
Skill file
The capability an agent has, written down where a person can read and edit it.
Cloud development environment
The compute, filesystem and toolchain live somewhere else, and are usually thrown away afterwards.
Running an AI agent in the cloud instead of on your laptop
Three approaches, one of which is ours, described precisely enough that you can tell which one you actually want.
Questions people ask
+Is the agent runtime the same as the model?
No. The model is a stateless reasoning service reached over an API; the runtime is a process on a machine that calls it repeatedly, holds the filesystem and credentials, enforces limits and records results. Swapping models changes the quality of the reasoning and nothing about the operational behaviour.
+Why does an agent need its own machine?
Because it needs a filesystem to write to, credentials that must not be exposed to a browser, network access for tools, and a process that keeps running when the requester's laptop closes. None of those survive in a client-side session.
+Can the runtime be swapped?
It depends on whether the product talks to a queue contract or to the runtime directly. Polaris deliberately defines the job contract in the database, so the service that claims jobs can be replaced without changing anything in the application.
Related
Task queue
The thing that lets a request survive the process that made it.
Headless agent
Nobody is typing at it, so its output is actions and artefacts rather than replies.
Agent orchestration
Deciding which agent does what, in what order, and what happens when one fails.
Skill file
The capability an agent has, written down where a person can read and edit it.
Cloud development environment
The compute, filesystem and toolchain live somewhere else, and are usually thrown away afterwards.
Work log
The record that makes an unwatched run reviewable afterwards.
Running an AI agent in the cloud instead of on your laptop
Three approaches, one of which is ours, described precisely enough that you can tell which one you actually want.