Agents

AgentLoop coordinates multiple specialized AI agents that work together to complete software development tasks. Each agent has a defined role, a behavior tree that drives its workflow, and runs in its own process so it can work in parallel with the others.

The agents listed below are starter templates — sensible defaults that cover most software workflows out of the box. The real power of AgentLoop is shaping these into your own agents: rewriting their behavior trees, swapping in your team’s conventions, or defining entirely new agents for your domain. See Customizing Agents below.

The Agents View

Open the Agents view from the navigation rail to manage agents in the desktop app. The top level is a roster of every agent type (as cards or a table). Drill into any agent to inspect it across a set of tabs:

Inspecting an agent’s behavior tree now lives right here in the Agents view — there’s no separate workspace to open. Select an agent to step through its behavior tree tick-by-tick in the debugger, and browse its recent runs under the Instances tab to replay a finished run after the fact.

Task agents are launched just-in-time for each task rather than kept running as continuous instance rows, so an agent’s recent runs reflect the work it has actually picked up.

Built-in Agents

AgentLoop ships a roster of agents covering the full software-development loop. They’re starter templates — most teams customize them or add their own (see Custom Agents).

Agents that work the board

These pick up tasks from the board and do the work.

Product Manager

AGILE breakdown of a request into actionable tasks, wired into a DAG of dependencies for optimal parallel execution. Use it when you describe a feature, want to plan a sprint, or need a task breakdown.

Try asking:

• “Break down user authentication into tasks and add them to the board.”
• “Plan a sprint for the admin dashboard rewrite.”

Engineer

Analyzes the codebase and implements changes in a single session: writes code, runs git (branch, commit, push), and self-reviews before handing off to QA. Each engineer instance works in its own worktree, so several can run in parallel, and they coordinate through agent-to-agent messaging.

Try asking:

• “Have the engineer implement the login API endpoint.”
• “Ask the engineer to fix the bug in the payment module.”

QA Tester

Runs your existing test suites and validates changes once implementation is ready. Bounces failing work back to engineering, and escalates persistent failures to Blocked. Can message engineers to clarify implementation details.

Try asking:

• “Ask QA to test the new authentication flow.”

Release

When a task reaches Done, pushes its branch and opens a well-crafted GitHub pull request — a descriptive title plus a thorough body summarizing the changes, test results, and context.

Merge Resolver

Merges parallel worktree branches when a subproject’s DAG completes, resolves conflicts between in-flight work, and coordinates merge ordering — including creating prerequisite tasks and reorganizing the DAG when a pre-existing bug fix has to land first.

Infrastructure agents

These run as a single always-on instance each and keep the system coordinated.

Orchestrator

The master coordinator. It schedules tasks across the dependency graph, routes each one to the right agent type, and holds exclusive access to git and GitHub operations — other agents request those through it. See Orchestrator.

Chat

The conversational interface. It owns the conversation, answers questions about your code, and routes your intent to the orchestrator. It phrases and sends requests rather than mutating task state directly. See Chat.

Agent Supervisor

A read-only sidecar paired with another agent. It answers questions about that agent’s live state — and can reason “in the agent’s voice” — without ever mutating project state, delegating work, or touching the shell.

Utility

BT Sandbox

A disposable agent that hosts a minimal behavior tree for the single-agent runner, outside the orchestrator. Swap its tree to experiment with behavior-tree mechanics in isolation — see Authoring Behavior Trees.

Specialization variants

AgentLoop ships specialized variants for common stacks. The right one is selected automatically based on your project type — and they’re built with the same template system you’d use for your own stack (a Rails engineer, a Terraform reviewer, a QA agent that knows your harness).

Customizing Agents

Templates are the floor, not the ceiling. Most teams get production-grade results by adapting agents to fit their codebase, their conventions, and their domain. AgentLoop is built around three layers of customization:

• Agent templates — Define new agents, or override the built-in ones, with markdown templates and frontmatter. Bake in your team’s conventions, the libraries you use, the patterns you want followed, the things you want avoided.
• Behavior trees — Reshape the workflow itself: where the agent retries, where it escalates, what quality gates it enforces, and which steps the LLM gets to decide vs. which run deterministically.
• MCP integration — Connect agents to your own tools through the Model Context Protocol — your test runners, your internal APIs, your data sources, your deploy systems.

This is where AgentLoop earns its keep. Two teams running the same starter Engineer template against the same task will get generic output; the same Engineer template tuned with your codebase’s conventions, your review checklist, and your CI tooling produces work that lands cleanly in your repo.

How Agents Are Driven

Every agent’s workflow is defined by a behavior tree: a workflow definition that combines deterministic control flow (sequence, retry, validation) with controlled LLM steps (analyze, plan, decide). This means:

• The same input produces the same execution path
• LLM reasoning is bounded to specific decision points
• You can inspect, replay, and debug any agent’s behavior tree from its Behavior Tree tab in the Agents view — see Debugging Behavior Trees

See Architecture for more on how agents fit into the system.

Delegation

You don’t usually delegate manually. The chat agent figures out which agent to involve based on what you’re asking, and the orchestrator routes tasks to the right agent type as they hit the board. But you can be explicit when you want to:

• “Have the engineer implement the API endpoint.”
• “Ask the QA agent to test the authentication flow.”
• “Have the product manager break this epic into tasks.”

Watching Agents Work

The Agents view shows live agent sessions:

• Which agents are currently active
• What task each agent is working on
• Real-time progress and status

Because task agents spin up per task, what you see reflects the work currently in flight; finished runs are kept under each agent’s Instances tab. Open the view from the navigation rail in the sidebar.

Parallel Agent Execution

Multiple agents can work simultaneously on independent tasks. Configure parallelism per project:

orchestrator:
  max_parallel_agents: 4

When parallel execution is enabled:

• Independent tasks execute concurrently
• Each engineer agent works in its own git worktree (when worktrees are enabled)
• Optionally each agent runs inside its own container sandbox

See Git Worktrees and Container Sandboxing for the isolation options.

Agent Workflow

Quality Gates

The orchestrator enforces gates between agent handoffs:

1. PM → Engineer — Tasks must have clear requirements
2. Engineer → QA — Code changes must be complete and committed
3. QA → Done — Tests must pass validation; failures bounce back