If you manage more than a couple of teams, you'll want them in version control — reviewable in pull requests and reproducible across environments. forge iac treats a whole workspace like infrastructure: your teams, the schedules that run them and the automations that fire them, defined in one forge.yaml and reconciled with plan and apply, just like Terraform.

Tip:You'll need the Forge CLI and an org API key with the teams:write scope. Install with npm i -g @forge/cli and run forge auth login.

Step 1: Export your current teams

Start from what you already have. forge iac export writes every team you own into a manifest:

forge iac export          # writes forge.yaml

Each team gets a stable key (derived from its name if it didn't have one). The key is how Forge matches a team across applies — keep it stable even if you rename the team.

Step 2: Edit the manifest

Commit forge.yaml to your repo and edit it like any code. Add a team, tweak a system prompt, add an agent:

version: 1
teams:
  - key: code-review
    name: Code Review Team
    description: Reviews pull requests
    agents:
      - role: reviewer
        name: Senior Reviewer
        system_prompt: You are an expert code reviewer...
      - role: security_auditor
        name: Security Auditor
        system_prompt: You audit code for OWASP Top 10 issues...

Step 3: Plan before you apply

forge iac plan shows exactly what would change — and touches nothing:

forge iac plan

  + create   bid-response (5 agents)
  ~ update   code-review (2 agents)
  = no-change marketing-campaign

  Plan: 1 to create, 1 to update, 0 to destroy.

Step 4: Apply

forge iac apply reconciles your teams to the manifest, prompting before it makes changes. Add --yes to skip the prompt in CI, and --prune to delete IaC-managed teams you've removed from the file:

forge iac apply             # interactive
forge iac apply --yes       # for CI pipelines
forge iac apply --prune     # remove teams not in forge.yaml

Warning:--prune only deletes teams that carry an IaC key (i.e. teams Forge is managing). Teams you built in the dashboard without a key are never touched. Even so, review the plan before pruning.

Schedules and automations too

A team on its own rarely represents the whole workflow. Two more top-level sections cover what starts it: schedules: for runs on a cadence, and automations: for the inbound webhooks that let an external system kick off a run. Both reference a team by its key, so the whole workflow lives in one reviewable file.

teams:
  - key: due-diligence
    name: Due Diligence
    use_org_knowledge: true     # ground runs in your documents
    peer_queries: true          # agents may ask each other
    agents:
      - role: researcher
      - role: financial_analyst

schedules:
  - key: weekly-scan
    team: due-diligence
    title: Weekly market scan
    brief: Summarise material changes since last week.
    cron: "0 7 * * 1"

automations:
  - key: crm-deal-won
    team: due-diligence
    name: New deal from CRM
    brief_template: "Run diligence on {{company}}."

Note:An automation's signing secret is never in the manifest — it's a credential. It's generated when the automation is created and printed once by apply; store it wherever the calling system keeps its secrets. A manifest containing a secret field is rejected rather than committed to your repository by accident.

Run it from CI

Because applies are idempotent and matched by key, you can run forge iac apply --yes on every merge tomain to keep your Forge teams in lockstep with your repo. Teams, their agents and each agent's tools, their team settings, the schedules and the automations are all reconciled from the manifest — and export will pull everything you already have into the file to start from.

Manage teams as code with forge iac