Recommendation engines used to feel like a specialized ML topic: collaborative filtering, matrix factorization, ranking models, offline metrics, and A/B tests. AI agents changed the shape of the product around them.
In a modern agent app, recommendations are not only “items you may like.” They can be tools to call, documents to read, next actions to suggest, products to bundle, people to route to, workflows to automate, prompts to reuse, or agents to delegate to. The recommender is no longer just a model behind a carousel. It is often the decision layer that helps an agent choose what to do next.
That makes recommender systems more important, not less. The best production pattern is still boring in the best possible way: collect clean events, retrieve a manageable candidate set, rank it with the right features, apply business and safety constraints, observe outcomes, and improve through evaluation. The agent layer should make this system more interactive and explainable, not replace all of it with one giant prompt.
TL;DR
- A production recommender is a system, not a model. It includes event collection, identity, item catalogs, retrieval, ranking, filtering, exploration, evaluation, observability, safety, and product feedback loops.
- Start simple. A rules-based or popularity-based MVP often beats a complex model if your data is thin, your catalog is small, or your PM still needs to learn what “good” means.
- Most mature systems use a multi-stage architecture: retrieve many candidates cheaply, rank fewer candidates carefully, then apply constraints and presentation logic. YouTube’s deep recommendation paper and NVIDIA Merlin’s production examples both use this retrieval-ranking shape (YouTube paper, NVIDIA Merlin example).
- AI agents are useful around the recommender: preference elicitation, conversational refinement, explanation, workflow planning, tool orchestration, and cold-start help. They should not be allowed to silently bypass ranking, policy, permissions, or evals.
- Offline metrics are necessary but incomplete. Production recommendation quality needs online tests, counterfactual thinking, guardrails, trace analysis, business metrics, and long-term feedback-loop monitoring.
What You Will Learn Here
- How recommendation engines work from zero to production.
- Why retrieval, ranking, filtering, and ordering are separate jobs.
- Where classic collaborative filtering, matrix factorization, two-tower models, wide-and-deep models, LLMs, and agents fit.
- How to design a recommendation architecture for complex agent apps.
- What to evaluate before launch and what to monitor after launch.
- A small code example for a hybrid recommendation endpoint.
- The main gaps teams usually miss when moving from demo to production.
The Research Audit
I audited primary and close-to-primary sources for this article: classic industrial recommender papers from Amazon, Netflix, Google/YouTube, and Google Play; official TensorFlow Recommenders and NVIDIA Merlin materials; OpenAI, Anthropic, Google Cloud, Microsoft, OWASP, and OpenTelemetry guidance for production AI agents; and recent survey work on LLM-powered and agentic recommender systems.
The strongest pattern across the sources is this:
- Recommendation systems need staged architecture because scale, freshness, and precision pull in different directions.
- Agent systems need explicit control because autonomy, tool use, and user trust pull in different directions.
- The intersection needs both disciplines: recommender-system rigor for ranking decisions, and agent-engineering rigor for context, tools, safety, tracing, and human control.
The Mental Model
A recommender answers one of these questions:
Given:
user or account context
current task or session context
item or action catalog
business constraints
safety constraints
Return:
a ranked set of useful next optionsFor a media app, the options are videos or songs. For an ecommerce app, they are products or bundles. For an AI-agent product, they can be much more operational:
- Which document should the agent read next?
- Which tool should it call?
- Which workflow should it suggest?
- Which support answer should it draft?
- Which product should it recommend?
- Which human should approve the next step?
- Which specialized subagent should handle this part?
That is why recommender systems and agent systems are starting to overlap.
A Production Recommendation Flow
Most teams should think in stages:
Events + Catalog + User State
|
v
Candidate retrieval
popularity, content, vector search,
collaborative filtering, two-tower model
|
v
Filtering
permissions, inventory, safety,
freshness, policy, dedupe
|
v
Ranking
relevance, intent, context,
predicted value, uncertainty
|
v
Re-ranking / ordering
diversity, exploration,
business rules, UX constraints
|
v
Presentation + feedback eventsThis pattern shows up again and again in production systems. The YouTube recommendation paper describes a candidate generation network followed by a ranking network, because a system with a huge corpus needs a cheap way to narrow the field before applying richer features (YouTube paper). NVIDIA Merlin describes production recommender workflows as multiple stages that include preprocessing, retrieval, filtering, ranking, and ordering (NVIDIA Merlin multi-stage example).
The agent version adds one more layer:
User goal
|
v
Agent runtime
|
+--> asks recommender for options
+--> explains or refines user preferences
+--> applies approvals for risky actions
+--> calls tools only inside permission boundaries
|
v
Ranked recommendation or next actionThe recommender should remain a controlled service. The agent can ask for candidates, explain why an option is good, or help the user refine intent. But the agent should not invent unauthorized options or skip policy checks because the generated answer sounded confident.
Stage 0: Define the Recommendation Job
Before models, decide what “good” means.
For PMs, this means writing the recommendation contract:
- Who receives the recommendation?
- What item or action is being recommended?
- What user job does it help with?
- What should never be recommended?
- What is the success metric?
- What is the harm metric?
- How quickly does the system need to react?
For engineers, this becomes an interface:
type RecommendationRequest = {
userId: string;
sessionId?: string;
intent?: string;
surface: "home" | "search" | "chat" | "agent_action";
limit: number;
constraints?: {
allowedItemTypes?: string[];
requireApproval?: boolean;
excludeIds?: string[];
};
};
type Recommendation = {
id: string;
type: "article" | "product" | "tool" | "workflow" | "agent";
score: number;
reason: string;
requiresApproval: boolean;
};This contract is humble, but it prevents chaos. Your agent can ask for “the best next workflow,” but the recommender still returns typed objects with scores, reasons, and approval flags.
Stage 1: Start With a Baseline
The first recommender does not need deep learning. It needs to create a useful feedback loop.
Good MVP baselines:
- Popular items in the current category.
- Recently used items by the same user.
- Similar items by tags or embeddings.
- Editorial picks controlled by PMs.
- Rules based on lifecycle stage or task type.
- Item-to-item recommendations for small catalogs.
Amazon’s early item-to-item collaborative filtering work is still worth reading because it focuses on scale and product fit, not model glamour. The key move was comparing similar items rather than searching for similar users at request time, which made recommendations practical for a huge catalog (Amazon item-to-item paper).
An MVP baseline gives you something more valuable than a fancy architecture: logs. Without exposure, click, dismiss, conversion, and satisfaction events, your next model is mostly guessing.
Stage 2: Collect the Right Events
Recommendation data is not just “what the user clicked.” Clicks are useful, but they are biased by what you chose to show.
At minimum, log:
exposure: item was shown.position: where it appeared.surface: home, search, chat, checkout, editor, agent panel.request_context: intent, filters, locale, device, account state.action: click, save, buy, run, approve, dismiss, hide, rate.outcome: success, refund, escalation, task completion, churn signal.policy_result: blocked, allowed, approval required.model_versionandranking_version.
This matters because recommendation systems create their own future training data. If you only show popular items, popular items get more interactions, and your logs will tell you to keep showing popular items. Position bias is the simplest example: higher-ranked items receive more attention partly because they are higher-ranked, not only because they are better.
The production lesson: log what you showed, not only what users clicked.
Bad log:
user clicked item_42
Useful log:
request r123 showed [item_42, item_7, item_9]
positions [1, 2, 3]
user clicked item_42
item_7 was ignored
ranker=v4.2
policy=allowed
session_intent="compare pricing"Stage 3: Candidate Retrieval
Candidate retrieval is the fast, broad stage. Its job is to reduce millions of possible items to hundreds or thousands that are plausible.
Common retrieval methods:
- Popularity by segment.
- Content-based search by text, tags, metadata, or embeddings.
- Item-to-item collaborative filtering.
- Matrix factorization.
- Approximate nearest neighbor search over user and item embeddings.
- Two-tower neural retrieval models.
- LLM-assisted retrieval for cold-start or natural-language intent.
Matrix factorization is a classic collaborative-filtering technique: learn latent vectors for users and items, then score by vector similarity. The Netflix Prize era made this family of methods famous, especially because it could incorporate implicit feedback and other signals beyond explicit ratings (Koren, Bell, and Volinsky).
Two-tower retrieval is the modern cousin many engineers meet first. One tower encodes the user or query, another encodes the item, and retrieval happens through nearest-neighbor search. TensorFlow Recommenders describes this pattern directly in its retrieval tutorial (TensorFlow Recommenders retrieval).
User tower Item tower
---------- ----------
user history title
session intent -----> category
account features metadata
current context content embedding
| |
v v
user embedding item embedding
| |
+---------- dot product -----------+
|
v
candidate setFor agent apps, retrieval is often hybrid. You may retrieve:
- documents by semantic similarity,
- workflows by task intent,
- tools by capability,
- products by catalog features,
- past successful actions by user similarity.
The practical rule: retrieval should optimize recall. It is allowed to be rough. Ranking will be more precise.
Stage 4: Filtering and Policy
Filtering is where production reality enters the room.
Filter before ranking when an item should never be eligible:
- user lacks permission,
- item is out of stock,
- document is confidential,
- tool is disabled,
- workflow is not available in this region,
- content violates policy,
- action requires approval and no approval path exists.
Filter after ranking when the rule depends on the final list:
- dedupe similar items,
- cap one category,
- ensure diversity,
- add exploration slots,
- avoid repeating the same recommendation too often.
In an agent app, this is not optional. OpenAI’s agent safety guidance highlights prompt injection and risky downstream tool calls as serious design concerns, and OWASP’s AI Agent Security Cheat Sheet calls out prompt injection, tool abuse, privilege escalation, and data exfiltration as major risks (OpenAI agent safety, OWASP AI Agent Security Cheat Sheet).
That means your recommender should not only answer “what is relevant?” It must also answer “what is allowed?”
Stage 5: Ranking
Ranking is the slower, more precise stage. It receives a manageable candidate set and sorts it using richer features.
Ranking features often include:
- user-item interaction history,
- current session intent,
- item freshness,
- creator or brand quality,
- price, margin, or availability,
- semantic match,
- social proof,
- predicted click or conversion,
- predicted long-term satisfaction,
- safety or trust scores,
- uncertainty.
Wide-and-deep models are a useful historical bridge here. Google’s Wide & Deep paper describes combining memorization from wide linear feature crosses with generalization from deep neural embeddings, and reports production use in Google Play (Wide & Deep paper). The architecture is old by current standards, but the product lesson remains fresh: recommender rankers often need both exact known patterns and generalization to new combinations.
For many production teams, the ranker evolves like this:
Rules
-> logistic regression / gradient boosted trees
-> matrix factorization features
-> deep ranking model
-> multi-task ranker
-> contextual bandit or online learner for selected surfacesDo not skip steps just because the last one sounds more advanced. A well-instrumented gradient-boosted ranker can beat a poorly understood deep model.
Stage 6: Re-ranking, Diversity, and Exploration
A ranker can produce a technically correct but boring list.
If every recommended item is near-identical, users may click once and then lose trust. If the system never explores, new items never get a fair chance. If the list optimizes only short-term clicks, it may harm long-term retention or user satisfaction.
Common re-ranking goals:
- diversify categories,
- diversify creators or suppliers,
- include fresh items,
- reserve exploration slots,
- cap repeated recommendations,
- balance relevance with business constraints,
- avoid sensitive or manipulative inferences.
Contextual bandits are a principled way to manage exploration and exploitation, especially when content changes quickly. The Yahoo News LinUCB paper framed personalized news recommendation as a contextual bandit problem, where the system chooses articles, observes click feedback, and learns while serving users (Li et al., 2010). In practice, bandits are powerful but operationally demanding: you need careful logging, guardrails, and evaluation because the model is learning from live exposure.
Where AI Agents Fit
Agents can improve recommender products in five strong ways.
1. Preference Elicitation
Cold start is painful because the system knows little about a new user or item. An agent can ask targeted questions:
Agent:
"Are you looking for a quick prototype, a production architecture,
or a research-heavy comparison?"
User:
"Production architecture."
Recommender context:
intent=production_architecture
depth=advanced
item_types=[article, template, repo, workflow]The agent turns vague intent into structured features the recommender can use.
2. Conversational Refinement
Traditional recommender UIs make users click filters. Agentic UIs let users say:
- “More practical, less academic.”
- “Show me cheaper options.”
- “I already read that.”
- “Prefer Python examples.”
- “Exclude anything that requires Kubernetes.”
The agent should translate those refinements into constraints and features, then call the recommender again.
3. Explanation
LLMs are good at explanation, but explanations should be grounded in ranker features and policy decisions.
Better:
"I recommended this because it matches your current FastAPI stack,
uses Postgres like your project, and has the highest success rate
among similar teams."Risky:
"I recommended this because I think it is perfect for you."The first explanation can be audited. The second is vibes with punctuation.
4. Workflow Planning
In complex apps, the recommender may return possible next actions:
- create a ticket,
- run a diagnostic,
- ask for approval,
- send a message,
- assign a reviewer,
- open a dashboard,
- start a remediation workflow.
The agent can plan around those options, but tool permissions and approvals should stay outside the model’s imagination. Anthropic’s agent guidance recommends starting with simple composable patterns and increasing autonomy only when needed; OpenAI’s practical guide similarly emphasizes clear orchestration, tools, guardrails, and human oversight for production agents (Anthropic building effective agents, OpenAI practical guide).
5. User Simulation and Research
Recent research explores LLM-powered agents for recommender systems, including user simulation, conversational recommendation, and agentic recommendation benchmarks. Agent4Rec, for example, uses generative agents initialized from MovieLens data to simulate recommendation interactions (Agent4Rec paper). Surveys on LLM-powered agents for recommender systems describe modules such as profiles, memory, planning, and action as emerging building blocks (LLM-powered agents for recommender systems survey).
This is promising, especially for research and cold-start exploration. But synthetic users are not a substitute for production telemetry. Treat them as an extra test environment, not as proof that real users will behave the same way.
A Reference Architecture for Agentic Recommendations
+----------------------+
| Admin / PM controls |
| rules, inventory, |
| campaigns, policies |
+----------+-----------+
|
v
+-------------+ +-------------------+-------------------+
| User / App | --> | Agent or API recommendation request |
+-------------+ +-------------------+-------------------+
|
v
+----------+-----------+
| Context builder |
| user, session, |
| intent, permissions |
+----------+-----------+
|
+-------------------+-------------------+
| |
v v
+---------+----------+ +----------+---------+
| Candidate retrieval | | Policy service |
| vectors, CF, search | | auth, safety, |
| popularity, tools | | compliance |
+---------+----------+ +----------+---------+
| |
+-------------------+-------------------+
|
v
+----------+-----------+
| Ranker / re-ranker |
| relevance, diversity |
| exploration |
+----------+-----------+
|
v
+----------+-----------+
| Response + reasons |
| trace + event log |
+----------+-----------+
|
v
+----------+-----------+
| Training + eval loop |
+----------------------+The important part is separation of concerns:
- The agent handles conversation and task orchestration.
- The recommender handles candidate scoring.
- The policy service handles eligibility and safety.
- The event pipeline handles learning.
- The evaluation system decides whether changes are better.
- Observability gives everyone a shared memory of what happened.
A Small Hybrid Recommender Example
This is not a full production system. It is a compact shape you can grow from.
type Candidate = {
id: string;
type: "doc" | "tool" | "workflow";
baseScore: number;
metadata: Record<string, string | number | boolean>;
};
type UserContext = {
userId: string;
intent: string;
allowedTypes: Candidate["type"][];
recentIds: Set<string>;
role: "viewer" | "operator" | "admin";
};
async function recommendNextActions(ctx: UserContext, limit = 5) {
const [semantic, popular, recentSuccesses] = await Promise.all([
retrieveByEmbedding(ctx.intent, 100),
retrievePopularByRole(ctx.role, 50),
retrieveSuccessfulForSimilarUsers(ctx.userId, 50),
]);
const candidates = dedupe([...semantic, ...popular, ...recentSuccesses]);
const eligible = candidates.filter((candidate) => {
if (!ctx.allowedTypes.includes(candidate.type)) return false;
if (ctx.recentIds.has(candidate.id)) return false;
if (!passesPolicy(candidate, ctx)) return false;
return true;
});
const ranked = eligible
.map((candidate) => ({
...candidate,
score:
candidate.baseScore +
intentBoost(candidate, ctx.intent) +
freshnessBoost(candidate) +
successRateBoost(candidate, ctx.role) -
riskPenalty(candidate, ctx.role),
}))
.sort((a, b) => b.score - a.score);
const diversified = diversifyByType(ranked);
await logRecommendationExposure({
userId: ctx.userId,
intent: ctx.intent,
shownIds: diversified.slice(0, limit).map((item) => item.id),
rankerVersion: "hybrid-v1",
});
return diversified.slice(0, limit).map((item) => ({
id: item.id,
type: item.type,
score: item.score,
reason: buildGroundedReason(item, ctx),
requiresApproval: needsApproval(item, ctx),
}));
}This example keeps the essential production hooks:
- multiple retrieval sources,
- policy filtering,
- score composition,
- diversity,
- exposure logging,
- reasons,
- approval flags.
That is the shape you want before adding heavier ML.
Evaluation: What to Measure Before and After Launch
Recommendation evaluation is tricky because historical data is biased by the old system. Offline evaluation is still useful, but it should not be treated as final truth.
Offline metrics:
- precision@k,
- recall@k,
- NDCG,
- MAP,
- coverage,
- diversity,
- novelty,
- calibration,
- constraint violation rate,
- latency and cost.
Online metrics:
- click-through rate,
- conversion,
- task completion,
- acceptance rate,
- dismiss or hide rate,
- long-term retention,
- revenue or savings,
- escalation rate,
- complaint rate,
- human override rate,
- safety incident rate.
Agent-specific metrics:
- tool-call success,
- approval rate,
- wrong-action prevention,
- trace-level task success,
- grounded explanation quality,
- hallucinated recommendation rate,
- permission violation attempts,
- recovery after user correction.
OpenAI’s current agent evaluation guidance recommends trace grading for workflow-level issues because traces capture model calls, tool calls, guardrails, and handoffs end to end (OpenAI agent evals). Anthropic’s eval guidance also frames evals as structured tests for AI systems, not only model benchmarks (Anthropic evals).
For recommender changes, also consider counterfactual or off-policy evaluation before exposing users to risky changes. The “Offline A/B testing for recommender systems” paper studies estimators intended to predict business uplift before online A/B tests (Gilotte et al.). The practical takeaway is not “offline replaces online.” It is “use offline methods to avoid obviously bad launches, then validate with real users.”
Observability: The Debugging Layer
When a user asks, “Why did the agent recommend this?”, you need more than a final answer.
Log the decision path:
trace_id: rec_8f21
user_intent: "reduce cloud bill"
retrieval_sources:
semantic: [workflow_12, doc_91, tool_3]
popular: [workflow_4, doc_22]
filtered:
tool_3 -> blocked: missing_permission
ranked:
workflow_12 -> 0.84
doc_91 -> 0.77
workflow_4 -> 0.61
reranked:
workflow_12, doc_91, workflow_4
shown:
workflow_12, doc_91, workflow_4
outcome:
user_approved workflow_12For agent systems, traces should include model calls, tool calls, handoffs, guardrails, policy decisions, and custom events. The OpenAI Agents SDK tracing docs describe tracing as a record of generations, tool calls, handoffs, guardrails, and custom events (OpenAI Agents SDK tracing). OpenTelemetry is also standardizing GenAI semantic conventions for spans and metrics, including agent and framework spans (OpenTelemetry GenAI agent spans).
For PMs, observability is not only for engineers. It is how you learn which recommendation surfaces are helping users and which ones are creating confusion.
Safety and Governance
Recommendation systems can cause harm quietly. Agentic recommendation systems can cause harm actively.
Risks to design for:
- recommending unavailable or unauthorized actions,
- leaking private documents through personalized suggestions,
- optimizing short-term clicks over user welfare,
- reinforcing popularity bias,
- manipulating user choices,
- allowing prompt injection to influence recommendations,
- allowing an agent to call risky tools from a recommendation,
- generating explanations that are not grounded in real features.
Microsoft’s governance guidance for AI agents emphasizes that organizations need to know what agents exist, who owns them, what they can access, what they do, and how to stop unsafe behavior (Microsoft agent governance). That applies directly to agentic recommenders: recommendations that trigger actions must be owned, observable, permissioned, and stoppable.
A simple launch checklist:
- Every recommended action has an owner.
- Every tool recommendation has a permission check.
- Risky actions require approval.
- The model cannot override policy filters.
- Explanations are generated from grounded features.
- Prompt-injected content is treated as untrusted input.
- Users can dismiss, correct, or reset personalization.
- The system logs exposure and outcomes.
- There is a kill switch by surface, model, and policy.
Build Roadmap: Zero to Production
Phase 1: Product Contract
Define the surface, user job, item catalog, constraints, and success metrics. Decide what should never be recommended.
Phase 2: Baseline Recommender
Ship popularity, rules, tags, recency, or item-to-item logic. Add event logging from day one.
Phase 3: Retrieval Layer
Add semantic search, collaborative signals, matrix factorization, or a two-tower model depending on catalog size and data maturity.
Phase 4: Ranking Layer
Train a ranker with user, item, context, and interaction features. Keep a simple model as a fallback and benchmark.
Phase 5: Agent Integration
Let the agent collect preferences, refine constraints, explain recommendations, and orchestrate approved next actions. Keep policy and ranking outside the prompt.
Phase 6: Evaluation and Observability
Add offline metrics, scenario tests, trace grading, online experiments, cost/latency dashboards, and safety monitoring.
Phase 7: Governance and Scale
Add ownership, approval workflows, rollout controls, model/version tracking, drift checks, privacy review, and incident response.
Common Architecture Choices
| Situation | Good first choice | Avoid |
|---|---|---|
| Small catalog, little data | Rules + editorial + popularity | Deep model without signal |
| Rich item text, cold start | Embeddings + metadata filters | Pure collaborative filtering |
| Large catalog | Retrieval + ranking stages | Ranking every item online |
| Fast-changing content | Freshness features + exploration | Batch-only retraining |
| Regulated actions | Policy service + approvals | Letting the agent decide permissions |
| Complex user intent | Agent preference elicitation | One-shot recommendations with no refinement |
| Production debugging | Traces + exposure logs | Only logging clicks |
Known Gaps in This Article
This article is intentionally architecture-first. The biggest gaps worth expanding later are:
- A hands-on notebook that trains a retrieval model and ranker on a public dataset.
- A deeper comparison of vector databases, feature stores, and online serving stacks.
- A full section on privacy-preserving personalization and data retention.
- A stronger treatment of marketplace fairness, creator/supplier fairness, and long-term ecosystem health.
- More examples for non-commerce domains: developer tools, internal knowledge bases, healthcare operations, education, and support automation.
Recommended Next Sections to Add Later
If this article becomes a series, I would add:
- “Two-Tower Retrieval From Scratch”
- “How to Evaluate Recommenders Without Fooling Yourself”
- “Agentic Recommendation UX Patterns”
- “Feature Stores for Recommendation Systems”
- “How to Design Recommendation Explanations”
- “Safety Patterns for Tool and Workflow Recommendations”
Source List
- Greg Linden, Brent Smith, and Jeremy York, “Amazon.com Recommendations: Item-to-Item Collaborative Filtering” (PDF).
- Yehuda Koren, Robert Bell, and Chris Volinsky, “Matrix Factorization Techniques for Recommender Systems” (PDF).
- Paul Covington, Jay Adams, and Emre Sargin, “Deep Neural Networks for YouTube Recommendations” (PDF).
- Heng-Tze Cheng et al., “Wide & Deep Learning for Recommender Systems” (arXiv).
- TensorFlow Recommenders, “Recommending movies: retrieval” (official guide).
- NVIDIA Merlin, “Building Intelligent Recommender Systems with Merlin” (official example).
- Lihong Li et al., “A Contextual-Bandit Approach to Personalized News Article Recommendation” (paper page).
- Alexandre Gilotte et al., “Offline A/B testing for Recommender Systems” (arXiv).
- Lei Li et al., “Large Language Models for Generative Recommendation: A Survey and Visionary Discussions” (arXiv).
- “A Survey on LLM-powered Agents for Recommender Systems” (arXiv).
- “On Generative Agents in Recommendation” / Agent4Rec (arXiv).
- OpenAI, “A Practical Guide to Building Agents” (PDF).
- OpenAI, “Safety in building agents” (official docs).
- OpenAI, “Evaluate agent workflows” (official docs).
- OpenAI Agents SDK, “Tracing” (official docs).
- Anthropic, “Building Effective Agents” (research note).
- Anthropic, “Demystifying evals for AI agents” (engineering note).
- Google Cloud, “Choose your agentic AI architecture components” (official docs).
- Microsoft, “Governance and security for AI agents across the organization” (official docs).
- OWASP, “AI Agent Security Cheat Sheet” (official cheat sheet).
- OpenTelemetry, “Semantic Conventions for GenAI agent and framework spans” (official specification).