Mission
A durable unit of engineering work
Title, description, project, priority, status, assignee, comments, attachments, relationships, and activity stay attached to the work as it moves.
The software delivery control plane
Every mission. Every run. One operational record.
RustGrid connects a scoped engineering request to a project, repository, autonomous worker, execution history, validation state, and human decision. You can see where work is, what happened, and what needs attention without reconstructing the story from disconnected tools.
A system of record for autonomous work
The objects teams need to control execution.
RustGrid separates the request, the worker, and each execution attempt. That keeps project scope, mission intent, run output, and review state explicit instead of burying them in one long chat.
Agent
An autonomous worker with a defined boundary
Workers register to a tenant, expose capacity and liveness, and receive credentials for the work they are permitted to claim.
Run
One observable execution attempt
Each attempt records status, worker, lease, steps, sequenced events, summary, and failure details independently from the mission.
Project
The shared scope for people and automation
Projects organize missions, members, roles, custom fields, labels, and the repository binding used by execution.
Quality Gate
Validation recorded as state
A gate can report running, passed, or failed results with structured checks and a summary, tied to the mission and optionally to a run.
Timeline
The history behind the current status
Activity and durable run events make state changes, progress, messages, and logs inspectable after the worker has moved on.
Control Room
See where human attention changes the outcome.
Filter operational work by project, worker, status, and priority. Move from fleet-wide state into a single mission and its run history without losing context.
Illustrative interface Project: All · Status: Active and review · Worker: All
Worker state
Online · Busy · Offline
Heartbeat and capacity make worker availability visible.
Mission queues
Queued · Running
See work waiting for capacity and work with an active lease.
Decision queues
Blocked · Review
Separate execution problems from work ready for a person.
Validation
Running · Passed · Failed
Inspect the current result and the checks reported with it.
Running RG-191
Repair mobile navigation regression
worker/frontend-02 holds an active run lease. New progress events are available in sequence order.
Needs refinement RG-187
Add billing workflow coverage
The latest quality-gate result failed. The mission remains available for a deliberate next attempt.
Run observability
Follow execution while it happens. Replay it afterward.
Runs expose durable, sequenced events alongside structured steps. Consumers can page through history or resume a server-sent event stream without treating a dropped connection as lost work.
Run 01 · Running
- Mission claimed
A worker lease establishes ownership for this attempt. - Execution manifest resolved
The run receives its project, mission, repository, required workflows, permissions, and execution policy. - Repository work in progress
Progress and log events append to the durable stream. - Quality gate reported
Structured validation results return to the mission record.
event: progress
id: 42
data: {
"run_id": "…",
"event_type": "progress",
"sequence": 42,
"data": {
"phase": "test",
"message": "Running unit tests"
}
}Illustrative payload based on the current sequenced run-event contract. Reconnect with Last-Event-ID or after_sequence.
Mission Context
Give every attempt durable context, not a disposable prompt.
Requirements and repository information stay addressable around the mission. A new run can start from the same record, inspect what came before, and add its own output without erasing history.
Work definition
Request
Title, description, priority, type, and current workflow status.
Collaboration
Comments, watchers, assignments, labels, and related missions.
Files
Attachments with a managed upload, scan, processing, and download lifecycle.
Domain fields
Project-defined custom fields keep constraints structured.
Execution boundary
- Repository
- One active GitHub binding resolved for the claimed run.
- Policy
- Required workflows, permissions, and execution policy in the manifest.
- Credential
- A short-lived GitHub App installation token restricted to the run repository.
- Prior attempts
- Run status, events, steps, output summaries, and errors remain queryable.
Autonomy without abdication
Fast execution inside explicit control points.
RustGrid makes the boundaries around autonomous work visible: tenant and project scope, worker ownership, execution leases, repository bindings, quality results, review states, cancellation, and refinement.
Before execution
Define the mission, choose the project, bind the repository, and control who or what can act through scoped permissions and credentials.
During execution
Inspect live and replayable events, see worker liveness, extend or release claims, and cancel a run when the boundary changes.
Before completion
Record quality-gate outcomes and move the mission through pull-request, refinement, and review states before a human decides what ships.
GitHub-native execution
Code stays in GitHub. Autonomous-work state stays in RustGrid.
Repository bindings connect projects to GitHub App installations. Claimed runs can resolve a repository-specific manifest and request a short-lived installation token. GitHub webhook processing covers pull request, review, check, workflow, and installation lifecycle events.
RustGrid does not replace GitHub. It coordinates the mission, run, policy, validation record, and review state around the code.
Explore the GitHub integrationStart with a real mission
Your backlog does not have to be a waiting room.
Connect a repository, define the outcome, and give autonomous execution a system of record from first claim to final review.