Agentic Recommender Systems: How Harness Engineering Changes Personalization

The next recommender system will not only answer, “Which item should be ranked first?” It will decide whether to ask, retrieve, compare, explain, remember, or—under explicit authority—act.

For twenty years, recommendation engineering has optimized a mostly one-way contract: observe behavior, retrieve candidates, score them, display a list, and learn from clicks, watches, purchases, skips, or dwell time. Agentic AI changes that contract into a loop. The user can state a goal in language, correct the system, negotiate constraints, introduce a photo or document, and ask the system to act across tools.

The ranking stack does not disappear. The production pattern emerging from research and deployed systems is a hybrid architecture:

Fast recommenders retrieve and score the world. An agent interprets the goal and orchestrates the journey. A harness controls what the agent may know, say, remember, and do.

Putting an LLM in front of a catalog creates a conversational demo. Reliability comes from the surrounding harness: candidate tools, context assembly, policy, memory controls, evaluators, traces, approval gates, replay, and staged rollout.

This guide explains the architectural shift, examines real production evidence and research prototypes, and provides a concrete implementation and evaluation plan. The source review is current through August 15, 2026.

The three recommender paradigms are different

“Generative recommender” and “agentic recommender” are often used as if they mean the same thing. They do not.

A classical ranker can be written as a scoring function:

score = f(user, item, request_context)

A generative recommender learns a distribution over the next item or interaction:

P(next_item | interaction_history, request_context)

An agentic recommender learns or implements a policy over a wider action space:

next_action = decision_policy(
  user_goal,
  observations,
  session_state,
  governed_memory,
  available_tools,
  governance_policy,
  budget
)

next_action may be ask, retrieve, filter, compare, recommend, explain, save, add_to_cart, book, buy, or escalate. The critical change is not natural-language output. It is closed-loop decision-making under constraints.

Two boundaries follow:

1. An LLM that writes a friendly explanation for a fixed ranked list is generative, but not necessarily agentic.
2. An agentic system should not ask an LLM to score every item in a million-item catalog. It should use specialized retrieval and ranking tools, then reason over a bounded, grounded candidate set.

Recent surveys describe a similar progression from feature-based systems to generative and agentic paradigms, and divide agentic work into recommendation-oriented, interaction-oriented, and simulation-oriented systems. See the foundation-model recommender survey, the LLM-agent recommender survey, and the agentic recommender perspective.

Two branches of agentic recommendation

The field now has two related but distinct branches:

1. Serving-time agents help a person express preferences, compare candidates, and complete a task. τ-Rec tests this branch with reveal-tagged preference elicitation, verifiable catalog predicates, and pass^k. Its best reported configuration falls from roughly 57% at pass^1 to 38% at pass^4, a useful warning that one successful trajectory is not evidence of repeated reliability.
2. Improvement-time agents operate behind the recommender. RecHarness separates bandit-selected optimization directions from LLM-generated hypotheses and reports a seven-day online experiment. SR-Agent uses simulation, structured diagnosis, bounded post-ranking edits, staged rewards, and rollback, and reports a one-month online A/B test on Kuaishou. These are early preprints, but they show the harness itself becoming a recommender optimization surface.

RecRM-Bench connects both branches by evaluating more than final clicks: instruction following, factual consistency, query-item relevance, and fine-grained behavior prediction. The two branches should share experience records and release gates, but never share unchecked write authority.

What changes when a recommender becomes agentic

1. Preference prediction becomes preference elicitation

Traditional recommenders infer intent from behavioral exhaust; agents can ask. “Show me running shoes” is underspecified, while “road shoes for a first marathon, under $140, wide toe box, overpronation” is a decision problem. The system must reduce uncertainty without turning every request into an interview. Measure preference information gained per necessary turn, not conversation length.

2. The user profile becomes scoped, revisable memory

A recommender profile is usually an inferred latent representation. Agentic systems add explicit statements such as “I prefer aisle seats” or “do not recommend this creator again.” Each preference can be durable or session-only, explicit or inferred, personal or task-specific, current or contradicted, and permitted for one purpose but prohibited for another.

“Likes spicy food” should not override “cooking for a toddler tonight.” “Usually flies economy” should not silently defeat a business-trip policy that allows premium economy. A production system must preserve provenance and scope instead of flattening every observation into a permanent profile.

Treat memory updates as proposals, not incidental chat side effects. Store the source, confidence, purpose, retention policy, consent state, and contradiction links. The promotion-aware memory model shows why recall and promotion need separate controls.

3. Ranking one item becomes planning a solution

Dinner plans, trips, room designs, and learning paths are sets and sequences with compatibility and budget constraints. A planner can query rankers, inventory, compatibility graphs, policy, price history, or availability, then revise when a constraint fails.

4. Persuasion becomes evidence-bound explanation

Natural language makes recommendations easier to understand—and easier to overstate. An explanation is not evidence. Every factual claim should resolve to catalog data, a review aggregate, an explicit preference, or another admissible reference; sponsored and organic influence must remain distinguishable. Google’s REGEN dataset usefully evaluates recommendations with critiques and narratives, but it does not make free-form production explanations automatically factual.

5. A recommendation becomes a possible external effect

Once a system can add items, reorder, reserve, book, or buy, a relevance error becomes an action error.

That changes the safety boundary. “Recommend these headphones” is read-only. “Add the two I viewed yesterday” is a reversible cart mutation. “Buy them when the price falls below $200” creates durable delegated authority. “Purchase now from an external merchant” crosses identity, payment, and third-party boundaries.

The action must be classified before the model is asked to execute it. A recommender contract should use the native ActionRisk vector: effect (none, local_state, external_state, physical_world), authority (agent, service, user_delegated, human_approved), reversibility, interaction boundary, and data scope. Confirmation point, expiry, and spend or quantity caps are additional obligations. These dimensions are not a single monotonic risk ladder.

ContextOS derives a legacy enforcement projection from that vector when a v1 consumer requires one, using the canonical ApprovalMode values: read_only, local_write, network, delegated, and destructive. An external price lookup crosses a network boundary without delegated authority; a 30-day “buy below ₹10,000” instruction needs user_delegated authority; the eventual financial commit may be irreversible. The model may propose an action, but deterministic policy evaluates the vector, emits obligations, and only then projects a compatibility mode.

6. CTR becomes one metric in a multi-objective scorecard

An agent can increase immediate engagement by asking leading questions, producing confident copy, hiding trade-offs, or repeatedly steering toward familiar items. Those behaviors may harm trust, diversity, provider health, or long-term satisfaction.

Agentic recommenders need at least six measurement planes:

No single scalar should erase hard constraints. Policy, safety, and factual validity are floors. Utility, latency, and economics can be optimized inside those floors.

The production architecture: three planes, two speeds

The production shape is a ranking plane, a decision-orchestration plane, and a governed action plane. “Agent as control plane” is tempting shorthand, but misleading: the agent is often on the request hot path and must not own governance.

The ranking plane stays specialized

The retrieval and ranking path continues to search a changing corpus, enforce eligibility, produce candidates at low latency, score behavior at high throughput, preserve exploration and marketplace constraints, and return stable item IDs with feature evidence.

Meta’s HSTU work reframes recommendation as sequential transduction and shows that recommendation foundation models can scale with compute. The published paper reports a 1.5-trillion-parameter generative recommender, a 12.4% improvement in online A/B-test metrics, and deployment across multiple surfaces, while also reporting public-dataset and efficiency gains. That is compelling evidence for foundation-scale recommendation—but it is still a recommendation model and serving system, not by itself an agent with tools and authority. See Actions Speak Louder than Words.

Meta’s newer SilverTorch work makes the complementary infrastructure point. It collapses retrieval operations—similarity search, eligibility filtering, reranking, and engagement scoring—into a model-based GPU path. Meta reports up to 23.7× throughput and 20.9× compute-cost efficiency versus the compared systems, with adoption across its apps. Those are vendor-reported maxima, but they demonstrate why the high-volume retrieval layer remains a specialized engineering problem. See SilverTorch: Index as Model.

The agent handles the long tail of intent

Invoke the agent path when a targeted question has high expected value, constraints span domains, the user wants comparison or explanation, fresh observations are required, the task is a bundle or sequence, or a reversible or delegated action is requested.

This keeps cost and latency proportional to task complexity. A home feed refresh does not need a multi-turn reasoning loop. A request to “plan a low-sodium week of dinners for four under $120, reuse ingredients, and build the cart from what is actually in stock” probably does.

The harness owns the boundary

The agent is the probabilistic reasoner. The harness compiles admissible context, bounds tools and budgets, validates candidates and claims, controls memory and authority, records evidence, gates releases, and replays controls without repeating effects.

This follows the broader harness-engineering lesson reported by OpenAI: when agents write and operate complex systems, the engineering work shifts toward environments, intent specifications, and feedback loops. Anthropic makes the same evaluation boundary explicit: evaluating an agent means evaluating the model and harness together. See OpenAI’s Harness engineering and Anthropic’s Demystifying evals for AI agents.

What real systems show—and what they do not

Production examples now cover every layer of the transition, from foundation recommenders to conversational steering and delegated purchase. They should be read carefully: product adoption, benchmark gains, online experiments, and causal business impact are different forms of evidence.

The pattern across deployments

Netflix shows a shared preference model becoming substrate for specialized downstream tasks—not the final experience. Spotify turns a ranked stream into a steerable mixed-initiative session. Amazon widens the action envelope from “recommend” to “monitor,” “cart,” “reorder,” and external purchase. Instacart shows why those actions need live domain infrastructure: catalog, local availability, price, quantities, and cart mutation.

The evidence supports an architectural sequence, not one universal lift: foundation preference learning → interactive steering → grounded tools → governed action. An embedding may suggest a preference; the current request can override it. Product adoption and conversion associations remain weaker evidence than randomized experiments. Once a recommender can transact, identity, authority, freshness, confirmation, idempotency, recovery, and exposure lineage become part of recommender engineering.

The harness for an agentic recommender

A useful production harness has nine coupled surfaces.

1. Intent and outcome contract

Do not begin with a universal prompt. Begin with a bounded task contract.

intent: commerce.plan_bundle
goal: "Build a compatible work-from-home setup"
action_risk:
  effect: external_state
  authority: human_approved
  reversibility: reversible
  interaction: api
  data_scope: CONFIDENTIAL
confirmation: before_commit
allowed_actions:
  - catalog.search
  - catalog.compare
  - inventory.check
  - cart.create_draft
forbidden_actions:
  - checkout.submit
hard_constraints:
  budget_usd: 1200
  delivery_by: "user_supplied_deadline"
success:
  - all_items_compatible
  - all_items_in_stock
  - total_within_budget
  - claims_grounded
  - draft_cart_confirmed_by_user

The contract should name the job, allowed effects, completion evidence, hard constraints, and failure behavior. “Recommend products” is too vague to evaluate or govern.

2. Context compiler

Compile context per request rather than dumping the entire user profile and catalog into the prompt. The context should contain:

• the current goal and explicit constraints;
• session turns needed to resolve references;
• a small set of relevant, consented preference memories;
• candidate and catalog evidence;
• policy and sponsorship disclosures;
• available tools and their schemas;
• budgets and stopping conditions.

Every included item needs provenance and a reason for admission. Every omitted high-value context class should be observable. This is the role of agentic context engineering and the Context Pack compiler.

3. Typed recommendation tools

Do not let the agent browse an unbounded internal database or invent catalog entities. Expose narrow tools:

type CandidateQuery = {
  query: string
  userEmbeddingRef?: string
  hardFilters: Record<string, string | number | boolean>
  objective: "relevance" | "diversity" | "value" | "compatibility"
  limit: number
}
 
type CandidateSet = {
  candidateSetId: string
  rankerVersion: string
  catalogSnapshot: string
  items: Array<{
    itemId: string
    score: number
    retrievalPosition: number
    policyPropensity?: number
    eligible: boolean
    eligibilityReasons: string[]
    attributes: Record<string, string | number | boolean>
    evidenceRefs: string[]
  }>
}

The tool returns item IDs, eligibility, normalized attributes, and evidence references—not marketing prose for the model to repeat. Separate tools should handle inventory, price, compatibility, review aggregation, and actions. Side-effecting tools require idempotency keys, an effective ActionRisk vector, policy obligations, and any legacy approval-mode projection.

Tool descriptions are not policy. Product descriptions, reviews, and merchant content are untrusted inputs and may contain prompt injection. Authorization, data filtering, and action eligibility belong in the Tool Gateway, outside model instructions. The Adapter Mesh defines that boundary.

4. Bounded planner, executor, and critic

The decision loop should make uncertainty and verification visible:

async function runRecommendation(task: Task, run: RunContext) {
  const compiled = await contextCompiler.compile(task, run)
  let state = initializeState(compiled)
 
  while (!state.done && state.stepCount < run.budget.maxSteps) {
    const proposed = await planner.next(state)
    const verified = await critic.verify(proposed, state)
 
    if (verified.verdict === "ask_user") {
      await sessionStore.checkpoint(state, verified)
      return awaitUserEnvelope(run.sessionId, verified.question)
    }
    if (verified.verdict === "deny") return finalizeDenied(state, verified)
    if (verified.verdict === "escalate") return finalizeEscalated(state, verified)
 
    const observation = await executor.execute(verified.step, {
      toolGateway,
      principal: run.principal,
      actionRisk: verified.actionRiskEffective,
      obligations: verified.obligations,
      approvalMode: verified.approvalModeProjection,
      policyDecisionId: verified.policyDecisionId,
      idempotencyKey: verified.idempotencyKey,
    })
 
    state = critic.scoreAndAdvance(state, observation)
    await sessionStore.checkpoint(state, verified, observation)
  }
 
  return consolidateDecisionRecord(state)
}

The model proposes. Deterministic validators confirm that:

• every recommended item exists in the returned candidate set;
• all hard filters are satisfied;
• price and inventory snapshots are fresh enough;
• bundle compatibility checks passed;
• every factual sentence has an evidence reference;
• sponsored items carry required disclosures;
• action scope, effective risk vector, obligations, and compatibility projection match policy;
• the loop remains within tool, token, time, and cost budgets.

5. Governed memory

Separate at least four stores:

Never promote a high-impact attribute merely because the model inferred it from one conversation. Sensitive attributes need stronger purpose and consent controls. Corrections must propagate to both retrieval features and agent memory, or the two layers will contradict each other.

6. Policy, authority, and user control

The agent should reveal the boundary between suggestion and action. The interface must make it obvious when the system is:

• showing candidates;
• using stored preferences;
• changing a saved list or cart;
• creating a monitoring rule;
• preparing a purchase;
• executing an irreversible external action.

Authority should narrow across delegation, not expand. A “buy below $75” instruction needs scope, merchant eligibility, quantity, expiration, total-spend cap, substitution policy, and a revocation path. The approval record should bind to the exact planned action, not to a vague earlier conversation.

7. Learning-data contract

The agent changes the exposure policy. It may retrieve 1,000 items, receive 100 eligible candidates, reason over 12, render three, and act on one. Collapsing those stages into “shown” contaminates the next ranker’s labels.

Record the funnel explicitly:

The resulting event needs candidate_set_id, ranker scores and version, original position, eligibility decisions, agent reorder or suppression reason, rendered position, viewability, exploration probability or policy propensity, and downstream outcome. Never train on agent_considered as if it were an impression. Preserve the original serving propensity when doing counterfactual or off-policy evaluation.

{
  "candidate_set_id": "cand_7f2",
  "item_id": "hotel_204",
  "ranker": { "version": "hotel_ranker@18", "score": 0.81, "position": 4 },
  "funnel": { "retrieved": true, "eligible": true, "agent_considered": true, "rendered": false, "user_seen": false },
  "agent_decision": { "reason": "suppressed_cancellation_mismatch" },
  "policy_propensity": 0.08
}

8. Decision records, privacy, and three replay modes

Store a privacy-minimized decision path rather than only the final message—or every raw prompt:

run/
  intent-contract.json
  compiled-context-manifest.json    # hashes, types, admission reasons
  memory-manifest.json              # scoped refs, not raw profile text
  candidate-exposure-events.jsonl
  plan-and-verdicts.jsonl
  tool-transcript-manifest.json      # redacted refs + content hashes
  policy-decisions.jsonl
  approvals.jsonl
  evaluator-scorecard.json
  decision-record.json

Encrypt sensitive payloads separately, use content-addressed references, restrict access by purpose, and set retention and deletion policies by data class. Preserve raw context or tool output only when the audit purpose justifies it; a resolvable hash and redacted manifest are often sufficient.

“Replay” then has three explicit meanings:

Externally hosted and stochastic models generally cannot promise byte-identical re-generation. In this post, byte-identical replay applies only to reconstruction of the stored record and deterministic controls. Counterfactual success means the candidate meets declared semantic and policy thresholds, not that it emits identical tokens or a matching tool sequence. A purchase replay that purchases again is a second incident.

Define replay_success by mode: hash-complete reconstruction, identical deterministic verdicts and state transitions, or a counterfactual scorecard delta within bounds. Pin the pack, policy, catalog snapshot, feature definitions, tool versions, and evaluator rubric closely enough to attribute differences.

The canonical DecisionRecord and evaluation and observability contracts provide a concrete implementation shape.

9. Evaluation and staged improvement

The harness itself is the optimization target. A model upgrade, prompt edit, memory-recall rule, retrieval change, new tool, or evaluator update can all alter behavior.

Maintain separate datasets:

• development set: representative cases for rapid debugging;
• search set: examples used for prompt, routing, retrieval, and harness tuning;
• release set: held-out regression gate;
• simulation set: rare failures, contradictory constraints, outages, stale inventory, and adversarial content;
• shadow-live set: sampled production traffic with no user-facing action.

Do not tune against the release set. Do not allow an LLM judge to be the only grader. Combine deterministic assertions, retrieval metrics, domain simulators, trained or rubric-based graders, human review, and controlled online experiments.

Worked trace: a Delhi-to-Tokyo family trip

Consider an illustrative request:

“Plan a family trip from Delhi to Tokyo in September, with sensible flight timings, a walkable hotel, and flexible cancellation.”

The IDs and scores below are synthetic, but the control boundaries are production-shaped.

1. Intake and clarification

The system binds the request to travel.plan_bundle. “Family,” “September,” “sensible,” and “walkable” are not executable constraints. Exact dates and traveler ages affect availability, fare rules, room occupancy, and price, so the agent asks one high-information question:

“Which September dates, how many travelers, and what are the children’s ages? If you have a total budget, include it.”

The user answers: September 14–21, two adults and one eight-year-old, total budget ₹450,000. This answer is checkpointed into the session before any new search.

2. Compile preferences without flattening them

The compiler includes only the relevant preference references and records why the business-hotel inference was rejected. Current-trip intent beats a weak durable inference.

3. Let the existing rankers search at scale

The flight ranker flight_ranker@41 returns candidate set flt_cand_91: 420 retrieved itineraries, 46 eligible after schedule, occupancy, and policy filters, and 15 admitted to agent context. The hotel ranker hotel_ranker@18 returns htl_cand_62: 630 properties, 52 eligible, and 12 admitted. Both sets retain original scores, positions, filter reasons, and serving propensities.

The agent never free-generates an airline, hotel, fare, or rate plan. It invokes tools over those bounded IDs:

The final response renders two bundles and explains each trade-off using fare-rule, rate-plan, location, and price evidence. Twelve internally considered hotels are not logged as user exposures; only the two rendered hotels become render events, and only viewable cards can become user_seen events.

4. Separate draft creation from booking authority

Creating a draft trip is { effect: local_state, authority: human_approved, reversibility: reversible, interaction: api, data_scope: CONFIDENTIAL } and requires confirmation before the write. Live supplier reads separately cross the network boundary. Booking would change the vector to external_state and require a fresh price and inventory check, traveler identity, explicit confirmation against the exact itinerary and total, and the policy-selected approval path. A standing “book if the total falls below ₹400,000 for the next 30 days” instruction would additionally require user_delegated authority, expiry, spend cap, supplier scope, and revocation.

5. Emit a decision and learning record

{
  "decision_id": "travel.plan_bundle.present",
  "candidate_sets": [
    { "id": "flt_cand_91", "ranker": "flight_ranker@41", "retrieved": 420, "eligible": 46, "agent_considered": 15 },
    { "id": "htl_cand_62", "ranker": "hotel_ranker@18", "retrieved": 630, "eligible": 52, "agent_considered": 12 }
  ],
  "constraints": { "hard_satisfied": 7, "hard_total": 7, "overrides": ["pref_business_hotel"] },
  "rendered": ["bundle_a", "bundle_b"],
  "evidence_refs": ["fare_rule:fr_118", "rate_plan:rp_204", "geo:walk_52", "quote:q_771"],
  "action_risk": { "effect": "none", "authority": "agent", "reversibility": "read_only", "interaction": "api", "data_scope": "CONFIDENTIAL" },
  "approval": null,
  "replay": { "forensic_manifest": "sha256:...", "control_fixture": "replay:travel_091" },
  "learning_events_ref": "exposure:travel_091"
}

If the user selects bundle B, creates a draft, or rejects both because the arrival time is too late, each event updates the funnel without rewriting which candidates were actually exposed. That separation makes the decision auditable and keeps the next ranker’s training data causally legible.

A release-grade evaluation scorecard

Start with hard gates, then optimize the rest. This illustrative contract makes sample size, confidence, coverage, and cohort slices part of the result:

measurement:
  confidence_level: 0.95
  min_trials_per_release: 10000
  min_trials_per_required_slice: 500
  required_slices: [intent, new_user, returning_user, locale, device, risk_vector]
  trace_coverage: ">= 0.999"
 
hard_gates:
  catalog_item_validity:
    observed_rate: 1.000
    checked_population: rendered_items
  restricted_action_without_approval:
    observed_violations: 0
    upper_confidence_bound: "<= 0.0003"
  prohibited_attribute_use:
    observed_violations: 0
    coverage: "all required slices"
  evidence_coverage_for_factual_claims:
    lower_confidence_bound: ">= 0.995"
 
quality:
  constraint_satisfaction_delta: ">= -tolerance"
  ndcg_at_10_delta: ">= -tolerance"
  pass_k_by_intent: "report k = 1, 2, 4"
  unnecessary_question_rate: "<= registered target"
 
operations:
  p95_interactive_latency_ms: "<= target"
  cost_per_accepted_outcome: "<= budget"
  forensic_reconstruction_success: 1.000
  deterministic_control_replay_success: 1.000
  counterfactual_scorecard_delta: "within registered bounds"

“Zero observed violations” is not “zero risk.” With no failures, the rough 95% upper bound is about 3 / n; ten clean examples say almost nothing. Report denominators, confidence intervals, missing-trace coverage, and the weakest required slice. Pre-register tolerances before looking at the candidate result.

Evaluate the path, not only the final list

Two agents can recommend the same items for very different reasons. One used the stated budget and fresh inventory. The other ignored the budget, hallucinated availability, and got lucky. A final-list metric treats them as equal.

Trace graders should evaluate:

1. Was the right uncertainty identified?
2. Was a question necessary, and was it the cheapest useful question?
3. Were the right retrieval and verification tools selected?
4. Did the agent remain inside the candidate and authority boundaries?
5. Did evidence support both selection and explanation?
6. Did the final action match the user-confirmed plan?

Use agent simulation, but distrust it correctly

Agent4Rec equips simulated users with profile, memory, and action modules; RecMind uses planning and tools for zero-shot recommendation. Both are useful research directions. Agent4Rec’s authors explicitly study where simulated behavior aligns with and deviates from real behavior. See Agent4Rec and RecMind.

Use simulators to generate long-tail journeys, attack the conversation policy, compare clarification strategies, and reproduce known failure shapes. Do not use them as proof of human satisfaction, conversion, fairness, or long-term welfare. A simulator inherits the language model’s stereotypes, verbosity, and preference priors. Calibrate it against real traces and report the divergence.

Preserve long-term and ecosystem outcomes

Optimizing only for the current user action can create filter bubbles, supplier concentration, addictive engagement, or short-term persuasion that damages trust. Recommenders mediate an ecosystem of users, creators, merchants, advertisers, and the platform. Google researchers argue that explicitly modeling these coupled incentives is necessary for ecosystem health; see Modeling Recommender Ecosystems.

Keep long-horizon holdouts and provider-side metrics. Measure concentration, exposure, diversity, complaint and regret signals, repeat satisfaction, and whether the agent’s explanations or actions alter the feedback distribution used for future training.

Failure modes specific to agentic recommendation

The economics: route reasoning where it earns its keep

Agentic recommendation adds model tokens, tool calls, network latency, evaluator cost, and operational complexity. The business case should be measured per accepted outcome, not per chat.

incremental_value_per_session
  = conversion_or_retention_uplift
  + reduced_search_effort
  + basket_or_task_value
  - inference_cost
  - tool_and_data_cost
  - expected_failure_cost
  - human_review_cost

Use three lanes:

1. Fast lane: ordinary feed and known-item search use the existing ranker.
2. Assist lane: the agent interprets, asks, compares, and explains but cannot mutate external state.
3. Action lane: the agent uses reversible or delegated tools under explicit policy and approval.

Cache stable catalog evidence, not personalized decisions with hidden state. Use a small model for classification, query rewriting, and rubric checks when the scorecard permits. Reserve stronger reasoning for constraint-heavy steps. Stop once the outcome contract is satisfied; endless “helpfulness” is a cost and safety bug.

A 90-day implementation plan

Days 1–15: establish the non-agent baseline

• Select one high-value, constraint-rich intent—not the whole recommendation surface.
• Record the current retrieval, ranking, latency, diversity, conversion, correction, and satisfaction baselines.
• Create a golden set from real journeys, operator corrections, and hard policy cases.
• Normalize item IDs, catalog snapshots, availability, price, and evidence references.
• Define the task contract and the actions that are explicitly out of scope.

Exit gate: the team can forensically reconstruct the current system’s candidate, eligibility, exposure, and outcome path.

Days 16–30: ship a grounded assist lane

• Add natural-language constraint extraction and one targeted clarification policy.
• Expose read-only candidate, inventory, comparison, and evidence tools.
• Generate recommendations only from returned candidate IDs.
• Require evidence for factual explanations.
• Log privacy-minimized context and transcript manifests, stage-specific exposure events, and scorecards.

Exit gate: held-out relevance does not regress beyond tolerance; catalog validity and prohibited-attribute gates are perfect.

Days 31–50: add the bounded decision loop

• Introduce Planner → Critic.verify → Executor → Critic.score.
• Add tool, token, latency, and replanning budgets.
• Test contradictory constraints, no-result cases, tool timeouts, stale inventory, injected product text, and deterministic control replay.
• Calibrate graders against domain experts and disagreement examples.
• Run the agent in shadow beside the production recommender.

Exit gate: the shadow agent recovers or escalates safely on the long-tail suite and produces complete replay artifacts.

Days 51–70: introduce memory and reversible actions

• Separate working, session, durable explicit, and inferred preference stores.
• Add consent, provenance, expiry, contradiction, correction, and deletion paths.
• Enable only reversible actions such as saved-list or draft-cart creation.
• Bind every action to an idempotency key, native ActionRisk, policy obligations, and legacy approval-mode projection where required.
• Run internal and low-risk canaries.

Exit gate: no action escapes its authority; memory corrections change both agent context and retrieval behavior.

Days 71–90: canary, compare, and prepare rollback

• Progress from shadow to internal, low-risk, and monitored cohorts.
• Run controlled online experiments with stratification by intent and cohort.
• Track long-term and provider-side metrics, not only immediate conversion.
• Rehearse the kill switch, forensic reconstruction, deterministic control replay, and a sandboxed counterfactual evaluation.
• Promote only changes that pass hard gates and improve the Pareto frontier across utility, latency, and economics.

Exit gate: the team can disable the agent path without disabling core recommendations, and can reconstruct any action from its decision record.

The deepest design insight

The recommender model is no longer the whole recommender system. Features, embeddings, retrieval, rankers, experiments, and feedback data remain essential, while the harness becomes a second optimization surface over context, tools, memory, policy, evaluation, and learning-data lineage.

The winning architecture allocates autonomy precisely:

• prediction where prediction is enough;
• language where language reduces friction;
• planning where the task is genuinely compositional;
• tools where external truth is required;
• memory where continuity helps and consent permits;
• approval where consequences increase;
• deterministic controls wherever a probabilistic model should not be trusted to police itself.

Primary sources and evidence notes

• Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations — Meta HSTU architecture, public benchmarks, online experiment, scale, and deployment claims.
• Foundation Model for Personalized Recommendation — Netflix interaction tokenization, long-history modeling, cold start, embeddings, and downstream uses.
• SilverTorch: Index as Model — Meta’s model-based retrieval architecture and reported efficiency.
• Spotify DJ Now Takes Requests — voice steering, market availability, personalization inputs, and engagement context.
• How Amazon is using generative and agentic AI to transform shopping — Rufus adoption, conversion association, memory, carting, price monitoring, and Buy for Me.
• Instacart’s AI assistant — live-inventory cart building and rollout; paired with the Gemini integration for catalog scale and cross-platform agentic flow.
• REGEN — critiques, narratives, dataset construction, and conversational recommendation benchmarks.
• Agent4Rec and RecMind — agent simulation and tool-using recommendation research, respectively.
• τ-Rec and RecRM-Bench — verifiable preference-elicitation trajectories, repeated-trial reliability, and multidimensional process evaluation.
• RecHarness and SR-Agent — improvement-time agents, bounded strategy search, staged rewards, rollback, and reported online experiments; both are early preprints.
• Harness engineering and Demystifying evals for AI agents — primary engineering sources for environment, feedback-loop, and model-plus-harness evaluation claims.

What to read next

• How great AI engineers build agents with datasets, scores, and harnesses
• Context engineering in production
• Harness Engineering foundation
• Evaluation and Observability foundation
• Promotion-aware Memory foundation