Loqira-Labs/agentkot

KOT presents a clear and unusually opinionated product vision. The documentation describes a broad agent harness with multi-provider orchestration, subagents, persistent teammates, resumable pipelines, virtual file edits, shell sessions, memory, history compaction, semantic search, media generation, and dynamic CLI tools. Tool contracts include parameters, limits, failure behavior, and examples rather than stopping at a feature list. English, Russian, and Chinese documentation are maintained across the main guide and individual tool references. The project is also direct about its threat model. It explicitly states that KOT executes commands and edits files with the launching user’s full permissions and expects users to supply isolation through a container, virtual machine, or separate account.
The central limitation is that this is a binary distribution repository, not an inspectable software repository. It contains three stripped executables totaling more than 160 MB, but no source code, dependency manifests, build process, tests, CI workflows, changelog, security policy, or reproducible-build instructions. Therefore, none of the substantial implementation claims can be independently verified. This matters because the binaries handle API keys, OAuth tokens, source code, shell access, file modifications, and network requests. The repository also has no license file, so users receive no clear permission to modify or redistribute the software. Claims such as “the best AI harness” are not supported by benchmarks or comparative evidence.
For a tool with this level of host access, release provenance should be the first improvement. Publish binaries through versioned GitHub Releases instead of committing them directly, and provide signed checksums, an SBOM, platform signatures, vulnerability reporting instructions, and documented credential-file permissions. Ideally, publish the Rust source and CI that builds and tests each artifact reproducibly. If the product is intentionally closed source, say so clearly and provide a commercial or source-available license plus an independent security audit. The web server should also document whether it enforces authentication and reject non-loopback binding unless explicitly enabled. Until those controls exist, the safest use is inside an isolated environment with no personal credentials or unrelated files.