Skip to main content
Experimental version.This is the latest in-development version of AI-Implement. Features may change without notice and behavior is not guaranteed. Switch to the latest stable version here.
AI-Implement runs each issue through a fixed set of stages, and stage agent configuration lets an administrator choose how each one runs:
  • planning — the read-only analysis pass
  • implementation — the code changes and any post-push fixes
  • review — the verdict passes
Every stage resolves to the same settings:
  • agent — claude or codex
  • provider — anthropic or bedrock for Claude, openai for Codex
  • model — the model id, passed through to the agent unchanged
  • account profile — the stored credential the run authenticates with
  • elapsed timeout — the wall-clock limit for one invocation of the stage, in milliseconds
Stage settings live in two layers: the orchestrator holds one set of stage defaults, and each project either inherits a default or overrides it. Nothing in a target repository carries them. A project only runs on this configuration once it opts in. Until then it stays on its existing behavior, described under Legacy projects below.

​
How a stage resolves

Each project resolves field by field against the orchestrator defaults:
  • An overridden field uses the project’s value.
  • An inherited field uses the orchestrator default.
Every stage must end with a value for every setting and an account profile that is active, permitted for the project, and matches the stage’s agent and provider. A stage with any field left unresolved cannot be enabled. This holds for every stage at once, including planning. Disabling planning on the mapping skips the planning run, but the planning stage stays in the configuration and must still resolve for the project to opt in. The Agents tab shows each field’s effective value and where it came from, so you can read the resolved stage before saving:
  • Effective: <value> (source: orchestrator default) — the field is inherited.
  • Effective: <value> (source: project) — the field is overridden here.

​
Set the orchestrator defaults

1

Enter the per-stage defaults

Open Models & providers. Complete the Orchestrator stage defaults table for each stage, then click Save.Use Elapsed time limit (ms) for the invocation timeout.A blank field has no default at this layer, so any project that inherits it is left with an unresolved stage. Fill every field you expect projects to inherit.
2

Turn defaults on

On the Settings page, under Orchestrator Agent Defaults, set Defaults mode to configured and click Save.The save is refused unless every stage already resolves to a complete selection, so enter the defaults first.
Turning on Defaults mode enrolls no project. It only makes the defaults available for projects to opt in to, one at a time. Until a project opts in, it stays on its existing behavior.

​
Opt a project in

1

Open the project's Agents tab

On the Projects page, open an existing project’s Edit dialog and select the Agents tab. A project must be saved before it can carry agent settings.
2

Choose Inherit or Override per field

For each field of each stage, pick Inherit to take the orchestrator default or Override to set a project-specific value. The effective value and its source update as you edit.
3

Opt in and save

Select Opt in to stage agent configuration and click Save agent settings.Opting in checks that every stage resolves and that the project is ready to run the selected agents. If a stage does not resolve, or a profile is not active, permitted, or compatible, the save is refused and nothing changes.
Agent settings save on their own button, separately from the rest of the mapping.

​
When opt-in is refused for readiness

Opting in inspects the backend the project would dispatch on, not just the configuration. A project whose runner or synced workflow cannot run the selected agents is refused, and nothing is saved. For a project on GitHub Actions, the common cause is a workflow file in the target repository that predates agent configuration. Run the Sync workflows action on the project’s row, merge the pull request it opens in the target repo, then open the Agents tab and opt in again.
Readiness depends on the backend, the target repository, and how each account profile authenticates, so opt-in is not guaranteed for every project. A Claude subscription profile cannot be enabled through project opt-in.

​
Example configurations

The model ids below are examples. Replace each with a model the selected account supports. Saving does not check whether your account can use a model. An unavailable model can fail when the stage runs.

​
Codex across every stage

One Codex profile (agent codex, provider openai) permitted for the project serves every stage:

​
A different agent by stage

Claude plans and reviews while Codex implements. This needs a profile for each agent permitted for the project — a Claude profile (provider anthropic) and a Codex profile (provider openai) — because each stage’s profile must match that stage’s agent and provider: Account profiles and their credentials are created on the Models & providers page. See Use Codex with OpenAI for the Codex profile, and Anthropic or AWS Bedrock for Claude.

​
Timeouts and limits

The timeout is an elapsed wall-clock limit for one invocation of a stage, in milliseconds. For example, 1800000 ms is 30 minutes. The same value carries two labels: Elapsed time limit (ms) in the orchestrator stage defaults, and Invocation timeout (ms) in a project’s Agents tab. How the limit combines with other caps depends on the agent:
  • Codex is bounded by this elapsed timeout together with the existing feedback-loop iteration cap (Max Iterations on the project).
  • Claude also honors this elapsed timeout, and its native turn caps stay separate — Max Turns per project, and Review Max Turns under the Retry Policy on the Settings page.
The remaining job time can shorten an invocation’s timeout. The Agents tab shows inherited and overridden values before that runtime limit applies.

​
When changes take effect

A saved selection applies to the project’s next run. A run already in flight keeps the settings it resolved at dispatch, so a mid-run change never alters it. For an opted-in project, the resolved model, timeout, and account profile take precedence over any model set in the target repository — including the model named in a reviewer definition, which the review stage’s configured model replaces.

​
Legacy projects

A project that has not opted in runs in legacy mode and is unaffected by stage configuration. It keeps:
  • the provider on its mapping’s Claude provider setting
  • the model from its repository front matter or per-repo configuration
  • its existing prompt front matter

​
Opting back out

1

Check the legacy credentials

Check the mapping’s Claude provider and make sure its legacy credentials are available.The next legacy run uses those credentials instead of a stage account profile. See Anthropic or AWS Bedrock.
2

Opt the project out

Clear Opt in to stage agent configuration and click Save agent settings.The next run uses legacy settings. A run already in flight keeps its resolved settings.