Software development has changed fundamentally in the last four months. But there was one this is real, this isn't hype moment that made it all feel undeniable.
A Coinbase engineer shared that 5% of all PRs merged now come from their in-house background agents. Coinbase: a $50B company, 4,000+ employees, operating in one of the most safety-critical, heavily regulated corners of tech. And still, 5% of all their PRs were coming from a background agent.
In the days that followed, Ramp and Stripe shared similar stories.
That was the moment Shruthi and I started taking the idea of a background coding agent seriously: systems that take work, run independently, and come back with results. So we built Vajra — named for Indra's thunderbolt in Indian mythology: celestial, precise, and charged with force.
Today, we're open-sourcing it.
Vajra was shaped by ideas shared openly by teams building at the frontier of agentic engineering. This post is our attempt to pay that forward.
What Vajra Does
Vajra is a background coding agent. You assign it an issue through Linear, and it handles the rest: planning, implementation, review, and a pull request, without anyone steering each step by hand.
It draws primarily from two open-source projects. The first is OpenAI's Symphony, which popularized the idea of an agent that polls Linear for assigned issues and works through them autonomously. The second is StrongDM's Attractor, which introduced graph-based agentic workflows defined in Graphviz DOT syntax.
Vajra combines those ideas and extends them with isolated per-issue workspaces, flexible routing, a built-in revision cycle for PR feedback, and a dashboard for monitoring and configuration.
A few principles shaped how we built it:
Be where the user already is. We use Linear for task management and Slack for updates. Vajra lives in both.
Be maximally flexible. Different people on our team want different models, different agents, different workflows. Some tasks are one-shot. Others need multi-stage pipelines. Vajra supports all of this.
Default to safety, but trust the user. Vajra opens pull requests — it does not merge its own code. But if the issue creator explicitly asks for a direct merge, Vajra will do that. The engineer remains accountable. Similarly, when we gave Vajra access to our database, it was read-only.
How It Works
Vajra has its own Linear and GitHub accounts. Every 30 seconds, it polls Linear for issues assigned to it. When it picks one up, it moves the issue to In Progress, executes the relevant workflow, and, when it finishes, moves the issue to In Review, opens a PR, and notifies the issue creator on Slack.
That flow is intentional. It mirrors the way a human engineer already works: pick up a ticket, move it to In Progress, do the work, put it up for review, and notify the team. Linear remains the source of truth for what is being worked on and by whom, whether the worker is a person or an agent.
When a new issue arrives, Vajra first decides which workflow to run. The simplest path is label-based routing: attach a Linear label, and the issue goes straight to the matching workflow with no LLM involved. Everything else goes through a lightweight triage step that reads the issue, selects the best-fit workflow, determines the target branch and merge strategy, and falls back to the default pipeline if nothing matches cleanly. If the issue is too vague to act on, triage posts a clarification comment and waits for the issue to be updated.
Workflows as Graphs
One of Vajra’s core ideas came from Attractor: represent workflows as directed graphs defined in DOT files.
Each node in the graph is one of three things: an agent (an LLM invocation), a tool (a shell command, with no LLM involved), or a control node. The two control nodes are fan_out, for running agents in parallel, and fan_in, for collecting and synthesizing their results.
Edges between nodes carry labels, and agents emit labels to determine what happens next. That gives Vajra three core primitives for composing workflows:
Branching. An agent evaluates the current state and emits a label like lgtm, revise, or escalate, and the graph routes accordingly.
Loops. A review agent can send work back to the agent that produced the plan or code. The graph handles the cycle natively.
Parallelism. A fan_out node can spawn multiple agents in parallel—different approaches to the same problem, or different subtasks—and a fan_in node can compare, combine, or synthesize what comes back.
With those three primitives, you can build surprisingly complex workflows. The default pipeline we use looks like this:
Start → Plan → Plan Review → [revise loop] → Code → Code Review → [revise loop] → Prepare PR → Publish PR → Exit
But nothing locks you into that shape. Teams can define their own workflows using the same primitives, shaped around how they actually work.
Why Revision and Parallelism Matter
As we built Vajra, two needs became clear.
First, some tasks require iteration, not just execution. A planner might propose an approach, another agent might review it, and the work might need to go back and forth a few times before it is ready. We wanted Vajra to support that kind of collaboration directly: one agent produces work, another approves it or sends it back with feedback, and the next pass continues from the existing thread rather than starting over. Revision became a first-class workflow primitive rather than an awkward retry mechanism.
Second, some tasks benefit from breadth before convergence. Bug finding, security review, research, and planning often work better when multiple agents explore the problem in parallel using different models, prompts, or reasoning styles. The best answer is often not the first one. It is the best one among several.
That is why Vajra supports fan_out and fan_in. A workflow can branch into parallel agent runs and merge back together later in a step that compares, selects, or combines the strongest outputs. This lets the system use model and prompt diversity deliberately instead of relying on a single agent to find the best path on its own.
Revision loops make agent work iterative; fan-out and fan-in make it exploratory. Together, they make Vajra much better suited to the messy, non-linear shape of real engineering work.
Isolated Workspaces and the Revision Cycle
Every issue gets its own workspace: a directory with a fresh clone of the repository. Agents working on different issues never share state and never step on each other’s branches.
Inside each workspace, a .vajra/ directory carries persistent state across retries: thread history, checkpoints, PR metadata, and fan-out collections. Before each attempt, the workspace is reset to a clean Git state against the target branch, but .vajra/ survives. The working surface stays clean; the memory of what has already been tried does not disappear.
Pipeline state is checkpointed at every stage boundary, so Vajra can resume after crashes.
But the task does not end when the PR is opened.
Every PR Vajra creates automatically gets a built-in revision mode that sits outside the workflow graph. When a reviewer submits Changes Requested—or posts /vajra revise as a comment—Vajra fetches the full review context from GitHub, including the review summary, inline comments with file paths and line numbers, and surrounding conversation threads. It filters out bot noise, assembles a structured feedback document, and runs a lightweight revision pipeline that updates the existing PR in place.
If the reviewer requests changes again, the cycle repeats. The Linear issue only moves to Done once the PR is merged.
The Operational Surface
Vajra comes with a Next.js dashboard for monitoring and configuration. The monitor view shows real-time KPIs—active runs, retries, completions, and failures—alongside a sortable runs table with live SSE updates. You can inspect individual runs and their outputs in detail, compose simple workflows visually, drop into raw DOT when needed, and edit agents, skills, and configuration without touching the codebase.
That makes Vajra usable not just by engineers, but by anyone on the team who needs visibility into how it is operating.
Everything is accessible through API and CLI. Runs, agents, workflows, skills, and configuration are all exposed through a REST API with real-time SSE streaming. A SKILL.md file wraps the most common queries so engineers can inspect Vajra, or even create new agents and workflows, without leaving the terminal.
Slack is the error surface. Vajra notifies the issue creator when a PR is ready for review, but also when human action is needed: credential failures, rate-limit hits, or a workflow reaching its limit.
Skills act as shared engineering memory. Agent prompts stay thin and task-specific. Shared skill documents capture engineering standards, common patterns, and project-specific conventions, so workflows can stay modular without re-encoding the same guidance everywhere.
Everything lives on the filesystem. There is no external database. Checkpoints, thread history, collections, event logs, and stage artifacts are all stored as files. Every stage preserves its rendered prompt, agent output, structured result, and artifact snapshots for each visit. ls and cat are often enough to debug the system.
How We Use Vajra
We use Vajra for work that is clear, scoped, and naturally asynchronous.
A good example is a feature request where the engineer already knows what should be built and can describe it clearly in Linear. In those cases, Vajra can pick up the issue, work through the implementation, and come back with a pull request—or at least a revision-ready draft—without constant back-and-forth.
We also use it for bug reviews, database checks, overnight scans, and other report-oriented tasks where the goal is not open-ended exploration, but a useful result: a bug report, a proposed fix, a sanity check, or a signal that something looks wrong.
Vajra is much less useful for work that depends on live exploration or evolving taste. Because it runs asynchronously, it is a poor fit when the problem is still fuzzy, when a feature is not yet well defined, or when the right answer depends on rapid human iteration. If we do not yet know what something should look like, Vajra is usually the wrong tool.
In practice, Vajra is mostly orchestrated programmatically through the Linear MCP, usually from inside Claude Code or Codex. Recurring work is scheduled by creating Linear issues on a cron through the API, and, when we are on the go, we use OpenClaw wired up to the Linear MCP so we can create Vajra issues over text.
Why We’re Open-Sourcing Vajra
We are in a moment when good ideas compound quickly.
We looked at Symphony and Attractor, took what was useful, and built Vajra. Now we are open-sourcing it so others can build on it in turn.
Fork it if you want. But even if you never touch the code, the main thing we want to share is the design: background agents that live inside existing team workflows, graphs as the substrate for coordination, revision as a native part of the loop, and parallelism as a deliberate tool rather than an accident.
Look at Vajra, look at other projects, take what resonates, and build a coding agent shaped around how your team actually works.
Vajra has reshaped how we work and made us meaningfully faster. We hope it helps others do the same.