Skip to main content
Each agent lives in a directory under agents/<name>/. Configuration is split across two files: A skill is the portable artifact (SKILL.md + optionally a Dockerfile). An agent is a skill instantiated in your project with local runtime config. When you al add a skill, it becomes an agent. An optional Dockerfile can also live in the agent directory for custom container images. It may be provided by the skill author or customized per-project.

SKILL.md

The YAML frontmatter contains portable metadata. The markdown body contains the agent’s instructions.

SKILL.md Frontmatter Fields

config.toml

The per-agent config.toml contains project-specific runtime configuration. This file is created by al add, al agent new, or al config.

config.toml Field Reference

*At least one of schedule or webhooks is required (unless scale = 0).

Harness

The optional [harness] table selects which harness runs this agent.

Fields

Notes

  • pi is the default harness and supports the full model fallback chain.
  • claude runs the agent through the Claude CLI harness and uses the agent’s primary model only.
  • Per-agent [harness] overrides the project-level [harness].
  • The claude harness is intended for Anthropic Claude models.

Scale

The scale field controls how many instances of an agent can run concurrently.
  • Default: 1 (only one instance can run at a time)
  • Minimum: 0 (disables the agent — no runners, cron jobs, or webhook bindings are created)
  • Maximum: No hard limit, but consider system resources and model API rate limits

How it works

  1. Scheduled runs: If a cron trigger fires but all agent instances are busy, the scheduled run is skipped with a warning
  2. Webhook events: If a webhook arrives but all instances are busy, the event is queued (up to workQueueSize limit in global config, default: 100)
  3. Agent calls: If one agent calls another but all target instances are busy, the call is queued in the same work queue

Example use cases

  • Dev agent with scale = 3: Handle multiple GitHub issues simultaneously
  • Review agent with scale = 2: Review multiple PRs in parallel
  • Monitoring agent with scale = 1: Ensure only one instance processes alerts at a time
  • Disabled agent with scale = 0: Keep the config in the project but don’t run it

Resource considerations

Each parallel instance:
  • Uses a separate Docker container (or OS process in host-user mode)
  • Has independent logging streams
  • May consume LLM API quota concurrently
  • Uses system memory and CPU
See Scaling Agents for a guide on scaling with resource locks.

Timeout

The timeout field controls the maximum runtime for an agent invocation. When the timeout expires, the process is terminated with exit code 124. Resolution order: config.toml timeout -> project config.toml [local].timeout -> 900 (default) This means you can set a project-wide default in [local].timeout and override it per-agent.

Examples

Hooks

Hooks run shell commands before and after the LLM session. Pre-hooks (hooks.pre) run after credentials are loaded but before the LLM session starts — use them for cloning repos, fetching data, or staging files. Post-hooks (hooks.post) run after the session completes — use them for cleanup, artifact upload, or reporting. See Dynamic Context for a guide on using hooks effectively.

How it works

  1. Commands run sequentially in the order they appear in config.toml
  2. Commands run inside the agent’s execution environment (container or host-user process) after credential/env setup
  3. Each command runs via /bin/sh -c "..."
  4. If any command exits non-zero, the run aborts with an error
  5. Credential env vars (GITHUB_TOKEN, GH_TOKEN, etc.) are available to hook commands

Fields

Examples

Notes

  • Each hook has a 5-minute timeout
  • Hooks are bounded by the container-level timeout
  • Environment variables set inside hook commands do not propagate back to the agent’s process.env

Runtime

The [runtime] table controls how the agent process is launched. By default, agents run in Docker containers. The host-user runtime runs agents as a separate OS user on the host machine via sudo -u, without Docker. Host-user mode is useful when agents need to run Docker commands themselves (Docker-in-Docker is insecure), or when you want lightweight isolation without container overhead.

Fields

How host-user mode works

  1. The scheduler spawns sudo -u <run_as> al _run-agent <agent> --project <dir>
  2. Credentials are staged to a temp directory and chowned to the agent user
  3. Each run gets an isolated working directory at /tmp/al-runs/<instance-id>/
  4. Logs are written to /tmp/al-runs/<instance-id>.log (owned by the scheduler, not the agent)
  5. No Docker images are built for host-user agents

Setup

The agent OS user must exist and sudoers must be configured. Run al doctor to validate and auto-configure (Linux only):
On Linux, al doctor will:
  • Create the OS user if it doesn’t exist (useradd --system --shell /usr/sbin/nologin <run_as>)
  • Add a sudoers rule allowing passwordless execution
On macOS, al doctor prints manual setup instructions.

Limitations

  • No custom Dockerfiles — Dockerfile in the agent directory is ignored
  • No container filesystem isolation — the agent runs on the host filesystem
  • The [local] config section (memory, cpus, image) does not apply to host-user agents
  • needsGateway is false — the gateway is not started for host-user-only projects

Webhook Trigger Fields

Each entry in the webhooks array has the following fields: All filter fields below are optional. Omit all of them to trigger on everything from that source. See Webhooks for complete filter field tables per provider.

GitHub filter fields

Sentry filter fields

Linear filter fields

Mintlify filter fields

Model Configuration

The models field references named models defined in config.toml under [models.<name>]. List one or more model names — the first is the primary model, and subsequent entries are fallbacks tried automatically when the primary is rate-limited or unavailable.
See Models for all supported providers, model IDs, auth types, thinking levels, and credential setup.