Customizing Agents

Fullsend agents work out of the box, but most teams want to tailor them — add coding conventions, domain knowledge, extra skills, or entirely new agent roles. This page lists every customization approach from lightest to heaviest so you can pick the right one.

Quick decision guide

Goal	Approach	Effort
Teach agents your coding style, test commands, or architecture rules	AGENTS.md	Low
Give an agent domain-specific knowledge or a new capability	Skills	Low
Change model, timeout, image, or add env vars to an existing agent	Harness configuration	Medium
Build a completely new agent with its own trigger, scripts, and schema	Bring Your Own Agent	Medium with fullsend agent new, high by hand

Start at the top and move down only when a lighter option doesn't cover your needs. Most teams only need AGENTS.md and perhaps a skill or two.

AGENTS.md

The simplest way to influence agent behavior. Add an AGENTS.md file to your repository with conventions that apply to all contributors — human and agent alike:

# AGENTS.md

## Testing
- Always run `make test` before committing.

## Code style
- Use structured logging via `slog`. Do not use `log.Printf`.

Every agent reads AGENTS.md automatically. No fullsend configuration changes needed.

Best for: coding conventions, test commands, architecture rules, domain context.

Guide: Configuring with AGENTS.md

Skills

Skills are self-contained markdown documents that teach an agent how to perform a specific task. Place them in .agents/skills/ in your repo and symlink .claude/skills to make them discoverable:

your-repo/
  .agents/skills/
    deployment-checks/
      SKILL.md
  .claude/skills -> ../.agents/skills

Skills extend what agents know — linting rules, deployment checklists, customer data sources — without changing any fullsend configuration.

Best for: agent-specific domain knowledge, helper scripts, extension points, replacing built-in skills.

Guide: Configuring with Skills

Harness configuration

To change how an existing agent runs — its model, timeout, sandbox image, environment variables, or skills — use base: harness composition. Create a thin harness that inherits from the upstream agent and overrides only what differs:

# .fullsend/harness/code.yaml
base: https://raw.githubusercontent.com/fullsend-ai/agents/<sha>/harness/code.yaml#sha256=abc...

model: sonnet
timeout_minutes: 45
skills:
  - skills/my-custom-linting
env:
  sandbox:
    JIRA_PROJECT: "MYPROJ"

Register the agent in .fullsend/config.yaml:

agents:
  - name: code
    source: harness/code.yaml

Best for: changing model or timeout, adding environment variables, adding skills via harness, extending the sandbox image, disabling agents.

Guides:

• Configuring Agent Behavior — harness composition, status notifications, disabling agents, GitHub Packages
• Harness Field Reference — complete field reference, merge rules, and advanced configuration

Bring Your Own Agent

When you need a completely new agent — with its own trigger, scripts, and output schema — start with the generator:

fullsend agent new my-agent --role triage

It writes the files below, registers the agent in config.yaml, and checks that the result loads. You then edit agents/my-agent.md, the instructions the agent follows; everything else is ready to run. See fullsend agent new for the flags and the role table, and Bring Your Own Agent for a validated walkthrough.

.fullsend/
  harness/my-agent.yaml         # Execution config, including the trigger
  agents/my-agent.md            # Agent prompt — the file you edit
  schemas/my-agent-result.schema.json  # What the agent must produce
  scripts/post-my-agent.sh      # Turns the result into one comment
  policies/base.yaml            # Sandbox policy (written when absent)

The harness's providers: list is bare builtin names (vertex-ai, github-ro for triage) that resolve against fullsend's own embedded provider definitions and profiles, so no providers/ or profiles/ files are written. The provider pair depends on --role; see the role table for the others.

The agent runs automatically when matching events arrive. It runs on the hosted mint as long as it keeps a built-in role:; a distinct GitHub App identity requires your own mint (see Custom Agent Identity).

Best for: entirely new agent roles, custom triggers, specialized output schemas.

Guide: Bring Your Own Agent

See also

• Default, derived, and custom agents — when does configuration cross into custom agent territory?
• Escalation ladder — prove-it path before deriving or replacing a core agent
• OWNERS file authorization — control who can trigger agents via Prow-style OWNERS files
• Bugfix Workflow — how agents work together end to end