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.
- Platform self-repair
- Automated validation
- PR-only output
- Platform suggestions
- plan approval
- before a user-started program writes code
- repair triggers
- opt-in, off by default
- cooldowns
- a minimum gap between repair runs
- daily budgets
- a daily limit on repair runs per project
- circuit breaker
- on error-monitoring webhook intake
- audit trail
- your projects and the platform itself
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:
- Isolation worktree and tiered validation up to the incumbent-attested matrix
- Write scope declared files only; protected paths routed to mandatory human review
- Suppressions any new suppression versus the parent blocks promotion
- Publication no pull request without an 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, scanning for TODOs, coverage gaps, API surface area, and structural patterns, and proposes targeted changes. Each one is scoped to a single reviewable PR with impacted files, validation commands, and a risk assessment.
Suggestions go through a critic pass that filters out redundant, already-implemented, or low-signal ideas. What survives is actionable, evidence-based, and ready to approve or dismiss in the workbench.
Platform vs. project
Both lanes share the same error triage queue and guardrail philosophy, but run purpose-built engines.
- project repair
- 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. See runtime repair
- platform repair
- Targets the CrewWork platform itself, under the stricter gates above, on its own isolated worker pool. View the dedicated page
Watch the platform work
Self-repair runs, suggestion cycles, error aggregation, validation results, and error-monitoring integration health are visible in the workbench. Every remediation produces an append-only, queryable event log of its lifecycle, stage transitions, policy decisions, and attempts, with validation results in a durable run bundle, so auditors can reconstruct any run.
Ingested error events are retained for a configurable window (seven days by default) and can be replayed per project or platform-wide, with a dry run first. Members with read access can also pull a non-certifying compliance evidence report over that history.
- model ledger
- Every model call in CrewWork Admin with its model, provider, latency, token count, exact USD cost, and trace lineage; prompts and outputs are never stored
- activity log
- A redacted platform activity log (timestamp, actor, action), for platform administrators only
- stack
- Built-in Prometheus, Grafana, Loki, and Tempo: provisioned dashboards, OTLP tracing, and log search in the default deployment; 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 hosts on your own network through an outbound-only, mutual-TLS release agent, with no inbound connectivity to the target. Status is tracked from queued to healthy, and on-call escalates automatically when a release fails.
See whether CrewWork fits your work.
CrewWork is built and running, and not yet generally available.
- worth discussing
- The errors and backlog you would hand off
- Where your source has to stay
- The evidence you would need to trust a change