Capabilities
Project preparation, execution environment and pull request follow-up mechanisms.
01
Specification
| Mechanism | Implementation |
|---|---|
| Warm nodes | A pre-provisioned node removes machine provisioning from task startup. With prewarming enabled and an available warm node, work can start in seconds. A warm node is unused capacity; after its operation it is deleted, not returned to the pool. |
| SOCI and internal container registry | AWE environment images are published with SOCI indexes to the internal registry. Lazy loading lets the worker start before the entire image is downloaded; remaining image data is fetched in the background. |
| Prepared project environment | The AWE contains project runtimes, dependencies, tools, service configuration and execution instructions for running the application and its checks. |
| Separate rootless Docker daemon | Docker runs on the node outside the agent container, without Docker-in-Docker inside the worker. The daemon supports image builds and containers for project services such as databases and queues. The daemon belongs to the worker stack on its single-use node; it is not shared across customer tasks. |
| Project service images | The environment declares service images in prewarm_images and Dockerfile builds in source_builds. The current runtime pulls or builds these images on demand; proactive prewarming is not active. |
| Cache reuse and refresh | Prepared dependencies and generated artifacts are reused. Refresh updates or invalidates them for the selected source revision. Reuse applies to caches stored in the project image, not the mutable workspace of a completed task. |
| Application verification | Builds, unit and integration tests run in the prepared environment. Headless Playwright checks are available when the project provides the browser and its dependencies. |
| Pull request follow-up | Open PRs carrying the project’s configured task label are eligible for automated follow-up when their branch belongs to the connected repository. PR updates, discussion, reviews, inline comments and completed CI events can trigger a run. The agent reads the current discussion, diff and checks to decide whether action is needed. |
| Review feedback, CI and conflicts | The agent can address actionable feedback, investigate failing CI jobs and resolve merge conflicts. It runs applicable verification and publishes completed changes to the same PR branch, with verification results and remaining issues. If no change is needed, it leaves the PR unchanged without a redundant comment. |
| Follow-up controls and credit usage | Automated runs use the project owner’s credits. Duplicate events and events received while a run is queued, running or publishing do not queue another run. The agent refreshes PR state before returning its result; it stops if the PR is closed, merged or loses its task label. Once the available credits are exhausted, new runs are not queued. The merge decision stays with you. |
| Optimized agent harness | A harness tuned for AWE execution, focused on shorter task runtimes and lower token usage. |