> ## Documentation Index
> Fetch the complete documentation index at: https://silmaril.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Learning your application

> A self-improving defense that learns your workflows and adapts as they change.

A coding agent's build repair workflow changes over time. The team adopts a new package registry, moves builds into a different environment, or replaces a tool. An action that once looked unusual may become routine. A familiar action may gain access to more sensitive data.

**Adaptability** is the ability of a defense to learn from these changes and improve its decisions over time. Silmaril's goal is a self-improving system that learns your application, detects where its understanding falls short, and tests improvements as the application evolves.

## Learn while the application runs

Suppose the team adopts a private package registry. The agent now needs to fetch a dependency from it to repair the build. A defense working from an older picture of the application might stop a legitimate installation.

An adaptive defense should recognize that its understanding needs to change. It can use the task, the package source, the surrounding actions, and reliable outcome signals to distinguish this new workflow from a malicious package recommendation in an error report.

The goal is to make that learning continuous, without requiring someone to write a new rule for every workflow change. Human feedback can help resolve ambiguity and provide useful examples. It is one learning signal within a broader improvement process.

## Improve through an autonomous loop

The architectural goal is a loop that observes activity, identifies mistakes or unfamiliar patterns, develops candidate improvements, and evaluates them against both legitimate work and attacks.

In the build repair, an improvement should recognize the team's new registry while still detecting a lookalike registry introduced by an untrusted report. Learning that one installation was legitimate should not make every installation acceptable.

Evaluation gives the loop a way to measure progress. A candidate should reduce unnecessary interruptions while preserving detection of harmful behavior. Changes that meet the deployment's evaluation and rollout criteria can advance, with subsequent decisions providing evidence for the next iteration.

A successful build alone is not enough evidence. The agent could complete the repair after exposing a credential or installing a malicious package. Improvement depends on learning whether the actions served the authorized task, alongside whether the task finished.

## Keep learning connected to enforcement

The degree of automation depends on the product and deployment, including the available signals, tuning mechanisms, and rollout controls. These principles do not imply that every SDK call retrains a model or immediately changes enforcement.

[Intent and outcomes](/docs/concepts/intent-and-outcomes) supplies the context for learning. [Independent enforcement](/docs/concepts/independent-enforcement) keeps the resulting decisions outside the agent's own reasoning. Together, they form [The Vital Trifecta](https://silmaril.dev/blog/vital-trifecta).