Skip to main content
RELAI is framework-agnostic. It works best when a git-tracked Python, TypeScript, JavaScript, or Go project exposes a runnable local agent boundary.

​
Project readiness checklist

  • The project is a Git repository with at least one commit.
  • A supported Docker-compatible daemon is running and can run Linux containers; Docker Compose, Bash, and uv are available.
  • The daemon can see the project directory. VM-based runtimes may share only your home directory by default. Private-registry installs using build secrets also require Docker BuildKit.
  • The agent has a clear entrypoint: a function, command, graph, framework object, or another runnable boundary.
  • Dependencies and runtime constraints are declared in files visible inside the repository.
  • Provider credentials and other secrets come from environment variables or local env files—not committed source.
  • The behavior you want to test does not require an inaccessible production-only boundary.
Containers do not reuse your host environmentHost virtual environments and node_modules are not mounted into the Linux task image. RELAI builds from repository-visible metadata and lockfiles.

​
Language requirements

  • The task image must satisfy the runtime constraint declared by the project.
  • Declare dependencies in supported metadata such as pyproject.toml, requirements.txt, a lockfile, or the project’s package-manager files.
  • Commit the lockfile when the project uses one.

​
Important container constraints

Every agent image needs python3

RELAI’s launcher requires Python even when the agent project itself is TypeScript or Go. Supply it in the base image or runtime setup. RELAI checks selected agent images before Python preflight, including cached and custom images.

External local paths need packaging

file:, link:, and other paths outside the selected repository are not automatically available inside /workspace.
The separate verifier image needs the dependencies used by its checks and reward writer.

​
Framework support

During initialization, RELAI resolves the project’s exact dependencies and generates a project-owned adapter rather than selecting a maintained framework recipe. End-to-end turns are required; named targets, tool overrides, tool events, and framework-native components are enabled only when RELAI can verify them. Opaque or hosted frameworks can still work when the project exposes a runnable boundary. If RELAI cannot reach that boundary within the allowed project changes, initialization should explain the application change needed to continue.

​
Upgrades and teammates on different versions

RELAI artifacts remain usable when you upgrade the CLI. Upgrading does not rewrite, invalidate, or re-register agent tests, evaluators, benchmarks, EvalsWiki knowledge, configuration, or saved results, and it preserves your comments and edits.
  • An older CLI preserves fields and settings introduced by a newer version when it edits a shared artifact.
  • If an artifact uses a format that an older CLI cannot read safely, the command stops before changing anything and asks that teammate to upgrade.

​
Audit first, then initialize

Use RELAI to audit whether this machine and agent repository appear ready. Keep the audit read-only, explain every blocker, and ask before running relai init, which creates and validates project files.

relai setup --check does not write configuration. Full project validation happens during initialization, which can take several minutes and writes the simulator harness, EvalsWiki, and local project state. This checklist predicts common blockers; it does not replace initialization.

Project looks compatible?

Run one learning loop on your own agent.