Baron

Baron

**Let your coding agent write to your work tracker — and keep the same flow when you change trackers.** Baron is an open-source layer that turns issues, branches, PRs, CI runs, and deployments into one normalized contract, so your agent never learns a vendor's API, states, or column names.


The problem

AI coding agents bake **one vendor's API** and **one team's process** into prompts. The moment your issues live in Azure DevOps but your code is on GitHub, or your board columns aren't literally "To Do / Done", or you switch trackers next quarter — the prompts break, and the agent falls back to raw, vendor-specific tools. You've hardcoded vendor lock-in into the way you work.

What Baron does

Plenty of tools let an agent *read* your tracker. Baron is about the other direction: **writing** — creating work items, moving them, cutting branches, opening and merging PRs — which is where an agent does damage when it guesses a vendor's state machine wrong.

The agent speaks one abstract vocabulary in terms of **roles** (`backlog → ready → in_progress → in_review → done`; blocking is an orthogonal flag, so a blocked item keeps the role the work is actually in), and Baron translates to each provider's real API, states, and quirks. You confirm that mapping once, at `baron init`, and it is committed to your repo as configuration — not re-guessed by the model on every call.

Each port binds to a provider independently, so `issues` on Azure DevOps, `scm` on GitHub, and `notify` on Slack is a normal setup rather than a special case.

What it looks like

You:  Start work on STORE-142.

Baron  ▸ runs the task-start recipe as a single call:
  ✓ Loaded STORE-142 "Add rate limiting to the login endpoint"  (type role: task)
  ✓ Checked it: not done, has a canonical branch, not assigned to someone else
  ✓ Branched feature/STORE-142 from the repo's