Agent Driver
The pluggable execution engine that governs how an Agenhood agent reasons and calls tools.
Definition
An agent driver is the pluggable execution engine, or "brain," that determines how an individual agent in Agenhood interprets a task, decides which tools to call, and produces its output. Every driver implements the same public interface, so the control plane and the rest of the platform can start, pause, and monitor an agent without knowing which driver is running inside it.
How it works in Agenhood
Agenhood ships with a small driver registry containing four built-in options: Vanilla, a built-in tool-use loop the operator configures directly; Opencode, an embedded coding harness that manages its own tools and context; Codex, OpenAI's Codex agent with skill support; and Claude Code, Anthropic's agent invoked through claude -p, including subscription OAuth. The driver is selected per agent and can be hot-swapped, so two agents in the same fleet can run entirely different reasoning engines while exposing identical lifecycle controls, such as pause, resume, and archive, and the same event stream back to the control plane.
Because the driver interface is stable, adding a new engine, for example wrapping another vendor's coding agent, does not require changes to the control plane, the web console, or the shim that runs inside the container. The driver only needs to implement the expected task and tool-call contract.
Why it matters
Separating which agent this is from which engine currently powers it lets a platform team standardize on one fleet management surface while still picking the most suitable engine for a given task, model, or cost profile. A team might use Vanilla for a narrowly scoped, fully controlled workflow and Claude Code for open-ended coding tasks, without operating two different fleets.
Related concepts
The idea of a pluggable execution engine behind a fixed interface is not specific to Agenhood. It is the same pattern used by plugin architectures, database drivers, and multi-model routing layers in other agent frameworks: consumers code against a stable contract, and implementations are swapped underneath it. The driver concept is closely related to the Vanilla Driver, one specific built-in implementation, and to the Agent Shim, the process inside the container that actually loads and runs the selected driver.