Learning on the Job: Continual Learning from Deployment Feedback for Frozen-Weights Agents
Abstract: AI agents encounter learning opportunities in every episode they run, and discard nearly all of them: the underlying models are frozen at deployment, so an agent that resolves a difficult request today starts from zero when it recurs tomorrow. Yet ordinary operation already produces feedback, in the form of outcome verdicts and after-the-fact corrections. We show that this feedback is a sufficient signal for continual learning when the frozen model is paired with an external memory that distils each episode into retrievable natural-language rules. On the banking domain of $τ$-bench, against a static-RAG control retrieving over the complete policy corpus, learning from the one-bit outcome verdict lifts single-trial success to 1.6$\times$ the baseline, and learning from corrections to 2.6$\times$, converting 22 of the 84 tasks the baseline never solves. The result spans the deployment spectrum, measured on Mistral Large, an open-weights model that organisations with data sovereignty requirements can self-host, and replicated on a frontier model, Claude Sonnet 5. The accumulated memory also transfers: each model, reading the store built by the other, rises above its own no-memory baseline. The harness, protocol, and data are released.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
Learning on the Job: A simple explanation
What this paper is about (the big idea)
Today’s AI helpers often “forget” what they just learned. Even if an AI solves a tricky problem today, it won’t remember that solution tomorrow because its core brain (its model weights) is locked in place after it’s deployed. This paper shows a practical way to fix that without retraining the AI: give it a shared, external memory where it can store short, clear rules from each job, then reuse them later.
Think of it like this: the AI’s brain can’t change, but it keeps a smart notebook. After each task, it writes down a simple rule about what worked (or what failed), and next time a similar problem shows up, it looks in the notebook first.
What questions the researchers asked
- Can AIs learn over time just from the everyday feedback they already get at work?
- Feedback type 1: a simple thumbs up/down (did the solution work?).
- Feedback type 2: if it failed, show the correct steps afterward (like an answer key).
- Does this “notebook” help different AIs, not just the one that wrote the notes?
- Can we measure this fairly on a hard, real-world-style benchmark and share the tools so others can repeat it?
How they tested it (in everyday terms)
They used banking tasks from a benchmark called tau-bench. Each task is a conversation with a customer and the AI has to make the right moves (using tools like a database) so the final account state matches the correct answer.
They compared three setups:
- Baseline (no memory): The AI can search a big policy library (about 700 documents) but it doesn’t remember anything between tasks. This is standard RAG (retrieval-augmented generation) — like looking things up in a library every time.
- Experience learning: After each task, the AI only gets a thumbs up/down. It must write its own short lesson: what to try again next time, or what to avoid.
- Instruction learning: If the AI failed, it also gets the correct step-by-step solution afterward (once). Then it can write a precise “WHEN–THEN” rule into memory.
They used a shared memory system called Spark:
- The memory stores “insights” — short, reusable rules in plain language, like “WHEN the customer describes X, THEN do Y.”
- The AI can search this memory during future tasks.
- After a task ends, the AI adds or updates a rule based on the feedback it got.
- A safety and quality filter keeps memory clean and useful.
They ran this on two models:
- Mistral Large (an open model an organization could self-host).
- Claude Sonnet 5 (a stronger, frontier model).
Each of the 97 tasks was attempted 4 times. In the memory setups, the same notebook stayed active across those attempts, so the AI could actually learn between tries.
Key terms in simple language:
- Frozen weights: the AI’s core brain doesn’t change after deployment.
- RAG: the AI can look up documents but doesn’t remember new lessons by itself.
- External memory: a shared notebook of rules any connected AI can read.
- Passk: how often a task is solved in all k tries. Pass1 = solved on a single try. (They also looked at how often an AI “holds” a win across trials.)
What they found (the highlights)
Here are the most important results, explained simply:
- Learning from feedback really works, even without retraining the model.
- On Mistral Large:
- Baseline single-try success (pass1): about 6%.
- Experience learning (thumbs up/down): about 10% (1.6× the baseline).
- Instruction learning (plus the correct steps after failures): about 17% (2.6× the baseline).
- The instruction setup solved 22 of 84 tasks the baseline never solved at all.
- Experience learning “held” wins very well: when it solved a task once, it solved it again 88% of the time on the next try.
- On Claude Sonnet 5 (the stronger model):
- Baseline pass1: about 25%.
- Instruction learning: about 40% — a big lift even on a strong base model.
- It converted 28 of 57 “never-solved-by-baseline” tasks at least once.
- It also held wins well (about 83%).
- The AI got better over the 4 attempts when it had memory. The baseline stayed flat (no learning), but memory-based versions improved across attempts, because the notebook filled up with useful rules.
- The memory helped other AIs too (cross-model transfer).
- Mistral reading Claude’s notebook jumped to about 29% pass1 (from 6% baseline).
- Claude reading Mistral’s notebook rose to about 31% (from 25% baseline).
- In plain terms: lessons one AI learned were clear and general enough that a different AI could use them — exactly what you want for “organizational knowledge.”
Why this matters
- It’s a practical way to make AIs learn continuously on the job without expensive retraining, without the risk of “forgetting” old skills, and without needing new safety reviews every time.
- It turns everyday work feedback (thumbs up/down, or a one-time correction) into durable, shareable knowledge.
- It helps weaker and stronger models alike, and the knowledge can be shared across different models — so teams and organizations can pool what their AIs learn.
A few limits to keep in mind
- The feedback in the tests was perfectly accurate (like a reliable grader). Real-world feedback can be late or noisy.
- They tested one domain (banking) and two models; more domains and runs would strengthen the evidence.
- This mainly measures learning for recurring types of problems. It doesn’t claim the AI will generalize to brand-new problem types.
The simple takeaway
Give a deployed AI a shared notebook and let it write short, clear rules from everyday feedback. Even with its brain “frozen,” it will get better over time, remember what works, share that knowledge with other AIs, and solve many problems it couldn’t solve before — all without retraining.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The paper demonstrates promising gains from post-episode feedback and external memory, but several aspects remain untested or under-specified. The following concrete gaps could guide future research:
- Run-to-run variability is unmeasured: each condition is a single run, so variance from randomness beyond task sampling (e.g., memory growth dynamics, ordering effects) is unknown; replicate with multiple seeds and shuffled trial schedules.
- Short horizon: only four trials per task were used, preventing observation of longer-term learning curves, store growth/decay, interference, and aging; extend to dozens/hundreds of trials to study stability, compaction, and regressions over time.
- Feedback robustness not evaluated: outcome/correction signals were perfect and immediate; test tolerance to noisy, delayed, partial, or adversarial feedback, and quantify how trust-weighting and curation mitigate errors.
- Missing ablations of Spark’s lifecycle: isolate contributions of trust-weighted ranking, deduplication, synthesis, quality/safety filters, and the write-time validator by systematically disabling or varying each component.
- Experience mode not tested on the stronger model: the “experience” arm was omitted for Claude Sonnet 5; run it to assess whether more first-time successes yield larger gains and whether high retention persists.
- Why instruction retains less than experience is unexplained: investigate whether lower hold (0.65 vs 0.88) stems from over-specific rules, retrieval/trust dynamics, conflict resolution, or misapplication; test rule abstraction levels and validator strictness.
- Memory scale and usage statistics are absent: report and analyze number of insights created/enriched/pruned, average rule length/specificity, retrieval hit rate, proportion of actions gated by memory, and per-task memory usage.
- No error typology or negative-transfer analysis: quantify and categorize misapplications, conflicts with KB policy, and regressions; measure how often memory hurts competent tasks and design guardrails.
- Limited baselines: compare against alternative memory and continual-learning strategies (e.g., conversation replay/context caching, vector-RAG over past trajectories, MemGPT-style virtual memory, Reflexion-type self-feedback, PEFT/LoRA online updates).
- Retrieval sensitivity untested: baseline uses BM25 over policies and unspecified retrieval for memory; benchmark hybrid dense–sparse retrieval, re-ranking, and query reformulation for both policy and memory search.
- Generalization beyond recurring scenarios is unmeasured: evaluate transfer to unseen task types, policy variants, or compositional goals instead of repeated instances of the same task family.
- Domain and model coverage is narrow: results are on one knowledge-intensive domain (τ-banking) and two models; extend to additional domains (compliance, healthcare, logistics), smaller models, multilingual settings, and on-device deployments.
- Simulator external validity: the customer is an LLM (GPT-5.2); validate on human-in-the-loop or real operational logs to assess whether conversational variability, goal ambiguity, and escalation behaviors affect learning.
- Cost, latency, and throughput trade-offs are unreported: measure inference overheads from memory search/write/feedback, curation pipeline costs, and overall cost-benefit (e.g., annotation cost of corrections vs gains).
- Security, privacy, and multi-tenant risks untested: simulate poisoning, prompt-injection via memory contributions, cross-tenant leakage, and access-control failures; quantify safety filter efficacy and false-positive/negative rates.
- Conflict resolution with authoritative KB is not quantified: measure frequency and outcomes of memory–KB disagreements, and test policies (KB-always-wins vs negotiated resolution) on task success and safety.
- Cross-model transfer limited to read-only: study collaborative co-learning where consumers can write back, assessing convergence, interference, and potential echo-chamber effects across heterogeneous models.
- Portability invariants are not identified: analyze which rule properties (abstraction level, format, vocabulary) predict cross-model usefulness; test normalization or style-agnostic distillation to improve portability.
- Scheduling effects underexplored: despite trial-major scheduling, first-trial parity suggests weak cross-task coupling; design tasks with shared subskills to quantify cross-task knowledge sharing and interference.
- Mid-episode writes disallowed by design: explore controlled mid-episode learning (e.g., provisional cache with quarantine) to trade faster adaptation against poisoning risk.
- Feedback granularity limited to verdict/correction: evaluate richer signals (graded scores, rationales, partial traces, counterfactuals) and credit-assignment mechanisms for more sample-efficient learning.
- Metric limitations: passk collapses learning at k=4 under coupled trials; validate alternative reliability metrics (e.g., acquisition time to first-solve, area under learning curve, conditional hold/regression rates) and report per-task survival analyses.
- Lifecycle and aging under real policy drift are untested: introduce time-varying or contradictory policies to study interference, update propagation, and deprecation; benchmark curation operators under drift.
- Human curation absent: compare autonomous vs human-in-the-loop curation for precision/recall, safety, and cost; determine minimal human effort needed to match or exceed fully automated pipelines.
- Data release clarity: it is unclear whether the learned memory stores themselves are released; sharing stores would enable independent verification of transferability and qualitative analysis of rule quality.
- Ethical and governance considerations unaddressed: assess compliance implications of organizational shared memory (e.g., PII handling, right-to-be-forgotten, auditability) and provide governance protocols.
Practical Applications
Immediate Applications
These applications can be implemented now, using the paper’s frozen-weights + external memory pattern, its read-contribute-feedback workflow, and off-the-shelf LLMs with a memory server (e.g., Spark via MCP). Each item lists sectors, example tools/workflows, and key assumptions/dependencies.
- Banking and Financial Services
- Policy-driven customer support and back-office operations (e.g., disputes, fee reversals, chargebacks, card upgrades, loan servicing, KYC/AML triage)
- Sectors: Finance, Banking, Contact centers
- Tools/workflows: Memory server integrated with existing RAG; connectors to policy repositories; automatic post-episode reflection to create “WHEN–THEN” verified rules; trust-weighted retrieval; dashboards tracking passk, hold rate, conversion
- Dependencies: Repeated tasks with deterministic or evaluable outcomes; access to outcome verdicts (pass/fail) and, where available, verified corrections (e.g., resolved tickets); strong curation (safety/quality/dedup)
- Compliance assistance (apply bank policy consistently; auditability of applied rules)
- Sectors: Finance, Risk & Compliance
- Tools/workflows: “Verified Rule” store with titles/content + retrieval query; audit logs of memory usage and feedback; policy-update notifications that trigger memory synthesis/merges
- Dependencies: Policy-change signals; governance to resolve conflicting or superseded rules
- Customer Support and Service Operations
- Experience-augmented helpdesk agents that learn from accept/reject edits and escalations
- Sectors: Retail/e-commerce, Telecom, Travel, SaaS
- Tools/workflows: Integrations with CRM/helpdesk (Salesforce, Zendesk, ServiceNow); outcome verdict = customer acceptance or agent edit; correction = approved resolution template/sequence
- Dependencies: Instrumentation to capture verdicts/edits; mapping approvals to “instruction” signals; minimal PII exposure with domain-scoped memory
- IT Service Management and SRE
- Runbook optimization via post-incident lessons (storing “what worked/what failed” as retrievable rules)
- Sectors: Software/IT Ops
- Tools/workflows: CI/CD and on-call tooling feed verdicts (test pass/fail, rollback events); reflection writes concise insights; “experience search” before running risky actions
- Dependencies: Deterministic verdicts (test outcomes, health checks); guardrails to avoid poisoning memory from mid-incident speculation
- Software Engineering Assistants (non-weight updates)
- Leverage prior coding-domain evidence: accumulating fixes, test-aware refactor patterns, integration quirks
- Sectors: Software
- Tools/workflows: CI verdicts as “experience”; failing tests with known-fix PRs as “instruction”; rule packs per repo/team
- Dependencies: Precise association of tests/build verdicts with code changes; deduplication and scoping per codebase
- Insurance and Claims Operations
- Consistent claims adjudication guided by learned rules from accepted denials/approvals and post-review corrections
- Sectors: Insurance
- Tools/workflows: Claims system emits outcome verdict; post-review corrections seed “instruction”; per-product memory domains
- Dependencies: Access to policy documents and precedent decisions; curation to avoid leakage of customer-specific PII
- HR and Benefits Administration
- Policy application for leave, benefits, reimbursements that improves with verified back-office corrections
- Sectors: HR/People Ops
- Tools/workflows: HRIS integration; memory-backed SOPs; feedback loop from HR approver decisions
- Dependencies: Clear verdict signals; separation of generalizable rules from one-off exceptions
- Public Sector Casework and Citizen Services
- Permit/tax/benefit case handling with rules learned from approvals/denials and policy rulings
- Sectors: Government
- Tools/workflows: Read-only policy retrieval + memory search; “instruction” via supervisor-approved resolutions; audit trail for each retrieved rule
- Dependencies: Compliance with records retention; redaction; change management for evolving statutes
- Education Operations and Tutoring Support (non-graded content)
- Administrative helpdesks (registration, financial aid FAQs) that learn from accepted responses; tutoring assistants that recall teacher-provided corrections (rubrics, worked examples)
- Sectors: Education
- Tools/workflows: LMS integration to capture instructor corrections; experience search for specific problem patterns
- Dependencies: Guardrails to prevent hallucinated “rules” for pedagogy; prefer instruction from verified teacher content
- Internal Knowledge Management
- Cross-model, cross-team “experience search” that surfaces reusable rules across heterogeneous LLM agents
- Sectors: All enterprise
- Tools/workflows: Shared, domain-scoped memory; cross-model frozen-store consumption; trust-weighted retrieval with negative feedback
- Dependencies: Access control per memory domain; style-agnostic rule format; conflict resolution operators
- Personal Productivity and Daily Life (low risk)
- Personal assistants that remember user corrections for recurring tasks (travel preferences, bill-pay edge cases, device automations)
- Sectors: Consumer apps
- Tools/workflows: Client-side memory domain (privacy-preserving); experience search before acting; “VERIFIED RULE” tagging after user confirmation
- Dependencies: Local/on-device or encrypted memory; user consent, easy rule inspection/deletion; avoidance of over-generalization
Long-Term Applications
These require more research, safety work, scaling, or ecosystem development beyond the paper’s scope (e.g., noisy feedback, high-stakes settings, standards, large-scale governance).
- Safety-Critical Decision Support with Verified Oversight
- Clinical workflows (order sets, prior auth, coding) and triage support that learn from clinician-approved corrections
- Sectors: Healthcare
- Tools/workflows: Human-in-the-loop instruction from EHR order audits; memory rules bound to contraindications; integration with safety validators
- Dependencies: Robust noise handling and provenance; regulatory acceptance (HIPAA, device software), formal verification; liability models
- Industrial Robotics and Manufacturing
- Multi-robot/process agents sharing procedural rules distilled from failed/successful runs (setup, tolerances, recovery)
- Sectors: Robotics, Manufacturing
- Tools/workflows: Sensor-derived verdicts; instruction from validated SOPs; cross-line memory domains
- Dependencies: Reliable mapping from telemetry to verdict; verification against safety constraints; hard real-time retrieval and rule application
- Energy, Utilities, and SCADA Operations
- Outage response and switching procedures that accumulate verified, operator-approved playbooks
- Sectors: Energy, Utilities
- Tools/workflows: Incident postmortems feed instruction; conflict-aware synthesis as infrastructure evolves
- Dependencies: Cybersecurity, strict access controls; auditability; defense against stale or misapplied rules
- Financial Risk Modeling and Advisory Assistants
- Memory-augmented advisors that adapt to policy/regulatory updates and post-compliance rulings
- Sectors: Finance/Wealth/Accounting
- Tools/workflows: Automatically flag rules impacted by regulation change; memory-to-playbook compilers for advisors
- Dependencies: RegTech integrations; compliance sign-off workflows; guardrails against over-generalization
- Cross-Organization Memory Exchange and Marketplaces
- Portable, sanitized “skill packs” or verified rule bundles transferable across models and vendors
- Sectors: Platform ecosystem
- Tools/workflows: MCP-based interop; schema standards for insights; memory quality scores; licensing/attribution
- Dependencies: Anonymization guarantees; IP/licensing frameworks; cross-vendor compatibility testing; anti-degradation checks (avoid model-style artifacts)
- Memory-Driven Governance, Auditing, and Standards
- Organizational policies for memory lifecycle: decay, conflict reconciliation, retraction on policy change, and risk scoring
- Sectors: Policy/GRC, Enterprise IT
- Tools/workflows: Governance dashboards (hold/regression rates, transferability, rule age); Sox/GDPR-aligned retention and deletion
- Dependencies: Formal standards for memory artifacts; third-party audits; incident playbooks for memory poisoning
- Noise-Robust Continual Learning at Scale
- Handling late, missing, or incorrect feedback; probabilistic trust/relevance models; robust aggregation from heterogeneous signals
- Sectors: All large deployments
- Tools/workflows: Confidence-weighted retrieval; disagreement-aware curation; human-curation queues; simulation-based QA
- Dependencies: Feedback reliability models; A/B testing harnesses; red-team tests for aging/interference
- Memory-to-Weights and Weights-to-Memory Pipelines
- Curating memory into fine-tuning datasets; distilling model improvements into portable memory documents
- Sectors: Model ops/MLE
- Tools/workflows: “Memory compiler” for SFT/RLHF data; catastrophic-forgetting checks; rollback and versioning
- Dependencies: Data governance and consent; evaluation benches for reliability and retention; rollback-on-regression policies
- Generalization Beyond Recurrent Scenarios
- Transferring learned rules to novel but structurally similar tasks; compositional rule induction across domains
- Sectors: Research, Multi-domain enterprises
- Tools/workflows: Abstraction/synthesis operators; meta-rules that capture invariants; cross-task curriculum scheduling
- Dependencies: Benchmarks and metrics separating acquisition vs retention vs generalization; theoretical backing (e.g., memory-augmented MDPs)
- End-User Transparency and Control Interfaces
- UIs for inspecting, editing, and simulating the effect of retrieved rules before acting
- Sectors: Enterprise UX, Consumer apps
- Tools/workflows: “Why this rule?” provenance; sandbox simulation; single-click retraction/appeal; conflict explainers
- Dependencies: Provenance capture; human-factors research; differential privacy for shared stores
Common Assumptions and Dependencies Affecting Feasibility
- Task structure: Repetition with variation; outcomes are evaluable (binary or verifiable sequences) and tied to concrete actions.
- Signal availability: Ability to capture outcome verdicts and, optionally, verified corrections from existing systems (ticketing, CI, CRM, policy engines).
- Governance: Safety/quality/deduplication pipelines; access-scoped memory domains; trust-weighted retrieval and negative feedback handling.
- Integration: MCP-compatible memory service; tool-path integration so agents actively query memory; connectors to policy/document stores.
- Security/privacy: PII minimization, redaction, encryption; domain isolation; audit logging for regulatory contexts.
- Change management: Mechanisms to detect and retire stale or superseded rules; conflict resolution and versioning.
- Human-in-the-loop: Especially in high-stakes domains, human validation of “VERIFIED RULES” and explicit approval workflows.
- Model diversity: Cross-model portability favors style-agnostic, situational “WHEN–THEN” rules; preserve a consistent schema for transferability.
Glossary
Below is an alphabetical list of advanced domain-specific terms from the paper, each with a short definition and a verbatim example from the text.
- BM25 retrieval: A classic sparse information-retrieval ranking function used to score documents against a query. "with BM25 retrieval over the complete corpus of roughly 700 policy documents that govern the tasks: a static RAG control."
- Cluster bootstrap: A resampling method that accounts for within-cluster correlation by resampling entire clusters (here, tasks) rather than individual observations. "using a cluster bootstrap;"
- Contrastive distillation: A training technique that learns transferable knowledge by contrasting representations or behaviors, often to strip away model-specific quirks. "responds with contrastive distillation of transferable invariants"
- Conversion (floor task): In this paper’s stratified analysis, the event that a task the baseline never solves is solved at least once by a memory condition. "A memory condition converts a floor task when it solves it in at least one trial."
- Data sovereignty: The requirement that an organization’s data remain under its jurisdiction/control, often implying self-hosting and strict access boundaries. "an open-weights model that organisations with data sovereignty requirements can self-host,"
- Deterministic evaluator: An evaluation component that yields the same result for the same input every time, eliminating stochastic judgment noise. "The benchmark's deterministic evaluator instantiates both signals with perfect experimental reliability."
- Deterministic-reward benchmark: A benchmark where task rewards/outcomes are fully determined by actions, not subject to randomness or judging variance. "on a hard, deterministic-reward benchmark where continual learning is directly observable."
- Frontier model: A cutting-edge, high-performing LLM representing the current state of the art. "and replicated on a frontier model, Claude Sonnet 5."
- Frozen-weights agent: An agent built on a model whose parameters are fixed after deployment and not updated during operation. "is enough for a frozen-weights agent to learn continually."
- Ground truth: The authoritative, correct reference outcome used for evaluation. "the final database state matches a pre-computed ground truth."
- Hold rate: The probability a task that passes at trial t also passes at trial t+1; an operational measure of knowledge retention. "the hold rate, the probability that a task passed at trial passes again at "
- Markov Decision Process (MDP): A formal framework for sequential decision making under uncertainty, defined by states, actions, transition dynamics, and rewards. "Memento formalises case-based agent memory as a memory-augmented MDP~\cite{zhou2025mementofinetuningllmagents}."
- Model Context Protocol (MCP): A protocol for connecting agents/tools to model runtimes and services in a standardized way. "It runs as a standalone server that agents reach over the Model Context Protocol (MCP)~\cite{anthropic2024mcp}."
- Non-parametric memory: Knowledge stored and updated outside model parameters (weights), typically in external memory systems. "frame non-parametric memory as continual learning for LLMs"
- Open-weights model: A model whose parameters are accessible for self-hosting and inspection, as opposed to closed proprietary endpoints. "an open-weights model that organisations with data sovereignty requirements can self-host,"
- Paired contrasts: Statistical comparisons computed by pairing outcomes per the same task across conditions to reduce variance. "The paired contrasts with 95\% cluster-bootstrap intervals."
- passk: A strict reliability metric: a task counts only if the agent solves it in all k trials. "The benchmark's primary metric is pass\textasciicircum{k}:"
- Re-draw persistence: The likelihood that a success repeats purely due to re-sampling when trials are independent and no learning occurs. "for the baselines and the frozen-store consumers, whose trials are independent, it would measure re-draw persistence and is omitted."
- Retrieval-augmented generation (RAG): A method where a model retrieves external documents to ground and improve its generated answers. "The industry's current answer to supplying agents with knowledge is retrieval-augmented generation (RAG), which offers a strong but static foundation."
- Stateless evaluation: An evaluation regime where no state or memory carries over between trials, preventing inter-trial learning. "where standard stateless evaluation makes learning between trials impossible by construction."
- Static RAG: A RAG setup that does not adapt or learn from deployment feedback across episodes. "a static RAG control."
- Tau-bench (τ-bench): A benchmark suite (here, its banking domain) used to evaluate agent capabilities under tool use and policy constraints. "On the banking domain of -bench,"
- Transfer stratum: The subset of tasks used to measure cross-model transfer, defined using each consumer’s baseline failures and the producer’s successes. "For each consumer we define a transfer stratum: the tasks its own no-memory reference never solves in four trials, restricted to those the producer solved at least once during accumulation."
- Trial-major scheduling: An execution schedule where all tasks run their first trial before any second trials, spacing trials for each task. "Scheduling is trial-major: all tasks run their first trial before any task runs its second,"
- Trust-weighted retrieval: A retrieval ranking scheme that incorporates trust or feedback signals to prioritize reliable memories. "including trust-weighted retrieval and autonomous curation."
Collections
Sign up for free to add this paper to one or more collections.