{ "schema_version": 1, "builder_plan": { "scenario": "A support or data assistant repeats work across related customer requests.", "change": "Try the paper's memory change in a replay of past tasks, with separate memory per customer.", "baseline": "Your current memory pipeline plus a no-memory control using the same agent.", "steps": [ "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.", "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.", "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.", "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test." ], "measure": "Task success, stale memories, retrieval misses, response latency, and all memory maintenance costs.", "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation." }, "builder_review": null, "arxiv_id": "2610.11578", "title": "Chronos Enables Code Agents to Reason over Software Evolution", "summary": "Replaces flat semantic retrieval (or no retrieval) over repository history with structured experience cards distilled from merged pull requests, connected in a typed relation graph and consumed by a multi-agent patch-generation-and-selection workflow. Costs include offline indexing of PR history, an embedding/search service plus graph expansion at test time, and roughly triple the LLM calls per task from the two candidate agents and the selection step. It can fail where PR history is thin or poorly written, where retrieved cards are misleading rather than useful, and where the added agent steps amplify cost without resolving extra tasks on a given codebase.", "rationale": "The gains are consistent across six backbones and three benchmarks and the technique is implementable with API access plus modest indexing, but its value depends on the quality and volume of the target repository's PR history, so it warrants a workload-specific pilot before production adoption.", "technique": "PR-history experience graph for code agents", "family": "memoria_e_contexto", "recommendation": "testar", "published": "2026-10-08", "as_of": "2026-10-18", "editorial_status": "indexed", "source_url": "https://arxiv.org/abs/2610.11578", "independent_implementations": 1, "total_implementations": 2, "stars": 14, "citations": 0, "claims": [ { "claim_id": "claim-01", "statement": "Replaces flat semantic retrieval (or no retrieval) over repository history with structured experience cards distilled from merged pull requests, connected in a typed relation graph and consumed by a multi-agent patch-generation-and-selection workflow. Costs include offline indexing of PR history, an embedding/search service plus graph expansion at test time, and roughly triple the LLM calls per task from the two candidate agents and the selection step. It can fail where PR history is thin or poorly written, where retrieved cards are misleading rather than useful, and where the added agent steps amplify cost without resolving extra tasks on a given codebase.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2610.11578", "source_page": null, "source_excerpt": "" }, { "claim_id": "claim-02", "statement": "Raises SWE-Agent mean resolution on SWE-Bench Verified from 69.2% to 72.9% (peak 79.8% with MiniMax M2.5), and from 48.3% to 51.7% on SWE-Bench Pro; graph-grounded retrieval increases mean useful retrieved cards from 1.24 to 2.87 versus flat semantic search.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2610.11578", "source_page": null, "source_excerpt": "" } ], "exposure_map": [ { "dimension": "quality", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compute", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "latency", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "operations", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compatibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "security", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "data_and_training", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "reproducibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" } ], "risks": [], "minimum_test": [], "open_questions": [], "independent_tests": [], "lab_reproductions": [], "report_available": false, "validation_tier": "unknown", "evidence_tier": "unknown", "infrastructure_basis": "unknown", "equations": [], "equations_status": "not_fetched", "core_kind": "", "equations_fetched_at": "", "equations_source_url": "", "equations_source_sha256": "", "exposures_reviewed_at": "", "exposures_source_sha256": "" }