Configuring factory agents

Change how an existing factory agent works by editing its instructions, tools, and runtime in the Warp Factories web app or its definition files.

Prerequisites

• Editor access to this factory, or team or workspace admin access.
• An existing factory agent. See About factory agents for the default roles, or Creating custom agents to add a role.

Edit agent settings and instructions

For a Warp-managed factory, edit agent settings in the web app. For a GitHub-backed factory, settings are read-only in the web app; edit the factory definition files instead. See Where the definition lives.

1. In the web app sidebar, click your factory to expand it, then click Agents.

   

   The Agents page lists a factory’s foreman and default agents.

2. Click an agent to open its Settings tab.

   

   The Settings tab contains the agent’s description and resources.

3. Edit the agent description, harness, model, runner, host, MCP servers, or secrets.

4. To change the agent’s instructions, click Prompt and edit the prompt.

5. In the top-right corner, click Save.

Choose models and harnesses per agent

Choose each agent’s model and harness in its settings. Supported harnesses include the Warp Agent, Claude Code, and Codex. A foreman using Claude Code or Codex can still dispatch other factory agents, whose runs are tracked as its children.

Third-party harness access depends on your team’s plan and workspace settings. If a harness requires an upgrade, use the Warp Agent or review Warp pricing.

Default model IDs change over time, so choose based on what each agent has to do well:

Agent	What to optimize for
Foreman	Orchestration, instruction following, and long-running conversations
Triage	Research, evidence gathering, and working with connected tools
Spec	Synthesizing requirements, technical reasoning, and precise writing
Implement	Coding strength, with a harness that fits your repositories and toolchain
Review	A different model or harness from the implement agent, so the two don’t share blind spots

The model picker also includes custom routers from factories you can access. See Agent model choice, Custom routers, and Agent harnesses for available options.

For team-managed inference in definition files, see custom endpoint and BYOK model values, including factory defaults and per-agent overrides.

Reviewing inference for provider ZDR

Review every inference choice used by your workflow, not only the foreman’s model. Warp-managed inference is covered by provider Zero Data Retention (ZDR) across plans except for the models requiring provider retention. Turning off analytics doesn’t remove those exceptions.

For a Warp-managed factory, use the factory dashboard’s Agents and Scorers pages for their settings, and Factory definition for defaults and overrides that aren’t exposed in those editors. For a GitHub-backed factory, edit the existing files in the connected repository; dashboard settings are read-only. Both use the Factory definition syntax.

1. Review the factory default in factory.yaml: agentDefaults.model, or the model and type under agentDefaults.harness. Review each agent’s “Harness” and “Model” in Agents > the agent’s Settings, or its existing agents/<name>/agent.md frontmatter. An agent override can differ from the default.
2. Review Automations to identify the target agent for each trigger. In automations/<name>/automation.md, check execution overrides, especially model or harness. The automation editor doesn’t expose execution overrides.
3. Review the separate Computer Use model: agentDefaults.computerUseModel and any agent or automation computerUseModel override. An omitted value uses the documented inheritance or automatic selection, not necessarily the primary model.
4. If a selected model is a custom router, inspect every target and its default against the exception list. Review each Scorer’s “Judge model” on Scorers, or scorers/<name>/scorer.md. Also review the factory’s “Analysis model” for Self-improvement. These are separate inference choices from the agent’s primary model.
5. Before launching benchmarks, review every trial’s harness and model and the selected Scorers. For runs started through the CLI, API, or another agent, review any supplied model or harness override rather than assuming the saved agent settings apply.
6. Save dashboard changes, including definition edits. For a GitHub-backed factory, merge through your normal review process into its connected production branch and confirm a successful definition sync. Start a new run and inspect its model and harness in Runs. Existing runs keep their selected model; a completed test run doesn’t prove the provider’s contractual retention policy.

For customer-managed keys or endpoints, BYOLLM, and direct Claude Code or Codex calls, verify ZDR with the provider for the specific account, model, and configuration. Use factory inference options to identify the credential and provider route.

Auto, fallback, and auxiliary inference aren’t an immutable model pin. Recheck configurations when models or workflows change. Provider ZDR and analytics settings don’t disable factory transcript, attachment, or artifact storage.

Configuring a third-party harness

Change an agent’s harness to Claude Code or Codex to run it with that provider’s own coding tool.

1. In the web app sidebar, click your factory to expand it, then click Agents.

2. Click an agent to open its Settings tab.

3. In the “Harness” dropdown, choose Claude Code or Codex. The “Auth” field appears for these harnesses.

4. In the “Auth” field, choose a compatible, team-owned secret. To create one, click New auth secret for Claude Code or New OpenAI API Key for Codex.

   

   The Auth dropdown appears when a third-party harness is selected.

   Note

   • Claude Code accepts an Anthropic API key, Anthropic Bedrock API key, or Anthropic Bedrock access key.
   • Codex accepts an OpenAI API key.

   See connecting Claude Code credentials and connecting Codex credentials for how to obtain each key.

5. In the “Model” dropdown, choose a model from that harness’s catalog.

6. In the top-right corner, click Save.

With a Warp-managed factory, you can edit harness, auth, and model from the dashboard. A GitHub-backed factory sets them through agentDefaults.harness or a per-agent harness override in the definition files. For an example, see 03-multi-harness.

Related pages

• About factory agents - Understand responsibilities and human decision points
• Creating custom agents
• Factory skills
• Definitions as code