Recommender Systems Should Now Be Designed Towards Agents

1. Introduction

Recommender systems have historically been designed around people. Their canonical outputs are products, ads, songs, creators, news, and movies; their canonical objectives are relevance, utility, conversion, retention, and satisfaction [1,2,3,4]. Even as the methodology evolved from matrix factorization to sequential, contextual, conversational, causal, and reinforcement-learning formulations, the final recommendation usually still targeted a human chooser [5,6,7,8,9,10,11,12,13]. We call this long-standing paradigm recommender systems towards humans (RSTH).

A nearby but different line of work uses LLMs and agents inside the recommendation pipeline while keeping the final recipient human. We refer to this family as agentic recommender systems towards humans (ARSTH). Recent surveys of foundation-model and LLM-powered recommender systems make this trend explicit [14,15,16]. ARSTH are important, but they are still a subset of RSTH: their ranked outputs remain human-facing. Figure 1 illustrates the distinctions among these paradigms.

This position paper argues that recommender systems should now be designed towards agents. We refer to this third destination as recommender systems towards agents (RSTA). Modern agents do not merely answer questions. They browse, retrieve, compare, call APIs, inspect files, manipulate software, invoke verifiers, and coordinate with other agents. Tool-use, web, app, and multi-agent environments already expose repeated decision points where ranking changes what trajectories an agent can reach [17,18,19,20,21,22,23,24,25,26]. This matters not only to recommender systems, but also to LLM agents, tool-use evaluation, multi-agent orchestration, AI systems interfaces, and market design and governance.

Services must also increasingly face agents directly rather than only human users. As industry leaders point out, the software ecosystem will need to be fundamentally re-engineered to keep up with the execution speed and scale of autonomous AI agents [27,28]. Open interoperability and tool protocols already make agent-facing capability surfaces more legible [29,30,31], while analyst reports forecast massive growth in agentic features, task-specific agents, and digital labor inside ordinary applications (see Figure 2) [32,33,34,35,36]. In a world where software is re-architected for machine consumption, recommendation does not disappear. It becomes the essential routing and filtering layer of the agent-facing interface.

A natural objection follows immediately: if agents become stronger reasoning engines, should they not simply ingest the environment and plan everything internally? Our answer is no, for two foundational reasons. First, context limits and compute costs. Modern digital environments genuinely expose massive candidate spaces—an agent cannot hold tens of thousands of API schemas, product catalogs, or enterprise approval paths in its working memory without suffering severe latency, cost, and attention-degradation. Filtering and ranking remain existential systems requirements. Second, even when the immediate candidate space is modest, priority order dictates execution. Because internal planning is compute-bounded and path-dependent, an agent can only deeply evaluate a bounded prefix of actions. If an oversight action (like verify) or an optimal API call is not ranked highly, the agent will never consider it, leading to brittle or unauthorized trajectories. The RSTA layer is therefore not merely a rebranding of offline reinforcement learning or contextual bandits; it is a distinct architectural layer that brings the scalability, candidate-generation, and multi-stakeholder optimizations of classical recommender systems directly into the agent’s action space. Section 3 formalizes both regimes.

We make four concrete contributions. (1) We provide a clean boundary for what does and does not count as RSTA. (2) We turn the framing into three falsifiable claims. (3) We add a worked example by recasting a WorkArena-style hardware-order task family as a RSTA problem over grounded interventions. (4) We outline a focused agenda plus a lightweight evaluation template in Appendix I. The goal is not to rename all agentic decision making. The goal is to isolate a layer that is empirically testable, methodologically useful, and increasingly important.

2. What RSTA is—and What It Is Not

Our key distinction is not whether agents appear somewhere in the pipeline. It is whether the final ranked output is consumed by a human or by an acting agent. We therefore reserve RSTH for human-targeted ranking, reserve ARSTH for agentic modules inside human-targeted recommendation, and use RSTA only when the ranking is directed toward an acting agent, an orchestration layer, or a multi-agent system.

Definition. 

A recommender system towards agents (RSTA) is a system that, given an agent’s task, state, and feasible intervention inventory, produces a ranking over candidate interventions for that agent, with the explicit objective of improving downstream trajectory utility under preference, cost, policy, and safety constraints. The ranked objects can include tools, documents, offers, parameters, workflow branches, delegates, verifiers, and ask/act/defer/escalate options. We use authorized agency to denote the portion of the action surface the agent is both able and permitted to exercise.

A practical boundary test follows immediately. A problem counts as RSTA only when four conditions all hold: (1) the immediate recipient of the ranking is an acting agent or orchestration layer; (2) the ranked objects are explicit or reconstructable candidate interventions; (3) the ranking can change the downstream trajectory rather than only the surface presentation; and (4) success is measured by trajectory outcomes, possibly with multiple stakeholders behind the agent. Table 1 outlines clear negative examples to sharpen this boundary.

The exclusion boundary matters because it prevents the concept from becoming vacuous. A problem is not RSTA merely because an LLM or an agent appears in the stack. Conversely, a problem can be RSTA even when the menu is small, because the core object is not menu size alone; it is the ranking of grounded interventions for an acting agent under delegated and distributed agency.

Operationally, what separates RSTA from “just planning,” offline RL, or routing is a specific architectural interface. It is defined by an explicit or reconstructable candidate inventory, a ranked slate exposed directly to the acting agent, a bounded top-K inspection or deliberation budget that forces priority, the integration of possible service-private signals, and a diagnostic framework that separates failure attribution into candidate generation, ranking, and execution. While these pieces can exist in isolation, consolidating them creates a distinct, testable layer that dictates how agents navigate massive or compute-bounded action spaces.

3. Formalization: lArge Surfaces, Priority-Sensitive Sets, and Implications

At the most general level, an RSTA answers one question: among the feasible next-step interventions available at step t, which ones should be placed first for the agent? We use four ingredients: current state $s_t$, principal-side context ${\rho }_t$, optional service-side context ${\sigma }_t$, and feasible candidate set ${\Omega }_t$. An RSTA outputs an ordered slate

$$R_t=(r_{t,1},\dots ,r_{t,L_t})=f(s_t,{\rho }_t,{\sigma }_t,{\Omega }_t),$$

(1)

where each $r_{t,i}\in {\Omega }_t$ and order is part of the output. For agentic systems, the useful object is rarely only a tiny verb inventory such as {click, type, call, stop}. The useful object is the effective intervention space, the grounded and typed set of feasible next-step choices:

$${\Omega }_t=\left\{x=(o,\theta ,m,d)|o\in O_t,\theta \in {\Theta }_t,m\in M_t,d\in D_t,\mathrm{and}x\mathrm{is}\mathrm{feasible}\mathrm{at}t\right\}.$$

(2)

Here $O_t$ contains candidate objects such as items, tools, files, DOM elements, pages, sellers, or delegates; ${\Theta }_t$ contains feasible parameter settings; $M_t$ contains execution modes such as act, ask, defer, verify, sandbox, or escalate; and $D_t$ contains coordination choices such as collaborator, protocol, or aggregation mode. In a single-agent deployment, d can be a null delegate.

Let $\tau =(s_t,x_t,s_{t+1},x_{t+1},\dots )$ denote the realized future trajectory after step t. We evaluate a ranking through the scalar utility of the trajectory it helps induce:

$$U\left(\tau \right)=u(\tau \mid {\rho }_t,{\sigma }_t).$$

(3)

Depending on the application, u may reward task completion and preference satisfaction, and penalize cost, delay, risk, or policy violations.

Large-surface regime. 

In the first regime, recommendation matters because $|{\Omega }_t|$ is large or combinatorial. Shopping, tool use, web navigation, and enterprise workflows all produce this pattern. WebShop contains 1.18 million products, ToolLLM is built from 16,464 real-world APIs, AppWorld exposes 457 APIs across nine apps, and WorkArena-style service workflows contain rich grounded action surfaces [19,21,23,24,25]. In such settings recommendation still performs filtering and ranking, but over actionable interventions rather than only items.

Priority-sensitive regime. 

The second regime is smaller but central to our framework. Even when $|{\Omega }_t|$ is modest, ranking order can still matter because internal planning is compute-bounded, latency-bounded, order-sensitive, and often path-dependent. Under bounded deliberation, the agent can only afford to inspect a top-K prefix of the ranked slate, which we denote as $P_t\subset {\Omega }_t$. The agent then selects its next action $a_t\in P_t$ based on its internal evaluation. If the ranking is poor and the globally optimal intervention $x^{\star }$ falls outside this prefix ($x^{\star }\notin P_t$), the agent is forced to choose a suboptimal action. This leads to a strict drop in the expected downstream trajectory utility:

$$\underset{x\in P_t}{max}U(\tau \mid x)<U(\tau \mid x^{\star }).$$

(4)

This is the elementary but load-bearing reason recommendation survives even when menus are not large: ranking determines which interventions receive serious internal evaluation. Table 2 contrasts these two regimes.

Testable implications.

Claim 1: Priority-sensitive ranking improves trajectory utility even when candidate sets are small. Test by fixing the candidate inventory, varying slate order only, and measuring downstream trajectory utility rather than only next-step accuracy.

Claim 2: Service-side information creates value that local planning alone cannot fully recover. Test by comparing an agent-local ranker with and without access to service-private signals such as permissions, inventory, compatibility, reliability, or policy state.

Claim 3: Oversight actions should be modeled as recommendables, not post-hoc constraints. Test by allowing verify, ask, defer, sandbox, or escalate to compete in the slate and comparing trajectory-level safety and compliance against systems that apply guardrails only after ranking productive actions.

4. Worked Example: Recasting a WorkArena-Style Task as RSTA

To make the framing concrete without overclaiming a specific environment instance, we recast a WorkArena-style hardware-order task as a recommendation problem over grounded interventions [24,25]. WorkArena-style environments include service-catalog tasks in which an agent must order the right hardware item with the right specifications. The RSTA question is not only whether the final order is eventually correct. It is which next-step interventions should be surfaced first so that the trajectory stays accurate, efficient, and safe.

Consider a decision point at which the agent has reached the hardware catalog for a replacement laptop charger and sees several matches. One explicit candidate inventory is shown in Table 3. The example is faithful at the task-family level rather than a claim about one verbatim environment instance; the point is to make the candidate inventory, slate, and failure analysis fully explicit.

To see why this requires an RSTA layer rather than just local LLM planning, we map this inventory directly to our three claims.

First, consider Claim 1 (priority-sensitive small sets). Even though this menu contains only seven interventions—easily fitting into an LLM’s context window—an agent’s internal deliberation is bounded by token budgets, latency requirements, and API rate limits. If the agent can only afford to deeply evaluate or simulate a top-K prefix (e.g., $K=2$), the ranking strictly dictates the trajectory. If the premature submit ($x_6$) is ranked above the compatibility check ($x_2$), the agent executes a brittle shortcut before it ever considers verification.

Second, consider Claim 2 (service-side information asymmetry). Why should the enterprise catalog platform determine this ranking rather than the local agent? Because the platform holds private signals. Suppose the platform’s backend analytics reveal a 40% historical return rate for this specific charger SKU due to a recent manufacturer defect, a fact absent from the public product page. The local agent cannot know this. The service-side RSTA must therefore elevate the compatibility check ($x_2$) and the alternative comparison ($x_3$) to the top of the slate to protect downstream utility.

Finally, this inventory embodies Claim 3 (oversight as recommendables) by forcing productive actions ($x_1,x_6,x_7$) to compete directly against verification, clarification, and escalation ($x_2,x_4,x_5$) within the exact same slate.

A plausible service-aware ranked slate is therefore:

$$R_t=[x_2,x_3,x_1,x_5,x_4,x_6,x_7].$$

(5)

This order says: verify compatibility first (due to hidden return risks); compare the near-match next; inspect the best approved candidate only after verification; escalate for faster shipping if necessary; ask about substitutes if the exact item is not available; keep premature submit and non-approved purchase safely near the bottom.

The natural objective is trajectory-level rather than action-level:

$$U\left(\tau \right)=\alpha T\left(\tau \right)+\beta M\left(\tau \right)+\lambda G\left(\tau \right)-\gamma C\left(\tau \right)-\delta L\left(\tau \right)-\eta V\left(\tau \right),$$

(6)

where $T\left(\tau \right)$ is binary task completion, $M\left(\tau \right)$ measures how well the item matches the instruction, $G\left(\tau \right)$ is governance and authorization conformity, $C\left(\tau \right)$ is the spend, $L\left(\tau \right)$ represents latency or delay, and $V\left(\tau \right)$ penalizes policy or safety violations. The coefficients $\alpha ,\beta ,\lambda ,\gamma ,\delta ,\eta \ge 0$ are weighting parameters that balance task efficiency against cost and operational risk.

This recast exposes a failure that coarse end-to-end evaluation can miss. Standard end-to-end evaluation may focus on whether an order request was eventually created and roughly matched the instruction. That can fail to distinguish two different trajectories: one that ranked verification early and completed the task through the intended service-catalog path, and another that ranked premature submit or non-approved purchase above verification. The latter may still look superficially successful while being brittle, unauthorized, or costly to clean up. From an RSTA perspective, the diagnosis is therefore not only “the agent failed” or “the agent succeeded.” It is whether the ranking over grounded interventions surfaced the right actions in the right order. Table 4 highlights why this RSTA recast is methodologically different from ordinary end-to-end agent evaluation.

5. Alternative Views

We highlight five strong objections to the RSTA framing, spanning agent capabilities, machine learning paradigms, and systems architecture.

Counterargument 1: Stronger agents make recommendation obsolete. 

The most immediate objection is that if foundation models become sufficiently capable planners, an explicit recommendation layer becomes unnecessary; the agent should simply ingest the environment and plan its own path.

Response: We disagree because stronger reasoning does not erase physical and operational constraints. First, autonomy does not remove candidate scale. A web agent still faces millions of domains; a buyer still faces massive product catalogs. Better planning helps reason over these choices, but it does not bypass the need for an efficient retrieval and filtering layer before the LLM’s context window is invoked. Second, autonomy raises governance stakes. In delegated settings, the central question is often not whether the agent can act, but whether it should. The RSTA layer provides a structural choke-point to enforce shared autonomy and intelligent delegation [37,38,39], treating oversight actions (verify, ask, defer) as recommendables that compete directly with productive actions under constrained computational budgets.

Counterargument 2: RSTA is just offline RL or contextual bandits. 

A classical machine learning objection is that if the “user” is the agent state, the “item” is an action, and the “objective” is trajectory utility, the problem is mathematically identical to a Markov Decision Process. Under this view, RSTA is merely a rebranding of offline reinforcement learning or contextual bandits [9,40].

Response: While the mathematical DNA overlaps, RSTA provides a fundamentally distinct systems architecture and inductive bias. RL agents typically assume control over the policy and treat the environment as a passive transition function. In contrast, modern digital ecosystems are multi-stakeholder. A travel platform or enterprise SaaS actively wants to shape the agent’s behavior to respect inventory limits, load balancing, and platform safety. Recommender systems bring mature architectural solutions to this exact problem: decoupled two-tower models, efficient candidate generation pipelines, and multi-objective ranking functions that balance the agent’s utility against the service’s operational constraints [12].

Counterargument 3: RSTA is simply Retrieval-Augmented Generation (RAG) for tools. 

A common systems objection is that finding the right tool is just a vector search problem: embed the agent’s state, retrieve the top-K API schemas, and append them to the prompt.

Response: RAG optimizes for semantic similarity; RSTA optimizes for downstream trajectory utility. A pure semantic retriever cannot balance dynamic service-side constraints (e.g., rate limits, real-time inventory) against the agent’s budget. Furthermore, RAG retrieves passive documents, whereas RSTA ranks a heterogeneous space of executable interventions—including meta-actions like verify, ask, and escalate—that fundamentally alter the execution graph rather than just augmenting the context.

Counterargument 4: Infinite context windows will eliminate the need for filtering. 

As foundation models scale to millions of tokens, one might argue that an agent can simply ingest the entire candidate space (e.g., a whole product catalog or enterprise API directory) and evaluate it jointly.

Response: Even if context limits vanish, reasoning over massive action spaces introduces severe latency, cost, and attention degradation. More critically, the “infinite context” argument assumes the service provider is willing to transmit its entire dynamic backend state to the client agent. In reality, proprietary databases, dynamic pricing, and live inventory require a federated bottleneck. RSTA provides this necessary privacy-preserving interface, whether integrated locally with structured API responses or deployed explicitly as a service-side ranker.

Counterargument 5: Agent-to-service interaction should be deterministic, not probabilistic. 

Software engineering principles suggest that machine-to-machine communication should rely on deterministic routing and precise API contracts, not probabilistic recommendation slates.

Response: While the execution of an API must be deterministic, the discovery and selection of that API in an open ecosystem is inherently probabilistic. When a principal’s intent is ambiguous, or when thousands of overlapping services compete (e.g., booking a flight across multiple vendors), hard-coded deterministic logic is brittle. RSTA acts as the crucial probabilistic bridge between fuzzy human intent and deterministic machine execution.

6. Service-to-Agent Interfaces and Governance

It is important to clarify that the RSTA framework does not strictly require a complex, federated two-layer architecture. At its core, RSTA is simply the ranking of grounded interventions for an acting agent. However, as deployments scale, a natural service-facing pattern emerges to solve the information asymmetry problem. In many domains, the service knows something the local agent does not: inventory state, compatibility graphs, permission structure, reliability priors, pricing, or latent policy constraints. An agent-facing capability surface—acting as a service-side ranker—can therefore create value that local planning alone cannot reconstruct. The output need not be a passive list; it can be a machine-readable action slate with attached evidence, constraints, and executable affordances.

This is also why RSTA is governance-relevant. RSTH allocate scarce human attention. RSTA allocate scarce authorized agency. A weak RSTH wastes a click; a weak RSTA can overspend money, violate policy, execute the wrong configuration, or prioritize a brittle shortcut over a safe and intended workflow. Table 5 maps these ranking failures to concrete harms.

Some deployments may eventually separate agent-side and service-side rankers, while others may keep a single integrated ranking layer. That architectural choice should be treated as a future systems agenda rather than part of the core definition. The core definition is simpler: rank grounded interventions for an acting agent, and evaluate the resulting trajectory.

7. A Focused Research Agenda

The research agenda does not require an entirely new environment literally named “RSTA.” Existing agent environments already contain recommendation-shaped decisions. The near-term opportunity is to expose candidate inventories, rank productive and oversight actions jointly, and evaluate trajectory outcomes with the correct stakeholders in mind.

We emphasize five priorities, as outlined in Figure 3.

1.

Candidate-set reconstruction.

End-to-end agent benchmarks often hide feasible alternatives inside prompts, tool specifications, or environment code. RSTA work should make ${\Omega }_t$ explicit or deterministically reconstructable. Without that, it is hard to distinguish ranking quality from candidate-generation quality.

2.

Oversight as a recommendable.

Verify, ask, defer, sandbox, and escalate should compete directly against productive actions. This is the clearest methodological implication of Claim 3.

3.

Service-to-agent interface design.

If services increasingly face agents directly, then ranking becomes partly an interface problem: which objects, schemas, evidence packets, and executable affordances should be exposed, in what order, and with what guarantees?

4.

Multi-agent orchestration as recommendation.

Delegate choice, protocol choice, topology choice, and critic selection are ranking problems whenever they shape the trajectory of an agent team rather than merely backend plumbing [26,41,42,43,44,45].

5.

Interface-robust evaluation and governance.

Agentic performance is often sensitive to the harness rather than only the base model. RSTA evaluation should therefore report interface perturbations, side effects, approval events, and stakeholder outcomes, not only task success [46,47,48,49,50]. Appendix I provides a task card that makes candidate sets, recommendables, stakeholders, and trajectory metrics explicit.

8. Optimizing RSTA: From Clicks to Trajectories

Moving the immediate target of recommendation from humans to agents forces a fundamental shift in how systems learn and evaluate, transitioning from optimizing immediate, point-wise engagement signals (e.g., clicks, dwell time) over static offline datasets to optimizing delayed, multi-step trajectory utility within executable environments. The most profound methodological shift lies in supervision: whereas classical RSTH treat a skipped item as a soft negative and a click as a positive, RSTA must leverage grounded execution traces—where hallucinated tool calls, rollbacks, or unauthorized state mutations serve as severe hard penalties, and successful oversight actions (like verify) serve as highly positive signals even if they temporarily delay completion. This connects RSTA directly to modern preference learning via Direct Preference Optimization (DPO) [51,52,53,54,55] and offline reinforcement learning [56,57,58], where the objective is to reliably induce safer, cheaper, or faster task completion trajectories rather than satisfying human aesthetics. Finally, RSTA offer an evaluation advantage through executable counterfactuals; unlike human recommendation where unseen slates cannot be genuinely simulated, simulable RSTA environments (e.g., WorkArena-style tasks or OSWorld) allow researchers to execute alternative slates and strictly verify the causal impact of off-policy ranking interventions on downstream trajectory utility.

9. Broader Implications: Interfaces, Data, and Market Structure

The implication of this shift is conceptual as much as technical. Recommendation is moving from the screen into the loop. Once services and platforms interact directly with agents, the unit of optimization is no longer only what captures a person’s attention. It is also what productively and safely shapes an agent’s next reachable trajectory. That shift changes interfaces, supervision, and competition.

First, it changes interfaces. Agent-facing services need not merely wrap old APIs with natural-language endpoints. They may need structured, evidence-bearing, executable recommendation surfaces that expose bundles, constraints, and affordances in forms agents can consume efficiently. In many domains, the interface question and the ranking question become inseparable.

Second, it changes data flywheels. Human-facing recommenders learn from impressions, clicks, dwell time, and conversion. Agent-facing systems can learn from tool calls, arguments, retries, approval events, overrides, verifications, side effects, and task outcomes. That creates richer supervision, but it also raises the cost of ranking errors because the feedback loop is closer to real action.

Third, it changes market structure. If a growing share of digital interaction is mediated by agents, then services compete not only on human UX but also on being machine-readable, composable, verifiable, and trustworthy to agentic consumers. Metadata quality, provenance, policy transparency, and protocol participation become competitive dimensions. Recommendation research should engage with that transition directly rather than treating it as someone else’s infrastructure problem.

10. How the Claims can be Tested

To move beyond definitions, the most useful next step is a small experimental program that could falsify our framework. The three claims in Section 3 are designed to be tested with existing benchmark families plus modest additional instrumentation.

Testing Claim 1. 

Start from an environment with a modest action menu, such as tool selection or approval-choice settings, and hold the candidate inventory fixed. Then vary only the order of the slate delivered to the agent, while constraining the agent’s evaluation budget so that it can only inspect a top-K prefix or a bounded number of expensive checks. If trajectory utility changes materially under these interventions, then priority-sensitive ranking is doing real work even when menus are small.

Testing Claim 2. 

Compare two rankers on the same tasks and with the same principal-side context: one receives only agent-local state, while the other additionally receives service-private signals such as permissions, inventory, compatibility, reliability, or latent policy state. The relevant outcome is not merely next-step preference accuracy. It is whether access to service-private signals improves downstream utility in ways the local agent could not reconstruct alone.

Testing Claim 3. 

Evaluate two otherwise matched systems: one ranks productive and oversight actions in a common slate, while the other ranks productive actions first and applies guardrails only afterward. Then measure not only completion, but also approval efficiency, compliance, side effects, and human cleanup burden. If oversight-as-recommendable improves usable autonomy or reduces harmful interventions at comparable completion rates, then the post-hoc-guardrail view is incomplete.

11. Conclusions

Recommendation is moving from the screen to the execution loop, shifting the optimization unit from human attention to authorized machine agency. The central question is no longer what humans should see, but what acting agents should prioritize, verify, or delegate. As digital services expose agent-facing interfaces and planning remains constrained by compute and governance, an explicit RSTA layer becomes indispensable for safe, efficient operation. By ranking productive and oversight actions jointly, RSTA provides a robust foundation for next-generation interactive systems where trajectory utility, robustness, and strict governance are engineered directly into the slate.

Recommendation and interaction paradigms. 

Before agents became direct consumers of ranked interventions, recommender systems had already expanded well beyond static collaborative filtering to encompass deep learning [59]. Hybrid recommenders [60], matrix-factorization and pairwise-ranking formulations [3,4], sequential and transformer-based recommendation [5,7,61,62,63], conversational recommendation [10,11,64], multistakeholder recommendation [12], and causal or reinforcement-learning views of recommendation, including counterfactual estimators and slate optimization [9,13,40,65,66,67,68,69,70] all broadened what a recommender system can optimize. In parallel, interface-agent and mixed-initiative work treated personalization, delegation, and control transfer as first-class design problems [37,38,39,71,72,73,74,75,76]. Furthermore, early work on agent-mediated electronic commerce and shopbots [77,78,79,80] laid the economic groundwork for machine consumers, while classical principal-agent theory [81] formalizes the delegation risks. These literatures matter because RSTA inherit ranking questions from the former and autonomy questions from the latter.

Agent behavior, tool use, and evaluation. 

Recent agent work shifted from prompt-only interaction to tool use, reflection, web navigation, and long-horizon work tasks [17,18,82,83,84,85,86,87,88,89,90,91]. The evaluation ecosystem now includes generalist agent benchmarks such as AgentBench [92], workplace-style digital-worker environments such as TheAgentCompany [93], and broader surveys and infrastructure analyses of agent evaluation methodology [50,94,95,96,97]. For this paper, the key point is not benchmark performance per se; it is that these environments repeatedly expose explicit or recoverable choice points where ranking over grounded interventions affects downstream trajectories.

Interoperability, runtimes, and public ecosystems. 

Open protocols and runtime layers are making agent-facing interfaces more legible. Beyond the MCP and A2A announcements themselves [29,30], recent surveys synthesize emerging protocol families and their design trade-offs [31]. This matters because service-to-agent recommendation is partly an interface-design problem: what the service exposes, and how it exposes it, can affect both ranking quality and downstream execution.

Market and deployment context. 

Industry reports increasingly describe agents as a software and workflow layer rather than an isolated model feature. McKinsey’s state-of-AI and agentic-organization reports, Gartner’s enterprise-agent forecasts, Deloitte’s enterprise-adoption forecast, and Microsoft WorkLab’s digital-labor framing all point in that direction [27,28,32,33,34,35,36,98,99]. We also anticipate this extending to synthetic media and autonomous creative generation [100,101]. We use these sources only as directional timing signals, not as proof that any one interface design or market structure will dominate.

Appendix D.1. Shopping

Shopping makes preference elicitation, approval thresholds, and structured offers explicit. A buyer agent may need to clarify soft attributes such as acceptable substitutes, return-risk tolerance, or delivery urgency before acting [111,112]. It may also need to request human confirmation at salient thresholds, which aligns with broader human-AI interaction guidance on confidence, control transfer, and user trust [113,114]. Figure A1 visualizes this two-layer architecture, and Table A2 details a shopping-specific decomposition of the intervention space.

Figure A1. A shopping stack with an agent-side ranking layer and a service-side ranking layer. The agent-side layer contributes principal context and approval logic; the service-side layer contributes inventory, compatibility, and policy signals. This figure shows one important deployment pattern, not a claim that every RSTA deployment must contain both layers.

Figure A1. A shopping stack with an agent-side ranking layer and a service-side ranking layer. The agent-side layer contributes principal context and approval logic; the service-side layer contributes inventory, compatibility, and policy signals. This figure shows one important deployment pattern, not a claim that every RSTA deployment must contain both layers.

Table A2. A shopping-specific decomposition of Equation 2. The table makes the effective intervention space concrete for one service-facing domain.

Layer	Typical contents	Why it matters	Where it is often known best
Object layer $O_t$	products, sellers, substitutes, accessories, bundles	determines the feasible commercial options	service and cross-shop aggregators
Parameter layer ${\Theta }_t$	size, color, shipping, coupon, warranty, payment, return terms	changes utility even when the underlying product is fixed	service and principal jointly
Mode layer $M_t$	shortlist, compare, ask, reserve, cart, buy, wait, verify	determines whether the agent should act or seek more evidence	principal and policy layer
Delegation layer $D_t$	verifier, budget checker, comparison agent, human approval path	changes the reliability and governance of the trajectory	agent orchestration stack

Table A2. A shopping-specific decomposition of Equation 2. The table makes the effective intervention space concrete for one service-facing domain.

Layer	Typical contents	Why it matters	Where it is often known best
Object layer $O_t$	products, sellers, substitutes, accessories, bundles	determines the feasible commercial options	service and cross-shop aggregators
Parameter layer ${\Theta }_t$	size, color, shipping, coupon, warranty, payment, return terms	changes utility even when the underlying product is fixed	service and principal jointly
Mode layer $M_t$	shortlist, compare, ask, reserve, cart, buy, wait, verify	determines whether the agent should act or seek more evidence	principal and policy layer
Delegation layer $D_t$	verifier, budget checker, comparison agent, human approval path	changes the reliability and governance of the trajectory	agent orchestration stack

Appendix D.2. Travel

Travel adds high-cost commitment points, corporate policy constraints, and rebooking uncertainty. A travel agent often knows the principal’s calendar, layover tolerance, loyalty preferences, and approval rules, while a platform can rank fare bundles using private availability, fare rules, and partner-inventory signals. Figure A2 illustrates this dynamic.

Figure A2. Travel as service-to-agent recommendation. The platform ranks structured itinerary bundles for an agent that already knows dates, preferences, and authorization rules.

Figure A2. Travel as service-to-agent recommendation. The platform ranks structured itinerary bundles for an agent that already knows dates, preferences, and authorization rules.

Appendix D.3. Enterprise SaaS

Enterprise assistants add workflow state, permission structure, audit requirements, and approval routing. Here the recommendables are often not end-user-visible “items” at all, but workflow fragments, templates, connector choices, escalation paths, and approval actions. Figure A3 demonstrates this pattern.

Figure A3. Enterprise SaaS as service-to-agent recommendation. The service ranks executable workflow choices rather than merely presenting UI elements for a human operator.

Figure A3. Enterprise SaaS as service-to-agent recommendation. The service ranks executable workflow choices rather than merely presenting UI elements for a human operator.

Appendix D.4. Developer platforms

Developer platforms expose another high-value case. A coding agent may hold local code intent and repository context, while the platform can rank tools, test bundles, environments, reviewers, and rollback paths using CI state, compatibility information, and deployment-risk signals. Figure A4 maps this architecture, and Table A3 summarizes the parallel case studies across all these domains.

Figure A4. Developer platforms as service-to-agent recommendation. The platform can rank tool, verification, and rollout choices using signals that a local coding agent does not fully possess.

Figure A4. Developer platforms as service-to-agent recommendation. The platform can rank tool, verification, and rollout choices using signals that a local coding agent does not fully possess.

Table A3. Parallel domain case studies for service-to-agent recommendation. Each row instantiates the same core idea: the service-side layer can rank structured action opportunities for an acting agent using information that the principal-side agent may not fully possess locally.

Domain	What the service can rank for the agent	Important service-private or platform signals	Principal-side constraints	Representative resources
Shopping	products, sellers, bundles, coupons, shipping windows, return terms, compatibility checks, buy or reserve actions	inventory volatility, seller reliability, counterfeit risk, compatibility graphs, fulfillment likelihood	budget, brand exclusions, urgency, risk tolerance, approval threshold	WebShop, DeepShop, WebMall, AgenticShop [21,115,116,117]
Travel	itineraries, fare families, baggage bundles, hotel combinations, refund options, booking actions	seat availability, fare rules, rebooking frictions, partner inventory, corporate policy checks	dates, layover tolerance, loyalty preferences, travel policy, refund sensitivity	general web-agent environments provide partial travel analogues, especially for booking and itinerary-style web interaction [22,118]
Enterprise SaaS	workflow fragments, approval paths, document templates, connectors, escalation options	permission structure, compliance rules, org workflow state, template validity, connector health	delegated authority, SLA targets, audit requirements, team policy	WorkArena, WorkArena++, AssistantBench, and AppWorld provide close enterprise-workflow analogues [23,24,25,119]
Developer platforms	tools, test bundles, deployment targets, rollback actions, reviewer assignments, verifier workflows	CI state, dependency compatibility, environment health, repo policy, deployment risk	reliability threshold, code ownership, review rules, budget, sandbox policy	SWE-bench, SWE-agent, and OSWorld are the closest direct resources; AppWorld is a useful workflow analogue [23,120,121,122]

Table A3. Parallel domain case studies for service-to-agent recommendation. Each row instantiates the same core idea: the service-side layer can rank structured action opportunities for an acting agent using information that the principal-side agent may not fully possess locally.

Domain	What the service can rank for the agent	Important service-private or platform signals	Principal-side constraints	Representative resources
Shopping	products, sellers, bundles, coupons, shipping windows, return terms, compatibility checks, buy or reserve actions	inventory volatility, seller reliability, counterfeit risk, compatibility graphs, fulfillment likelihood	budget, brand exclusions, urgency, risk tolerance, approval threshold	WebShop, DeepShop, WebMall, AgenticShop [21,115,116,117]
Travel	itineraries, fare families, baggage bundles, hotel combinations, refund options, booking actions	seat availability, fare rules, rebooking frictions, partner inventory, corporate policy checks	dates, layover tolerance, loyalty preferences, travel policy, refund sensitivity	general web-agent environments provide partial travel analogues, especially for booking and itinerary-style web interaction [22,118]
Enterprise SaaS	workflow fragments, approval paths, document templates, connectors, escalation options	permission structure, compliance rules, org workflow state, template validity, connector health	delegated authority, SLA targets, audit requirements, team policy	WorkArena, WorkArena++, AssistantBench, and AppWorld provide close enterprise-workflow analogues [23,24,25,119]
Developer platforms	tools, test bundles, deployment targets, rollback actions, reviewer assignments, verifier workflows	CI state, dependency compatibility, environment health, repo policy, deployment risk	reliability threshold, code ownership, review rules, budget, sandbox policy	SWE-bench, SWE-agent, and OSWorld are the closest direct resources; AppWorld is a useful workflow analogue [23,120,121,122]