What our run establishes
Our run on October 13, 2026, at commit f0b6e47 recorded a successful Node dependency step and a failing placeholder test command. The attached summary records 15 seconds for installation and 4 seconds for testing. The raw install tail also contains pnpm's own "Done in 1.2s" message; that is the package manager's report, not the harness's elapsed step time.
The test tail prints "Error: no test specified" and exits 1. This establishes that the selected Node test command failed. It does not establish a failure in Gentle AI's Go implementation or receipt-review workflow. Build was skipped, not failed. No parsed test counts were recorded, so there is no passing-test total or coverage claim to report.
Our harness preserves each step's status, elapsed time, exit code, timeout flag, and captured output tail. The exact stored record is the basis for this account. The MrKeyoor testing methodology explains that reporting approach and its limits; the supplied methodology page was fetched after this run and does not establish which procedure version the older run used. No new execution was performed for this correction. The audit field is null, so neither advisory results nor scan coverage are established.
What Gentle AI adds to an existing agent
The README pinned to our measured commit describes shared workflow guidance, Engram memory integration, skills, optional documentation access through Context7 MCP, configuration backups, and model assignment where supported. It lists 17 integrations and warns that features such as delegation and review depend on each agent's native capabilities.
Gentle AI configures supported agents; Gentle Shell owns its own Pi runtime, agents, and interface. The distinction matters when choosing an installation path: updating the Gentle AI binary alone does not establish Gentle Shell behavior or parity across agents.
The pinned README describes Organic Driven Development as keeping understood work lightweight while giving substantial authorized work a recoverable feature document. That is a documented workflow policy. Our sandbox did not test whether an agent follows it reliably, retains useful context, or produces better changes.
Review defaults depend on the version
The README at our measured commit describes RDD as on by default and opt-out, with informational results. It binds evidence to a frozen candidate and leaves delivery decisions to the user. Our run did not exercise that lifecycle.
The v2.4.0 release made review opt-in; the README at our measured commit describes it as on by default and opt-out. These sources describe different states of the project. The v2.4.0 release notes identify release commit 301fb2ad, which is not our measured commit f0b6e47. Their CI claims and known issues apply to those release bytes, not automatically to our checkout.
For v2.4.0 specifically, the release notes identify authority-lock scaling, a refusal loop involving a path over 4 MiB, and missing lineage retention among its known issues. Those are documented release limitations, not failures reproduced by our sandbox. Check the documentation for the version you intend to install before relying on a default or recovery procedure.
Evaluate the configuration before adopting it
Use the documented installation dry run to inspect the proposed selections and destinations. After a controlled installation, check the generated configuration and run the selected agent against a small task with an outcome you can verify. Test memory, tools, and review separately if they are reasons for adopting the system.
The supplied quickstart says a manual binary update needs a subsequent asset sync. It also documents a read-only doctor command for binaries, state validity, Engram reachability, and disk space. Those checks are useful preparation; a passing health check would still leave actual agent behavior to verify.
The current source extracts contain differing installation examples: the main README shows v4.1.1 while the quickstart labels v4.0.0 as stable. Neither changes the identity of our recorded checkout or proves that an installation command was executed in our sandbox.
Alternatives answer different needs
Superpowers provides a development methodology through composable skills and requires a separate installation for each harness. Consider it when the main requirement is a prescribed planning, testing, and review process. Its README does not establish a replacement for every Gentle AI configuration or memory feature, and it provides no basis for calling it smaller or faster.
Spec Kit provides structured processes, reusable templates, and documented outcomes for AI coding agents. Consider it when specifications, bug-fixing records, or idea assessments are the work you need to organize. Its supplied README describes these as independent entry points. It is a process alternative for that need, not evidence of equivalent memory or configuration management.
How to read the scores
These editorial scores use a five-point rubric: 1 means substantial documented barriers, 2 means considerable setup or operating work, 3 means usable foundations with material qualifications, 4 means substantial supporting documentation or participation evidence, and 5 requires strong evidence with few material qualifications for the dimension. They are judgments about the supplied evidence, not benchmark results or adoption measurements. Community assesses visible participation, not user count; maturity distinguishes release and recovery mechanisms from verified reliability.