How does trunk-based development work with AI agents?

Why do AI agents push teams toward trunk-based development?

Agents produce many changes in parallel. On long-lived feature branches that means merge conflicts, stale branches and big merges nobody can review well. Trunk-based development avoids that: each change is small, merges to main quickly and deploys. Work that isn't finished is merged anyway, hidden behind a flag that is off. Flagger.gg's guide to trunk-based development with AI agents puts it simply: with agents shipping in parallel, flags replace long-lived branches.

How does an agent merge unfinished work safely?

It wraps the work in a flag and marks the flag not ready. In Flagger.gg, each app declares the flags it uses in code, and the SDK registers them when the app starts. A flag can carry a not-ready reason, which keeps it off and refuses to turn it on without an explicit confirmation. In auto-live mode, the default, a newly registered flag starts on unless it carries that reason, so the reason is how an agent ships dark. When the work is done, the agent removes the reason in a later change.

defs: {
  bulk_invoices: {
    summary: "Customers can send invoices in bulk",
    description: "New bulk send flow in billing",
    owner: "billing",
    notReady: "PDF export not done",
  },
}

Who decides when a feature goes live?

That's a choice per project. In Flagger.gg's auto-live mode, the agent can turn a finished flag on itself. With approvals on, an agent can roll out in production only up to a cap, 10% by default, and turning a flag on for everyone becomes a request a person approves. The Release console lists what's "Not live yet" first, with a one-line summary of each flag, so a person can see what the agents have merged and turn features on one at a time or in bulk. Read how to add human approval to an AI agent's actions.

What habits keep the main branch healthy?

• One flag per change, named for what it does, with an owner.
• Test both paths while the flag exists, on and off.
• Give agents the kill action, so a bad change on main can be switched off in seconds without a deploy.
• Remove the flag once the feature is on for everyone and stable, in a small follow-up change.
• Keep every merge small enough to review, by a person or a second agent.

How does North Bay Ventures work this way?

Every change at the studio, whether a person or an agent wrote it, goes through a pull request with automated checks, and merges itself once they pass. After merge, changes go straight to production; new companies have no staging server. Risky features ship switched off behind a flag. Read how we build companies, feature flags instead of staging and running many coding agents in parallel.