From ticket to PR¶

Agent Smith is an open source AI coding agent. You drop a ticket into your tracker, and a PR shows up on your repo, with the ticket already updated to point at it. Every run writes down what it cost in tokens and dollars, and every change it made comes with the reasoning the agent followed. That's the whole loop.

This page is the orientation. There's a fast-path link list at the bottom — if you're here to ship today, skip the rest and jump straight in.

What it does, in one paragraph¶

You drop a ticket into your tracker. Agent Smith reads it, clones every repo in the project into its own sandbox (each with its own toolchain image — a .NET repo gets dotnet/sdk:8.0, a Node repo gets node:20), generates a plan, lets you approve it (or runs headless if you've told it to), writes the code, runs the tests, opens one pull request per repo with the changes cross-linked, and writes the ticket back as resolved with every PR URL in the comment.

Lifecycle: ticket → orchestrator → sandboxes → pull requests → resolved

Watch it work¶

The dashboard is a live mission-control view of every run — what's waiting on you, what's running, and what finished today, each with its cost and the story of how it got there.

Agent Smith dashboard — runs overview

A run that hits a decision it shouldn't make alone pauses and asks; your answer resumes it immediately, no tokens burning while it waits. Every run keeps a five-beat story — ticket → plan → build → verify → outcome — you can open:

Run detail — the story of a run

Configuration for a server lives in the database and gets edited right here: agents, trackers, repos and connections wired into projects, with every reference picked from the catalog, so a project can never point at something that doesn't exist. Every edit is attributed and revertible, and the running server picks it up without a restart.

Configuration studio, the project wiring

What lands on disk after a run¶

Every run gets a directory under .agentsmith/runs/. The directory name is the run id — a UTC timestamp plus a 4-hex collision suffix plus a slug.

.agentsmith/runs/2026-05-22T14-03-11-9f2a-fix-login-bug/
├── plan.md       — the plan the agent followed, role-by-role
├── result.md     — what got done, cost in tokens and USD
└── decisions.md  — non-obvious choices made during the run

plan.md and decisions.md are the why-record. Six months later, when you've forgotten why the agent picked path A over path B, the answer is in there. That was the reason I built it this way — I got tired of code I couldn't reverse-engineer.

What's supported¶

Trackers — these are the ticket sources Agent Smith reads from and writes back to.

Tracker	Trigger modes	Connect page
Azure DevOps Boards	webhook · polling · label	Azure DevOps
Jira	webhook · polling · label	Jira
GitHub Issues	webhook · label	GitHub Issues
GitLab Issues	webhook · polling · label	GitLab Issues

AI providers — Agent Smith calls these directly from your infrastructure. You pick the model per role (a cheap one for scout passes, the good one for the actual code).

Provider	Notes
Anthropic Claude	First-class. Prompt caching on by default.
OpenAI	First-class. Reasoning models supported.
Azure OpenAI	Same as OpenAI plus per-deployment routing.
Google Gemini	First-class.
Ollama	Local models. No API key, no internet.
OpenAI-compatible	Groq, LM Studio, vLLM, your own endpoint.

See Connect your AI provider for the config blocks.

Skills — the role definitions (architect, backend dev, security analyst, contract reviewer, …) are developed in a separate repo, github.com/holgerleichsenring/agent-smith-skills, and every release ships with its catalog embedded: the binary you download already carries the exact skills it was tested with. Nothing to pin, nothing to fetch on first run. A skills: block in agentsmith.yml is only for overriding that — skills development, air-gap mirrors. See Skills catalog.

Get running today¶

The pages below are the fast-path. The only thing step 2 needs is an API key for an AI provider — everything else comes later.

Install — CLI binary, Docker image, or k8s.
First run — agent-smith demo proves the whole loop on a bundled sample project. One LLM key, no tracker, no Docker, minutes.
Connect your tracker — pick the page for your tracker.
Connect your repos — single repo, or multi-repo if your project spans more than one.
Connect your AI provider — the config block for the provider you have.
Point the loop at a real ticket: agent-smith fix --ticket 54 --project todolist — the first-run page walks it end to end. agent-smith doctor before that tells you whether the wiring holds.

Then pick a trigger mode (webhook is what you want for production) and pick a host setup (docker-compose is the easiest, k8s is what you want for shared use). Once it runs server-side, the dashboard is where you watch it: live step timeline, per-call LLM cost with the cached share, queued runs with their position, a cancel button that actually kills things.

How it works, when you have time¶

Methodology — the spec-first plan→review→verify→execute flow and why.
Lifecycle — what happens between ticket-in and ticket-back.
Spec dialogue — the conversational side: discuss work in Slack/Teams, file phases and epics, get asked when a ticket is too thin.
Expectations & durable dialogue — the ratified expectation as the run's acceptance contract, and how a run waits days for your answer without burning compute.
Multi-repo pipelines — one ticket, N sandboxes, N pull requests.
Skills catalog — where skills live, how versioning works.

Everything else lives in Reference. That's where the per-pipeline pages, the full agentsmith.yml schema, the architecture deep-dives, the pipeline-specific pages and the historical run-logs sit.