AgentFly report verification

Type: agentic-system-analyses/types/agentic-system-verification.md

Verification

The reports support a bounded source-level account. I independently read the consequential producer, selector, consumer and failure branches rather than accepting the analysts' check statements. SRC-1 HEAD equals the reviewed boundary, and the source checkout is clean. No target code, tests, providers or services were executed. The supplied correction-answer files are empty; the supplied structural report-check says none. There is no structural finding to route. Form, quotation occurrence and cross-member agreement remain deterministic checks, not evidence of semantic acceptance.

Runtime and workflow

I traced the complete ordinary client, the local streaming backend and dispatch adaptations, both benchmark query loops and writers, the retrieval modules, and trainer dataset/evaluation/update/save branches. The source anchors of the runtime records support their scoped meanings:

  • RT-CMP-openai-backend, RT-CMP-direct-model-backend, RT-CMP-case-retriever and RT-CMP-tool-judge-models distinguish remote inference, embedding inference and separately trained retrieval weights. Model names do not pin parameters. The grouped components name distinct implementations and do not imply one shared invocation. Relevant SRC-1 paths are client/agent.py, client/agent_local_server.py, both CBR drivers, memory/np_memory.py, memory/parametric_memory.py, memory/train_memory_retriever.py, server/ai_crawl.py, server/image_tool.py and server/video_tool.py.
  • RT-OBJ-shared-history, RT-RTE-query-execution and RT-RTE-local-execution correctly separate current messages, model proposals and Python progression. Content-first completion, serial task execution, task-local tool results and end-of-plan replanning are implemented. Direct streaming instead suppresses text when calls exist. The outer bound does not bound the executor loop. Tool-name adaptation does not establish provider compatibility or a matching registered tool.
  • RT-RTE-terminal-execution is supported by SRC-1 server/code_agent.py and server/interpreters/subprocess_interpreter.py: the exposed terminal path selects Bash through the subprocess interpreter with confirmation disabled by the wrapper default. Python import checking is a separate method. Host environment inheritance and caller-selected workspace paths support the refusal to claim containment. String error results can receive success wording; neither that wording nor cleanup certifies successful effects or rollback.
  • RT-RTE-crawl-extraction is model-mediated selection after crawler Markdown, with a grounding request but no independent quotation check in SRC-1 server/ai_crawl.py. It is not verbatim full-page delivery.
  • RT-RTE-case-admission and RT-RTE-retriever-training correctly distinguish automatic case/pair writes from operator-started training. Results precede later admission writes; restart suppression reads question identity. Both signs of cases persist. The trainer optimizes copied outcome labels and optionally selects by AUC/F1; case reload does not refresh weights.
  • RT-BAP-task-guidance and RT-BAP-case-guidance retain the difference between interpretive prompt guidance and numerical ranking authority. Delivery alone is not demonstrated dependence or benefit.

All route implementation statuses are supported as wiring, not observations. The workflow account faithfully selects the ordinary client rather than adding the benchmark judge to it. Its parsing-error, uncaught task/tool-error, retry, cleanup and printed-delivery distinctions follow SRC-1 client/agent.py. The representative workflow can terminate before delegation; this does not invalidate the multi-step path. No workflow declaration needs a new identity.

Memory and epistemic records

I checked the objects and subroutes against their actual writers and later consumers. MEM-OBJ-dummy-memo, MEM-OBJ-memory, MEM-OBJ-query-record and MEM-OBJ-training-data are distinct artifacts of the admission route. Latest-plan cases omit rich traces and judge reasons; result files retain them but their restart reader consumes only question identity. Pair writers copy one current outcome to every retrieved case. MEM-OBJ-checkpoint is a persisted numerical output of training, not another retriever component.

MEM-RTE-embedding-examples, MEM-RTE-classifier-examples and MEM-RTE-retrieval-display accurately separate question similarity, pair-classifier scoring and standalone printing. SRC-1 memory/np_memory.py and memory/parametric_memory.py, together with the two driver formatters, establish selection before label partitioning, description-only positive displays, raw negative displays, count caps and different tokenization budgets. Unknown parametric labels receive no example section but can enter training pairs. Missing-file reload leaves the loaded pool untouched, whereas a failed parse clears it. The nonparametric CUDA initialization precedes optional import recovery. These conditions prevent interpreting fallback as universal startup resilience.

MEM-OBJ-workspace-files and MEM-RTE-workspace-read are distinct retained-file and display parts of terminal/workspace work. SRC-1 server/code_agent.py confirms text truncation, code-extension bypass and binary metadata returns. MEM-OBJ-tool-files establishes document/media persistence and path-based reuse, but its coarse location/inventory description has the local limit below.

The four epistemic objects—EPI-OBJ-model-output, EPI-OBJ-judge-result, EPI-OBJ-case-entry and EPI-OBJ-training-entry—match the answer, judgment, reduced cases and pair artifacts in the drivers. Their truth-apt content and symbolic branch metadata are not conflated. EPI-RTE-answer-check checks answer/reference semantic agreement; EPI-RTE-outcome-label consumes the normalized result for scoring and labels. This is a bounded acceptance decision, not acceptance of the retained plan or evidence of a case's marginal utility. Failure-to-incorrect behavior is present in both judges.

EPI-RTE-case-format supports non-ampliative reshaping only for selected descriptions. I checked the worked deduction against _parse_plan, _pretty_plan and build_icl_text; omitted evidence fields preclude whole-object preservation. Generation and model judging remain semantically indeterminate rather than automatically ampliative. EPI-RTE-search-import preserves links and imports unverified snippets. EPI-RTE-media-answer returns candidate interpretations without an intervening semantic check. EPI-RTE-math-result correctly distinguishes add/subtract and awaited rounding from multiply/divide's unawaited global async round call. MCP serialization consequences remain uninspected. These findings follow SRC-1 server/search_tool.py, server/serp_search.py, server/image_tool.py, server/video_tool.py and server/math_tool.py.

The three claim records, EPI-CLM-experience-learning, EPI-CLM-weight-updates and EPI-CLM-automated-retraining, faithfully attribute SRC-1 README.md. The comparison preserves the LLM/retriever distinction, the outcome-label proxy and the unsupported scheduling/deployment claim. Neither committed corpora nor README performance statements establish observed generation or causal gains. The epistemic ledger separates checking, disposition, retention, selection and adaptation; its local lack of accepted-plan integration does not claim a system-complete negative.

Relations and reconciliation

Every declared Part of: relation was assessed for containment, not merely matching kinds. Case/result/pair objects, answer/judgment objects and their check/label/selection subroutes fit the case-admission container. Checkpoints fit training; workspace objects and requested reads fit terminal/workspace work. Formatting spans admission and training and therefore appropriately names overlap rather than one parent. The standalone retrieval display, side files and returning search/media/math routes have distinct referents. Empty Claims/Absences headings do not assert that no other claims or behaviors exist.

The reconciliation amendment identifies the same training-pair artifact in memory and epistemic, with the writer loop as identity evidence. Supersession does not strengthen its outcome provenance. The combined epistemic case object remains valid alongside two schema-specific memory parts; no split is needed. Exceptional history carryover, README's explicit --use_plan, stale-pool deletion behavior and partial-write recovery are compatible qualifications, not unresolved contradictions. Source branches independently support those dispositions. No correction answers or unresolved conflict requires further routing.

Consequential omission search and stopping decision

Search selection came from the frozen tracked tree, all client entry points, tool registrations and dependencies linking case/pair producers to later consumers. I searched SRC-1 client/memory/server Python for training calls, checkpoint names, case-bank writes, reloads, judges and alternate selectors. This found no additional shipped training scheduler or reason-reading planner path that would invalidate the scoped central conclusions. The standalone CLI and unused topk_select helper do not silently close that loop.

I also inspected alternate page-return tools and spreadsheet/document dispatch to test whether the query-aware extractor represented every acquisition route or whether case-bank storage represented every retained output. SRC-1 server/craw_page.py returns crawler Markdown directly; server/jina_fetch_tool.py returns service text after transport checks; server/excel_tool.py converts spreadsheets and can write an XLSX side file. These alternatives do not establish an independent truth test or automatic case admission. The epistemic report already marks these acquisition alternatives unassessed and avoids system-complete source-fidelity negatives. They leave the central planner, answer-check and case-reuse conclusions intact. The extra spreadsheet artifact and document-file placement require only the local inventory limit below.

Further omission expansion stopped because the selected challenges have supported dispositions, no material unsupported conclusion remains undisposed, and the reports do not claim exhaustive tool transformations, corpus genealogy, parameter contents or operational benefit. External converter/provider fidelity, full corpus quality and deployed interpreter isolation cannot be compared from this inspection. Available uninspected material is not evidenced absence.

Blockers

none

Limits

  • MEM-OBJ-tool-files is a partial side-file inventory, not a reliable directory or cleanup map. Its phrase placing document outputs under a cache directory is too coarse: SRC-1 server/documents_tool.py constructs DOCX/Chunkr outputs from basenames in the working directory and PPTX images beside the supplied source stem; its cache directory governs unzip output. SRC-1 server/excel_tool.py also writes an XLS-to-XLSX sibling file not named in this inventory. Withhold complete artifact-location, withdrawal and cleanup comparisons. Local filesystem persistence and caller-requested reuse remain supported, and neither the memory nor epistemic report claims exhaustive side-file coverage or automatic case-bank ingestion. This local inventory defect does not change the central memory mechanism or warrant a system-level rejection.

    md_path = f"{os.path.basename(document_path)}.md" docx_to_markdown(document_path, md_path) --- server/documents_tool.py out_path = document_path.rsplit(".", 1)[0] + ".xlsx" XLS2XLSX(document_path).to_xlsx(out_path) --- server/excel_tool.py