loncadev/baron

Baron

One pane of glass from backlog to deploy — for AI coding agents. Drive issues, branches, PRs, CI, deployments, and notifications across any stack through a single normalized contract, instead of hardwiring one vendor's API into your prompts.

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

Baron puts a normalized contract between the agent and your providers. The agent speaks one abstract vocabulary — work items, branches, PRs, CI runs, deployments, notifications, in terms of roles (backlog → ready → in_progress → in_review → done, plus blocked) — and Baron translates to each provider's real API, states, and quirks. Mix providers freely (Linear issues + GitHub PRs + Slack notifications). Same prompt, any stack.

What it looks like

You:  Start a task: add rate limiting to the login endpoint.

Baron  ▸ runs the task-start recipe as ONE deterministic call:
  ✓ Created STORE-142 "Add rate limiting to the login endpoint"  (type role: task)
  ✓ Branched feature/STORE-142 from the repo's default branch
  ✓ Moved STORE-142 → in_progress
  ✓ Commented: "Started on branch feature/STORE-142."

That same prompt on Azure DevOps sets the work item state to Active; on GitHub it applies an in-progress label — because in_progress is a role, not a vendor state. You confirmed that mapping once, at baron init. The agent never learns a vendor's column names, and the workflow's order is enforced by Baron's engine, not by the model improvising.

Why