Skip to main content
KRAIT

Your First Evolution

Watch KRAIT write, validate, and open a human-reviewed pull request through the self-evolution cycle.

How Self-Evolution Works

KRAIT agents evolve by proposing changes to their own skill modules, validating those changes through a security and testing pipeline, and opening reviewable pull requests. In the current release, humans make the final merge decision and new capabilities take effect on the next deploy. The evolution pipeline is supervised by OTP, so a failed proposal never crashes the agent.

The Evolution Cycle

When the agent determines it needs a new capability, it follows a four-stage process:

  1. Propose — The agent generates a new or modified skill module using its configured LLM provider.
  2. Validate — Narsil performs static analysis, security rule checking, and taint tracking on the proposed code.
  3. Test — The proposed skill is compiled and executed inside a sandboxed Docker container against generated test cases.
  4. Review — If all checks pass, KRAIT opens a pull request with the diff, validation evidence, and test output for human review.

Triggering Your First Evolution

Start the agent in development mode and give it a task that requires a skill it does not yet have:

krait dev

Then, in the chat interface at http://localhost:4000:

> Summarize the contents of a CSV file at /tmp/sample.csv

The agent will recognize it lacks a CSV-parsing skill and begin the evolution cycle. You can watch the process in real time in the terminal output and inspect the pull request it opens.

Watching the PR Process

Every evolution is recorded as a pull request or draft proposal. You can inspect past evolutions with:

krait evolutions list
krait evolutions show evo-00a3f1

Each evolution record includes the proposed diff, Narsil validation results, test output, and review status.

Narsil Validation

Narsil enforces the security rules defined in your Configuration. During validation it runs:

If any check fails, the evolution is rejected and the agent receives structured feedback explaining why, so it can refine its next attempt.

The Review Flow

After validation and testing pass, KRAIT packages the change as a normal GitHub pull request:

proposal -> Narsil + allowlist -> sandbox tests -> Git branch -> PR -> human merge -> deploy

KRAIT deliberately does not self-merge in the first release. Promotion-gated auto-merge and BEAM hot activation are planned as a future activation boundary, after review evidence and rollback semantics are wired end to end.

Next Steps