Multi-agent DAG orchestration, purpose-built for enterprise engineering teams Learn more →

Custom agents

Last updated 2026-05-21·8 min read

An agent is an autonomous, LLM-powered worker that performs one class of task inside a run. Cendriix ships a roster of built-in agents and lets you fork them or define your own. This guide covers the agent definition and how to author a custom agent.

Built-in agents

NameDescription
orchestratorReads the need, plans the work, and routes steps to the right agents. Runs first in most workflows.
devWrites and modifies code, opens pull requests, resolves review comments.
qaRuns and interprets tests, reproduces bugs, and writes regression coverage.
sreProvisions infrastructure, runs deploys, and reads telemetry to confirm a rollout is healthy.
securityReviews diffs for vulnerabilities and policy violations before a change merges.

The agent definition

Every agent, built-in or custom, is described by a single definition: a model, a system prompt, a permitted tool list, and a resource budget. Custom agent definitions live under .cendriix/agents/ and are versioned with the rest of your workspace configuration.

json
# .cendriix/agents/legal-review.yaml
slug: legal-review
name: Legal review
description: Flags license and compliance risks in a diff.

model:
  provider: anthropic
  name: claude-opus-4-5

prompt: |
  You review code changes for license compatibility and
  data-handling compliance. Flag risks; do not modify code.

tools:
  - github.pr.read
  - github.pr.comment

budget:
  max_usd: 2.00
  max_tool_calls: 40
  timeout_s: 600

Forking a built-in agent

The fastest way to create a custom agent is to fork a built-in one and adjust only what you need. The fork inherits the base agent's prompt and tool list; your overrides are layered on top.

bash
# Fork the dev agent into a customised variant
cendriix agent fork dev --slug dev-frontend

# Edit the generated definition, then publish
cendriix agent publish .cendriix/agents/dev-frontend.yaml

Tool permissions

An agent can only call tools that appear in its tools list, and every call is still subject to the workspace policy set. The list references tools by their fully qualified name, for example github.pr.comment or aws.ecs.updateService. If an agent attempts a tool that is not permitted, the orchestrator blocks the call and records a policy verdict in the audit log.

Least privilegeGrant only the tools an agent actually needs. A narrow tool list is the most effective guardrail, it removes whole classes of mistake before a policy ever has to evaluate them.

Model binding

Each agent binds to a model by provider and name. Cendriix supports Anthropic, OpenAI, and Google model families, as well as models you host yourself behind a compatible endpoint. A run can override an agent's model at trigger time with the --model flag, which is useful for A/B testing a cheaper or faster model on a non-critical step.

Resource budgets

Every agent definition carries a budget: a maximum spend, a cap on tool calls, and a wall-clock timeout. The budget is enforced live, an agent that reaches its ceiling is halted and the step fails cleanly rather than running unbounded. Budgets compose with the run-level cost cap described in Cost meters.

The agent library

The Agent Library in the dashboard lists every agent available to your workspace, with its model binding, tool list, and recent run history. Beta Agent-to- agent handoff configuration, letting one custom agent delegate to another, is currently in beta; the underlying handoff for built-in agents is generally available.

Next steps