Northstar Build is the current software-delivery proof of accountable autonomous work: it plans the assignment, runs coding agents in isolated workspaces, checks the result, and hands back a draft pull request.
Trackers hold the request. CI validates the code. Northstar runs the work between them.
A layered delivery workflow connecting an issue to a draft pull requestStart with the job each layer owns
Start with the three responsibilities, then inspect the complete capability matrix for a detailed review.
Task trackers hold intent. Northstar coordinates the agents, context, tools, and handoffs needed to act on it.
Custom scripts can cover a narrow path, but cross-repository work and shared context quickly become another internal platform to maintain.
Northstar adds isolated workspaces, explicit permissions, human approval gates, and a durable execution record.
CI/CD remains essential for tests and deployment. Agent-driven implementation needs a workflow before those stages begin.
A workflow carries the issue through implementation and returns reviewable code with evidence.
The aim is not to replace the tracker or deployment pipeline. It is to connect them through the non-deterministic work between assignment and review.
Detailed capability matrix
| Capability | Northstar BuildAgent delivery | Custom scriptsPython or JS | CI/CD pipelinesActions or GitLab | Task managementLinear or Jira |
|---|---|---|---|---|
| Orchestration and routing | ||||
| Multi-agent coordination | Built in | Partial or requires custom work | Unavailable | Unavailable |
| Dynamic tool provisioning | Built in | Partial or requires custom work | Unavailable | Unavailable |
| Context and memory sharing | Built in | Unavailable | Unavailable | Unavailable |
| Cross-repo workflows | Built in | Partial or requires custom work | Partial or requires custom work | Partial or requires custom work |
| Safety and control | ||||
| Human approval gates | Built in | Unavailable | Partial or requires custom work | Partial or requires custom work |
| Isolated workspaces | Built in | Partial or requires custom work | Built in | Unavailable |
| Permission boundary enforcement | Built in | Unavailable | Partial or requires custom work | Partial or requires custom work |
| Execution traces and audit logs | Built in | Unavailable | Built in | Partial or requires custom work |
| Developer experience | ||||
| Issue-to-PR workflow automation | Built in | Partial or requires custom work | Partial or requires custom work | Unavailable |
| Built-in integrations | Built in | Unavailable | Partial or requires custom work | Built in |
| Visual pipeline builder | Built in | Unavailable | Partial or requires custom work | Built in |
| Cost analytics and rate limiting | Built in | Unavailable | Unavailable | Unavailable |
Task trackers know what should happen. CI/CD knows how to validate and deploy. Northstar governs the work in between.
The missing middle layer
Traditional pipelines expect defined steps that pass or fail. Agents plan, loop, use tools, ask for help, and revise.
Local scripts can prove a workflow, but production use needs shared permissions, isolation, approval, and recovery.
Northstar does not replace the tracker or CI/CD. It provides the workflow for the work connecting them.
What the comparison demonstrates
Three distinct responsibilities
Orchestration
Agent work is iterative, not a deterministic job graph.
Agents plan, revise, use tools, and sometimes ask for help. Northstar is designed to coordinate that loop while scripts and CI/CD continue serving narrower deterministic roles.
Safety
The execution environment needs its own control surface.
Contained workspaces, permission boundaries, approval gates, and execution traces address risks that a task tracker does not own.
Handoff
The missing layer connects the issue to reviewable work.
Northstar sits between the source of intent and the systems that test, review, and deploy the result.
Start with Northstar Build, or bring a recurring engineering workflow to a design-partner pilot.