Autonomous development you can trust, monitor, and control
Autonomous automation is only valuable if it is safe and observable. CrewWork provides layered controls: bounded execution, validation gates, human plan approval before a user-started delivery program writes any code, opt-in repair triggers with cooldowns and daily budgets, and full audit trails across both your projects and the platform itself.
For the platform self-repair (self-modification) deep dive, seethe dedicated page. This page focuses on broader operational controls.
Self-repair, governed
When the platform encounters a runtime error in its own code, it aggregates the error by pattern and, once it crosses a configurable threshold, an admin launches the fix with one action, subject to layered gates:
- An isolated worktree and tiered validation up to the full test matrix with incumbent-attested evidence.
- A write-scope gate that keeps the fix inside its declared files, and protected platform-authority paths that route straight to mandatory human review.
- A quality gate that diffs candidate against parent and blocks any new suppression.
- A pre-publication checkpoint that refuses to open a pull request (PR) without a present, identity-matched assurance manifest.
Output is always a draft PR you approve. The platform never merges its own changes.
Catch code quality issues before they become production incidents
Waiting for errors is reactive. CrewWork analyzes your codebase after each indexing pass and on demand, identifies improvement opportunities backed by evidence, and proposes targeted changes, each scoped to a single reviewable PR.
Suggestions go through a critic pass that filters out redundant or low-signal ideas. What survives is actionable, evidence-based, and ready to approve or dismiss.
Evidence-based analysis
The pipeline scans the codebase for TODOs, coverage gaps, API surface area, and structural patterns to build a factual picture of where improvements are possible.
Critic review
Every suggestion passes through a critic that filters out redundant, already-implemented, or low-signal ideas. Only actionable suggestions survive.
Single-PR scope
Each suggestion is designed to be implementable in a single pull request, with impacted files, validation commands, and risk assessment included.
Automatic or on-demand execution
The suggestion pipeline runs automatically after every codebase indexing pass and can be triggered on demand. Results appear in the platform workspace for review.
Platform vs. project
Both lanes share the same error triage queue and guardrail philosophy, but run purpose-built engines.
Project HotFix
Targets your application repositories. Fixes validate against your project’s own commands and land on an isolated delivery branch. Pushing to GitHub is an explicit opt-in.
Platform self-repair
Targets the CrewWork platform itself, under stricter gates: isolated worktree, full matrix validation, and a draft PR you approve.
Watch the platform work
Platform self-repair runs, suggestion cycles, error aggregation, and validation results are all visible in the platform workspace. A monitoring stack built into the default deployment adds metrics, logs, and traces for deeper operational diagnostics. Sentry integration health is surfaced here so teams can verify error monitoring connectivity and confirm that automated repair triggers are operating safely.
Every remediation produces an append-only event log capturing the execution lifecycle, every stage transition, policy decisions, and per-stage attempt history, with validation results persisted in a durable run bundle. The log is queryable, so auditors can reconstruct any run after the fact.
Every ingested error event is retained for a configurable window (seven days by default) and can be reviewed and replayed for reconciliation, per project or platform-wide, with a dry run showing exactly what a replay will do before it runs. Any project member with read access can also pull a non-certifying compliance evidence report over that same history: see Compliance Evidence for the full model.
What you can see
- Platform self-repair run history with status, diffs, and validation results
- Error aggregation dashboard with pattern frequency and repair status
- Suggestion pipeline output with evidence and critic review decisions
- Daily budget usage and cooldown status
- Sentry integration health status, verification freshness, and ingest recency
- A model invocation ledger in the CrewWork Control console records every call with its model, provider, latency, token count, and exact USD cost, with trace and span lineage; prompts and outputs are never stored
- A redacted platform activity log (timestamp, actor, action) in the CrewWork Control console, restricted to platform administrators
- Built-in Prometheus, Grafana, Loki, and Tempo stack: provisioned dashboards, OTLP tracing, and log search ship in the default single-host Docker Compose deployment, and the engine queries Loki for fix context
From validated change to running release
Operations does not stop at the merge. CrewWork builds OCI release artifacts in gVisor-isolated builders and deploys them to any host on your own network through an outbound-only, mutual-TLS release agent. There is no inbound connectivity to the target host. Release status is tracked from queued to running to healthy, and team on-call rotations escalate automatically when a release fails.
Bring your next piece of work.
Discuss what you want to build, repair, or improve, along with your deployment needs and access to CrewWork.
Or view the architecture for the full technical picture.