funes Agent Memory

Trust is generally strong but with deductions. least_privilege: README and SECURITY.md state everything runs locally by default and nothing leaves the machine unless you run push or bind a shared memory, and recommend fine-grained tokens (write only for pushing machines, read-only elsewhere); however the installer is a curl | sh remote script and the updater replaces the binary in place, so the privilege boundary is not minimal — 2. user_confirmation: there is an always-on secret gate before push, datasets are private by default, and directory installs ask for trust once, but hooks bound to a memory push automatically at session boundaries, an ongoing implicit egress — 2. data_flow_transparency: README discloses the User-Agent carrying version and an anonymous install id stored at ~/.funes/install-id, that it derives from nothing and can be disabled via DO_NOT_TRACK/FUNES_NO_TELEMETRY; SECURITY.md explains remote recall caches locally and the Hub only stores — 3. sensitive_data_handling: three layers (index-time redaction, fail-closed trufflehog gate at publish, funes scrub) plus a documented rotation and rebuild procedure after a leak — 3. dependency_security: Cargo.toml pins lance/lance-io/lance-index to =11.0.0 and object_store to =0.13.2 with a comment about the IVF scratch-dir leak in 11/12, and CI pins third-party actions by commit, but the dependency surface is large with no audit or SBOM evidence — 2. external_effects: push creates/writes Hub dataset repos and update replaces the binary and refreshes integrations; private-by-default and gating help, but no explicit second confirmation for update/push is shown — 2. rollback: README notes the memory is a disposable derived artifact that can be rebuilt and update --force reinstalls, but there is no documented way to unpublish a remote memory, roll back a version, or revert the binary — 1. source_attribution: recall hits name which agent and session they came from and ask names its sources, but publisher identity is unverified and the LICENSE copyright line (2026 The HuggingFace Team) needs independent checking against the repo owner — 2.

self_consistency: README command table, docs links, Cargo.toml examples, and CI workflows are mutually consistent, and version 1.9.0+dev matches the update/status description, but many referenced docs/*.md and scripts/install.sh are not provided, so full cross-checking is impossible — 2. dependency_availability: Cargo.toml lists dependencies and optional features clearly, and README states the Rust toolchain plus protoc requirement, no ML runtime dependency for the default backend, and a glibc >= 2.35 floor; however hf-hub is pinned to a 1.0.0-rc.1 pre-release and first run downloads ~1.2 GB of weights — 2. failure_messages: CI and SECURITY.md mention the gate failing closed and exiting non-zero, but the repository material shows no user-facing error message design, diagnostic output examples, or troubleshooting section — 1.

audience_and_scenarios: README targets developers using Claude Code, Codex, pi, and Hermes and covers cross-agent memory, cross-machine sharing, team collaboration, and trying a public memory, with concrete scenarios — 3. capability_boundaries: README states funes has no generative model of its own, only embeds and reranks, that a memory is bound to one embedding model and refuses vectors from another, and that changing it requires a rebuild; boundaries are clear but unsupported capabilities and failure modes are not systematically listed — 2. trigger_precision: docs describe recall/get as tools the model invokes on its own, per-turn indexing hooks, and session-boundary publishing, which is fairly precise, but there is no discussion of false triggers, duplicate triggers, or rate limits — 2. environment_fit: README lists prebuilt binaries for Linux x86_64/aarch64 and macOS Apple Silicon with a glibc floor, which is specific, but Windows, other architectures, and container environments are not covered — 2.

information_architecture: README is well structured with feature overview, install, command table, how it works, building from source, notes, and license, plus a docs index link — 3. install_notes: README gives curl install, funes add, funes update, and source-build instructions including protoc, and explains checksum verification and its limitation — 3. naming_stability: command names (add/bind/remove/index/recall/get/push/update) and config paths (~/.funes) are consistent across README and CI, but Cargo.toml comments reveal a workdir rename and schema migration scripts, indicating past naming/structure churn — 2. examples_and_faq: README provides several command examples and GIF demos, but there is no dedicated FAQ and examples are mostly one-liners rather than full end-to-end walkthroughs — 2. known_limitations: README Notes cover single-embedding-model binding, rebuild-to-change, and subagent transcripts being indexed, and SECURITY.md covers untrusted remote memories and prompt injection, but performance, scale, and platform limits are not consolidated — 2. license: a full Apache-2.0 LICENSE file is present and Cargo.toml declares license = "Apache-2.0", matching the metadata — 3. versioning_changelog: Cargo.toml shows 1.9.0+dev and README mentions funes update and status checking for newer releases, but there is no CHANGELOG file or version history in the provided material — 1. maintenance_responsibility: SECURITY.md gives [email protected] and Huntr as disclosure channels and CI/nightly workflows indicate ongoing maintenance, but publisher identity is unverified and there is no maintainer list or support commitment — 1.

output_usability: recall prints ranked passages, get reassembles a cited turn in full, and ask returns a grounded answer naming sources, which is usable for agent consumption, but README explicitly says output is shaped for agents rather than people, so direct human use requires ask — 2. marginal_value: unified cross-agent memory, publishable Hub datasets, local embedding and reranking, and a secret gate differentiate it from generic memory tools, but the space is crowded and value depends heavily on the user already having substantial session history — 2. cost_benefit: ~1.2 GB of model weights, continuous per-turn indexing and reranking compute, and a heavy lance/arrow dependency stack make the benefit-to-cost ratio unremarkable for light usage — 1.

claim_traceability: key README claims about redaction, the gate, the anonymous install id, and checksum verification point to specific files or commands (SECURITY.md, Cargo.toml, scripts/install.sh), which is good, but some claims (e.g., the model spontaneously calling recall) rest only on GIF demos and cannot be statically verified — 2. cross_source_corroboration: README, SECURITY.md, Cargo.toml, and CI workflows corroborate each other on trufflehog version, model names, platform matrix, and DO_NOT_TRACK, but docs/*.md and scripts/install.sh are absent, preventing full cross-checking — 2. fact_inference_separation: README separates design intent from factual description and SECURITY.md clearly states the gate stops future rows but cannot unpublish, so the boundary is reasonably clear, though some performance and effectiveness statements lack quantitative support — 2.