KAMOTO's README documents npm run agent, and its package.json is named solana-program-library

The Quick Start clones a repository with a different owner and a different name

The installation section opens with a clone command that does not point at the repository holding it. The URL is natoshi-kamoto/kamoto, while the project lives under natoshikamoto/KamotoAgent. The directory name in the second line, kamoto, follows the URL rather than the repository. This is not a typo you can correct by inference either, because the manifest that would confirm which tree is meant is the next section's problem: the root package.json does not contain an agent script to run in either tree. Anyone following the Quick Start ends up holding a checkout whose relationship to the README is undefined, and the .env.example the next step copies is not among the files the repository root lists either.

npm run agent is not one of the scripts the root manifest defines

The documented entry point is a single command:

npm run agent

The root package.json defines build, build:program, clean, lint, format, format:fix and test, and every one of them delegates to turbo. There is no agent script in that list, so the final step of the Quick Start has nothing to invoke. The step before it has a separate problem. The README says npm install, while the same manifest declares packageManager [email protected], and the root carries pnpm-lock.yaml and pnpm-workspace.yaml. The repository also records engines node at 14.0.0 or newer, a floor that predates the native fetch and ESM assumptions most current tooling assumes.

The root package is named solana-program-library

The package manifest describes a different project from the one the README describes. Its name field reads solana-program-library, it is marked private, and its workspaces are account-compression/sdk, token-lending/js and token-swap/js. The development dependencies are the tell: @solana/eslint-config-solana at ^4.0.0, @solana/prettier-config-solana, eslint-config-turbo and turbo at ^2.3.3, with prettier configured to @solana/prettier-config-solana rather than any house style. None of these three workspaces corresponds to a market research, portfolio or risk module, and none of them corresponds to the /core, /markets, /execution, /risk and /data layout that the Supported Modules section prints. The module map in the README has no counterpart anywhere in the build configuration.

The Rust workspace is a list of Solana on-chain programs

The Cargo manifest closes the case. Its workspace members are program directories named for chain functionality: binary-option/program, binary-oracle-pair/program, name-service/program, managed-token/program, shared-memory/program, stateless-asks/program, token-lending/program, token-swap/program and its fuzz target, token-upgrade/program, token-wrap/program, governance/program and governance/chat/program, plus libraries and Rust examples for cross-program invocation, sysvars and lamport transfers. Two comments confirm the provenance. One overrides opt-level for curve25519-dalek because the crate's SIMD backend is slow at the dev default and slows proof verification inside the solana-test-validator. Another keeps check-cfg entries for target_os set to solana. Alongside this sit Anchor.toml, cbindgen.sh, patch.crates-io.sh and update-solana-dependencies.sh, a toolchain that patches crates.io rather than a market data adapter.

The architecture diagram ends at a downward arrow, and five roadmap boxes are already ticked

The ASCII architecture drawing is unfinished. It shows KAMOTO at the top, a Reasoning Core beneath it, and three branches into Market Research, Portfolio Engine and Risk Engine, which rejoin and point down at nothing. No node receives that arrow, and no execution layer is drawn, even though the workflow example a few sections earlier ends at an Execution Adapter and then Monitoring. The roadmap compounds it. Agent reasoning core, market-data abstraction, portfolio context, simulation engine and onchain execution are all marked complete, while additional brokerage adapters, multi-agent research, strategy marketplace, autonomous portfolio management and agent-created onchain markets are open. What the tree contains for those five completed items is a memory/ directory and the Solana workspace, not a reasoning core.

The README says MIT and the repository metadata says Apache-2.0

Two different licenses are on the table for the same tree. The README closes with a License section stating MIT, and the project description repeats the MIT phrasing. The repository's license field states Apache-2.0, and a LICENSE file sits at the repository root. Neither statement can be dismissed, because the README was written for one project and the metadata was inherited with the build files from another. The practical rule is narrow and firm: do not assume the MIT line grants you anything until you have opened the LICENSE file at the root and seen which text is actually there, and do not assume Apache-2.0 either. This is the first thing to settle before a single line of this code reaches anything of yours.

The root carries a .gitconfig, a directory with a space in its name, and a Python test

The file listing explains where the tree came from more than the README does. Alongside the Solana toolchain files it holds .gitconfig at the repository root, which git does not read there, so it is inert config that documents somebody's local settings rather than affecting anyone. It holds a directory whose name contains a space, robinhood chain/, which breaks naive path handling in shell loops, glob patterns and most task runners. It holds backend_test.py in a project whose primary language is recorded as JavaScript, plus coverage.sh, test_reports/, test_result.md and a .mergify.yml for merge automation. .eslintrc.js, .prettierrc and .prettierignore are all Solana-flavored. None of this is harmful, and all of it says the repository was assembled rather than grown in one piece.

The risk policy gives a bare 5000 and the example trades a named listed company

The configurable risk block is the most specific thing in the README:

risk:
  max_position_size: 0.10
  max_daily_loss: 0.03
  require_confirmation_above: 5000
  allowed_assets:
    - NVDA
    - BTC
    - ETH

Two of the three limits are fractions of the portfolio, which is unambiguous. The third, require_confirmation_above, is a bare number with no currency, no unit and no statement of whether it means notional, order value or position value. That single ambiguity decides whether the guard fires on a 5,000 unit trade or a 5,000,000 unit trade. The allow list is headed by NVDA, and the worked example asks the agent to research NVIDIA and construct a strategy, which is why the Disclaimer bothers to state that KAMOTO is not affiliated with NVIDIA or any brokerage, exchange or financial institution unless explicitly stated.

Editorial conclusion

Read this as a scaffold rather than a shipped product. The README sketches a coherent pipeline of research, market data, thesis, risk analysis, position construction, execution and monitoring, and the risk policy is the right shape, but nothing in the tree implements an agent: there is no agent script, no src directory for the documented import, no .env.example to copy, and the build files belong to a Solana on-chain program workspace with its own members and toolchain. The clone URL, the entry point and the license statement each disagree with the repository that contains them, which leaves the whole Quick Start unfollowable as written. If you want the architecture, rebuild it against your own broker and custody stack, and write the confirmation threshold with an explicit currency. If you want to run what is here, you are running a program library. Treat the token address in the project description as unexplained until its owner says what it is.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. natoshikamoto/KamotoAgent on GitHub
4. Project website
5. README