Before SAR became a framework for self-learning agents, it was an attempt to make a fragile, highly configurable mobile application capable of protecting—and, within limits, repairing—itself.
The support system began to outgrow the product.
In August 2020, a small team from BlueLight Creatives Studio began exploring a different way to distribute and configure Minecraft shaders on Android. At the time, using a shader on mobile commonly involved downloading files, installing them manually, and repeating the process whenever the user wanted a different version or configuration.
The proposed application would reduce that friction. A user would install the shader once, then use an Android interface to select presets and adjust the experience to suit the device, visual preference, or performance target. Advanced users could also edit configuration code directly.
That flexibility created a second problem. A mistyped expression, unsupported setting, or extreme value could break the shader or crash part of the application. The editor could expose the code, but it could not reliably explain every semantic error or detect every combination that would behave badly on a particular device.
- Install the shader package once
- Choose presets and device-appropriate settings in the app
- Permit direct configuration editing for advanced control
- Use SAR to detect, contain, and repair failures
An antivirus for its own code.
The first versions of SAR were not intelligent in the modern sense. They were a large collection of hardcoded rules covering failures the team could anticipate: malformed configuration, abnormal values, incompatible options, repeated crashes, and features that behaved differently across devices.
When a problem appeared, SAR logged the crash and began changing internal toggles and values to narrow down the cause. It could reduce a setting, substitute a safer value, disable an option, or restore the default configuration. It then checked whether the failure still occurred, in a process closer to automated troubleshooting than machine reasoning.
If those attempts failed, SAR could isolate the affected area of the application and prevent the user from reopening it. The system preserved the diagnostic record, sent a report to the developers, and kept the unstable feature inaccessible until a later update supplied a confirmed fix. The application could therefore continue operating without repeatedly exposing the user to the same known crash.
- Detect
Record the crash and identify the configuration or application area involved.
- Narrow
Change internal booleans, limits, and feature states to isolate the trigger.
- Repair
Reduce, replace, or reset suspect values and test the application again.
- Contain
Block only the unstable area when automated recovery cannot make it safe.
- Report
Send the evidence and attempted fixes to the development team.
The approach worked, but its cost grew with every new device, setting, feature, and interaction. Each scenario required more branches and more repair rules. Almost 80% of development time was eventually spent widening SAR rather than building the shader application it was meant to support. The safety layer had become the larger project.
The recovery system acquired an identity of its own.
The application worked, and the team gave its internal repair system a name: Kaizen AI. The name reflected an idea of continuous improvement, even though its earliest intelligence still came from deterministic rules rather than a learning model. In later versions, Kaizen AI was shortened to Zen AI and became more commonly known as ZenAI.
This naming marked an important change in how the team understood the project. ZenAI was no longer merely a diagnostic component inside a shader application. It was becoming a reusable approach to software that could observe its own failures, adjust its behavior, and preserve enough evidence for either recovery or escalation.
- August 2020
BlueLight Creatives Studio begins the mobile shader application and its rule-based SAR experiments.
- Kaizen AI
The repair system gains its first identity as an engine for continuous, automated improvement.
- ZenAI
Later versions simplify the name as the system grows beyond its original diagnostic role.
- Late 2022
BlueLight Creatives closes, bringing its approximately three-year creative chapter to an end.
- Early 2024
Xilo picks up the underlying ideas and continues the SAR lineage through modern AI.
That continuation produced the Kestrel Framework. Kestrel pursued the broad idea of an extensible agent framework associated with systems such as OpenClaw, but its design brief responded to problems Xilo had observed around those systems at the time.
- Reduce extensive token consumption during each agent turn
- Limit dependence on AI providers whose licenses or third-party support could change
- Make agent behavior, tools, and workflows more deeply customizable
- Treat security and constrained execution as architectural concerns
- Carry SAR's self-diagnosis and self-repair principles into an agent framework
Early Kestrel versions, however, exposed a new and more consequential weakness. SAR had no independent governance system. The agent could decide to modify itself, prepare a successor, evaluate that successor using its own judgment, and then rewrite its active version without external limits, guardrails, verification, or approval.
This created a circular trust model: the system proposing the change was also the system defining the test, interpreting the result, and authorizing deployment. A successful self-check only demonstrated that the newer version satisfied criteria chosen by the same intelligence that wanted the change. It did not establish that the change was safe, aligned, secure, or even fully understood.
From exhaustive rules to a repeatable learning cycle.
The original SAR attempted to create adaptability through the volume of its rules. Its later formulation—Study, Analyze, Reprogram—turns the same recovery instinct into a more general cycle. It separates evidence gathering, interpretation, and controlled change so that a system can improve without being granted unrestricted authority over itself.
Study
Capture the failure in context: logs, configuration, device limits, recent changes, prior repairs, and the user's intended outcome.
Analyze
Test known rules first, then form and rank new explanations when the failure does not match a previously documented case.
Reprogram
Apply the smallest approved change, validate it in isolation, preserve a rollback point, and record the result for the next cycle.
Reprogram does not have to mean rewriting the application's source code. It may be as limited as selecting a safer configuration, changing a prompt, updating a workflow rule, disabling one capability, or proposing a patch for human review. The important distinction is that an observed outcome changes future behavior in a traceable way.
Reasoning expands the space of recoverable failures.
Large language models make it possible to revisit the central limitation of the early system: SAR only knew how to respond to cases its developers had already described. A modern implementation could examine crash logs, configuration files, device characteristics, recent edits, source context, and the user's goal together. It could infer relationships between them and propose an explanation even when no exact rule exists.
For example, a shader value may be syntactically valid yet consume more graphics memory than a device can provide. A rule-based validator might accept it. An LLM-assisted SAR could connect the change to the resulting crash, explain the resource conflict, suggest a safer range, and prepare a repair for isolated testing.
Validated rules handle common syntax faults, fixed limits, known incompatibilities, permissions, and actions that must never be left to probabilistic judgment.
An LLM investigates unfamiliar failures, ranks possible causes, explains its reasoning, and proposes bounded experiments rather than directly declaring its first answer correct.
The result is not the replacement of rules with AI. It is a hybrid architecture in which rules define the safe operating area and a reasoning model explores uncertainty inside it. For Kestrel, this also means separating the agent that proposes an internal change from the mechanisms that decide whether that change is permitted to proceed.
- Guardian
Reject known-invalid states and enforce hard safety, privacy, and permission boundaries.
- Context builder
Collect only the logs, configuration, recent changes, and system details relevant to the failure.
- Diagnostic reasoner
Generate and rank hypotheses when deterministic checks cannot identify the cause.
- Sandbox verifier
Test a proposed change away from the user's working state and measure whether it resolves the failure.
- Recovery ledger
Record the decision, outcome, approval, and rollback point so every repair remains auditable.
A plausible repair is not yet a safe repair.
Kestrel's early unrestricted SAR demonstrated why self-repair and self-governance cannot be the same function. An agent may be capable of improving its own implementation while remaining unable to independently prove that the improvement preserves every important constraint.
An LLM can produce a confident but incorrect diagnosis. It may modify the wrong setting, hide the symptom instead of resolving the cause, or propose a change whose side effects appear later. SAR must therefore separate diagnosis, experimentation, approval, and deployment.
Low-risk and fully reversible changes may be automated after validation. More invasive actions—rewriting code, removing configuration, transmitting diagnostics, or disabling a major capability—should require explicit permission. Every applied change needs a preserved prior state and a clear path back to it.
- Deterministic boundaries around every model-proposed action
- Isolated tests before a repair reaches the user's active configuration
- Versioned changes, complete cycle logs, and one-step rollback
- Human approval scaled to the risk and reach of the proposed action
- Data minimization and consent before diagnostics leave the device
Mobile deployment introduces further constraints. On-device models must fit limited memory, power, and storage budgets; remote models depend on connectivity and introduce privacy and operating-cost concerns. A practical SAR may use compact local models for classification, deterministic routines for routine repairs, and larger remote models only for complex cases that the user has chosen to escalate.
When recovery is impossible, the system should fail safely and precisely. Instead of blocking an entire application, it should isolate the smallest confirmed unstable capability, explain what happened, preserve the user's work, and prepare a minimized report containing the likely cause and every repair already attempted.
The shader application was a proving ground.
The early project anticipated several ideas now associated with automated remediation, self-healing software, and agentic debugging. It observed failures, changed system state, tested possible solutions, isolated unsafe behavior, and escalated unresolved cases with evidence.
Through Kaizen AI, ZenAI, and eventually Kestrel, those capabilities extended beyond shaders. A governed SAR could support creative tools with user-authored configurations, enterprise workflows that change faster than their documentation, long-running agents that need to improve from operational feedback, and applications that must remain usable even when one subsystem fails.
Its value is greatest where configuration is complex, the environment varies between users, failures are expensive to reproduce manually, and human developers cannot anticipate every combination in advance. The objective is not autonomous code mutation. It is shorter diagnosis, safer recovery, better evidence, and a system that learns without concealing how it changed.
SAR began as software that tried to survive every failure its developers could imagine. Its modern opportunity is more ambitious: to investigate failures they did not imagine, while remaining bounded enough to fail safely when it cannot yet repair them.