From ticket to PR

Agent Smith is an open source AI coding agent. You drop a ticket into your tracker, it clones the repo into a sandbox, writes the code, runs the tests, opens the PR, and sets the ticket back to resolved.

Every run shows its cost. Every change comes with the reasoning the agent followed.

MIT licensed
Runs on your infrastructure
Calls your AI provider directly
A ticket comes in from your tracker. Agent Smith spawns one sandbox per repo, drives a tool-calling loop, then opens one PR per repo and resolves the ticket.

How a ticket actually becomes a PR

You drop a ticket into your tracker — Jira, Azure DevOps, GitHub Issues, GitLab, whatever you use. Agent Smith reads it, figures out which project it belongs to, and starts a run. If your project has more than one repo, every repo gets its own sandbox with its own toolchain image (one runs dotnet/sdk:8.0, another runs node:20, a Python worker gets python:3.12). Each sandbox clones its repo and cuts a branch named agentsmith/ticket-{N}.

Then the AI does the boring middle part. It analyses the code, comes up with a plan, lets you approve it (or runs headless if you trust the pipeline), writes the changes, runs the tests, and commits. One pull request per repo, all linked to each other in the PR body so reviewers see the whole change at once. The ticket gets set to resolved with every PR URL in the comment.

That's the standard flow. There's an approval gate before any code change lands, and every run records token usage and dollar cost so you actually know what you spent.

agent-smith fix "#54 in todo-list"
$ agent-smith fix "#54 in todo-list"
[1] FetchTicket → Null ref in UserService
[2] CheckoutSource → branch agentsmith/ticket-54 (3 repos)
[3] LoadContext → project context for server, client, worker
[4] AnalyzeCode → Scout mapped 483 files
[5] Triage → backend-dev + tester picked
[6] GeneratePlan → 4 steps, consensus after round 1
[7] Approval → approved
[8] AgenticExecute → UserService.cs, authClient.ts modified
[9] Test → 47 tests passed
[10] CommitAndPR → pull/42, pull/43
[11] PrCrossLink → siblings linked in both PRs
2 pull requests open · ticket #54 → resolved · $0.018

Why I built it this way

Your code stays on your machine.

Agent Smith calls sdoes not store any information about your code. It runs on your infrastructure. The more AI is been used, the more information is probably been saved unwantedly.

You see what every run cost.

Great developers write great code. They even write documentation. I never seen [the why being documented](https://codingsoul.org/2026/04/11/the-why-never-gets-written-down/). Agent Smith will document the plan and maintain a decisions.md log. Reasoning will be available over the complete lifecycle of the program.

Approval sits between the plan and the code.

The AI generates a plan, the plan gets shown to you, you approve or reject. Trust the pipeline? Set a config flag and runs go headless. Both modes ship because some teams want the eyeball, some don't.

One sandbox per repo, with its own toolchain.

You prefer mono repositories? Great, Agent Smith can work on UI, backend and workers directly. You got multi repositories per project? No problem. Agent Smith will create one sandbox per repository and create multiple pull requests.

Which languages ares supported?

You write Python? The sandbox will be Python based. Dotnet? Sandbox will use your dotnet sdk. The language is not part of the Agent Smith, it is part of the infrastructure that is used to get the job done. There are no limitations in terms of languages.

There are more pipelines than fix-bug

fix-bug is the headline because it's the one most people show up for. Eight more presets ship in the box: add-feature (same flow plus generated tests and docs), security-scan and api-security-scan (multi-role review against a codebase or a live API), legal-analysis (contract review with five legal specialists), mad-discussion (multi-agent design discussion when you want to argue something out), init-project (bootstraps the .agentsmith/ directory in each repo of a project), autonomous, skill-manager. Same orchestrator, different roles, different output shapes.

You can also define your own in agentsmith.yml. Skill files are YAML, no prompt engineering. Pipeline reference is in the docs.

Providers and deploy

Works with Claude, OpenAI, Gemini, Ollama (for fully local), and anything OpenAI-compatible (Groq, Azure OpenAI, LM Studio, vLLM, your own endpoint). You pick the model per role: a cheap one for the scout pass that maps the codebase, the good one for the actual code.

Deploy as a single binary, Docker container, or Kubernetes. The sandbox-agent injects via an init-container into whatever toolchain image your repos use, so you get one carrier image plus the upstream toolchain image you already trust. A chat gateway lets you trigger runs from Slack and Teams when that's how your team works.

AI providers · Docker Compose · Kubernetes

Have a look

First bug fix in about five minutes if your Docker is set up. The getting-started guide walks through it.