RCR-Router: Role-Aware Context Routing

• RCR-Router is a modular, role-aware context-routing framework for multi-agent LLM systems that dynamically selects relevant memory subsets to meet token constraints.
• It iteratively integrates agent outputs using heuristic scoring based on role, stage, and recency, ensuring optimal context delivery for each specialized agent.
• Experimental results demonstrate that RCR-Router reduces token usage by up to 47% while improving metrics like AQS and F1 compared to full-context and static routing methods.

RCR-Router is a modular, role-aware context-routing framework for multi-agent LLM systems that operate over a shared, structured memory and repeatedly refine that memory across interaction rounds. It is designed for settings such as multi-hop question answering in which specialized agents—such as a planner, retriever, reasoner, and synthesizer—must collaborate under strict token budgets. The framework addresses two coordination problems: context routing, namely deciding what portion of shared memory to send to each agent at each round, and iterative coordination, namely integrating agent outputs into memory and adapting routing across rounds. The system is positioned as an alternative to full-context routing and static routing, both of which are described as inefficient or insufficiently adaptive in growing multi-round workflows (Liu et al., 6 Aug 2025).

1. Problem setting and motivation

Multi-agent LLM systems are presented as a means of organizing collaboration among specialized agents to solve complex tasks such as multi-hop question answering. In this setting, two difficulties dominate. The first is that memory grows over rounds as plans, retrieved facts, intermediate reasoning, tool outputs, and messages accumulate. The second is that each agent’s context must fit within an allocated token budget. RCR-Router is introduced to address these constraints by dynamically selecting semantically relevant, role- and stage-conditioned subsets of memory under explicit token budgets, while iteratively integrating new outputs into shared memory (Liu et al., 6 Aug 2025).

The paper contrasts RCR-Router with two common coordination schemes. In full-context routing, every agent receives the entire shared memory each round. This wastes tokens, exposes irrelevant or redundant items, scales poorly with memory growth, and often slows inference due to inflated prompts. In static routing, each role receives a fixed, handcrafted context slice regardless of the evolving state. That design is token-efficient, but it lacks adaptability to task stage and round-to-round changes, so important new facts can be missed. RCR-Router is defined by opposition to both extremes: it preserves explicit budget control while adapting the routed context to role, stage, and recency.

A central premise of the framework is that memory heterogeneity matters. The shared store may contain text spans, YAML plans, graph triples, tables, tool outputs, and message history. A plausible implication is that routing quality depends not only on semantic similarity in the abstract, but also on whether the memory representation itself is structured in a way that supports fast indexing, filtering, de-duplication, and stage-aware selection.

2. System architecture and structured memory

RCR-Router is described as a context-routing layer inside a multi-agent LLM system. It operates over a Shared Memory Store $M$ that encodes structured agent interaction history, external knowledge, and state representations, including YAML blocks, graphs, and tables (Liu et al., 6 Aug 2025).

Its core modules are the Agent Manager, Memory Store, Token Budget Allocator, Importance Scorer, Semantic Filter and Context Assembler, Memory Update component, and Iterative Integration loop. The Agent Manager orchestrates roles, invocation order, and rounds; the Token Budget Allocator assigns per-agent budgets $B_i$; the Importance Scorer computes the relevance of each memory item to a given role and task stage; the Semantic Filter and Context Assembler construct the routed context $C_t^i$; and the Memory Update component extracts structure from agent outputs, filters redundancies, resolves conflicts, and writes back to the next-round store $M_{t+1}$.

The memory schema is explicit. Items may include facts, rationales, plans, tool outputs, and messages, with metadata such as id, type, role_tag, stage_tag, timestamp, token length, provenance/source, content hash, and optional semantic annotation. Content hashes are used for redundancy filtering, while role, stage, type, and timestamp support indexing and pruning. This structured-memory design is not auxiliary to routing; it is the substrate that makes routing cheap enough to run once per round and precise enough to expose only a relevant slice to each role.

Role-awareness is defined operationally. A planner needs the global instruction and prior subplans; a researcher or retriever needs planner intents and recent retrieval results; a reasoner needs selected evidence and subplans; and a synthesizer, summarizer, or recommender needs filtered evidence and validated reasoning steps. The framework also allows additional roles such as verifier and critic. By default, the system uses a shared memory $M_t$ rather than separate private stores, and visibility controls are treated as a design consideration implemented through tags, stage conditions, and role-based filters rather than through a distinct memory architecture.

3. Routing mechanism and iterative refinement

For each agent $A_i$ at round $t$, RCR-Router selects a context $C_t^i \subseteq M_t$ that maximizes role- and stage-relevance while respecting a token budget:

$$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$

The scoring policy is lightweight and heuristic. It combines role relevance, stage priority, and recency. Role relevance is binary: $\mathrm{Score}_{\mathrm{role}}(m)=1$ if $B_i$0 contains role-specific keywords for $B_i$1, and $B_i$2 otherwise. Stage priority is also binary: $B_i$3 if $B_i$4 belongs to the preferred types for $B_i$5, and $B_i$6 otherwise. Recency is exponentially decayed,

$B_i$7

These are combined into the weighted importance score

$B_i$8

with default $B_i$9. Budget allocation is role-aware and fixed-form:

$C_t^i$0

The selection problem is identified as NP-hard through its relation to $C_t^i$1 knapsack, and the implemented policy is greedy: sort memory items by descending $C_t^i$2 and pack them until the token budget is met. This is a key design choice. The method does not attempt globally optimal packing, but instead prioritizes low routing overhead relative to LLM inference cost.

Iterative refinement is the second defining mechanism. After each round, agent outputs $C_t^i$3 are integrated into the next memory state according to

$C_t^i$4

The update pipeline parses outputs, identifies facts, subplans, tool results, and intermediate reasoning steps, drops low-value or redundant items, structures retained content as YAML blocks, graph triples, or table rows, attaches metadata, and resolves conflicting facts or plans by priority-based replacement or merge with versioning. Because scoring in the next round uses updated role, stage, and recency information, newly relevant items can displace stale or redundant ones. The global objective is stated as balancing task success against total token cost across rounds and agents:

$C_t^i$5

A HotPotQA-style walkthrough in the paper illustrates the mechanism concretely. In round $C_t^i$6, the planner with $C_t^i$7 receives the user question plus minimal prior memory and outputs a plan with subgoal_1 and subgoal_2; these are written back as YAML plan items with stage_tag=planning. The searcher or retriever with $C_t^i$8 then receives the latest planner subgoals and relevant recent facts and writes tool_result items. In round $C_t^i$9, the reasoner with $M_{t+1}$0 receives recent plan and retrieval results and produces structured reasoning, while the recommender or synthesizer with $M_{t+1}$1 receives a concise, filtered slice of facts and reasoning and produces the final answer with brief justification. The routing policy stops adding items once the role budget is hit, preventing a full dump of all prior results to every agent.

4. Answer Quality Score

The paper introduces Answer Quality Score (AQS) as an output-aware evaluation metric intended to complement exact-match and token-overlap metrics. Its stated purpose is to evaluate explanation quality beyond EM and F1, specifically along the dimensions of correctness, relevance, completeness, and clarity (Liu et al., 6 Aug 2025).

AQS is an LLM-judged score in the interval $M_{t+1}$2 produced by a standardized evaluation prompt. The procedure takes a user query $M_{t+1}$3 and a generated answer $M_{t+1}$4, builds an evaluation prompt $M_{t+1}$5 with instructions to score and justify, runs an LLM scoring engine such as DeepSeek or GPT-4, parses the returned JSON, and extracts the scalar score. The paper treats the optional justification as auxiliary output rather than part of the metric itself.

The metric is motivated by a distinction between surface-level correctness and explanation quality. The paper gives an example in which two answers both achieve $M_{t+1}$6 and high F1, yet receive different AQS values because one is concise and accurate but unsupported, while the other includes supporting facts and clear reasoning. In that example, the first answer receives approximately $M_{t+1}$7 and the second approximately $M_{t+1}$8. The intended interpretation is that AQS captures cohesion and evidence alignment that standard answer-string metrics do not.

This introduces a specific evaluative stance toward multi-agent systems: quality is not exhausted by end answers alone, especially when the system is explicitly designed to decompose, retrieve, reason, and synthesize. A plausible implication is that routing methods that improve evidence exposure and reduce irrelevant context may show larger gains in AQS than in EM or F1, because explanation structure can improve even when final answer correctness is already high.

5. Experimental results

RCR-Router is evaluated on three multi-hop QA benchmarks: HotPotQA, MuSiQue, and 2WikiMultihop. The baselines are Full-Context Routing, Static Routing, and RCR-Router itself, with the latter tested in one-shot $M_{t+1}$9 and iterative $M_t$0 settings. In the summarized results, the per-agent budget is $M_t$1 (Liu et al., 6 Aug 2025).

On HotPotQA, Full-Context Routing uses $M_t$2 tokens, attains AQS $M_t$3, F1 $M_t$4, and runtime $M_t$5. Static Routing uses $M_t$6 tokens, AQS $M_t$7, F1 $M_t$8, and runtime $M_t$9. RCR-Router uses $A_i$0 tokens, AQS $A_i$1, F1 $A_i$2, and runtime $A_i$3. On MuSiQue, the corresponding results are Full: $A_i$4, $A_i$5, $A_i$6, $A_i$7; Static: $A_i$8, $A_i$9, $t$0, $t$1; RCR: $t$2, $t$3, $t$4, $t$5. On 2WikiMultihop, they are Full: $t$6, $t$7, $t$8, $t$9; Static: $C_t^i \subseteq M_t$0, $C_t^i \subseteq M_t$1, $C_t^i \subseteq M_t$2, $C_t^i \subseteq M_t$3; RCR: $C_t^i \subseteq M_t$4, $C_t^i \subseteq M_t$5, $C_t^i \subseteq M_t$6, $C_t^i \subseteq M_t$7.

The reported token reductions relative to Full-Context Routing are approximately $C_t^i \subseteq M_t$8 on HotPotQA, $C_t^i \subseteq M_t$9 on MuSiQue, and $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$0 on 2WikiMultihop. Aggregated across benchmarks, the paper states that RCR reduces tokens by $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$1–$$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$2 while improving or maintaining accuracy. It also reports that RCR has the lowest average runtime across datasets, with HotPotQA cited as an example: $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$3 for RCR versus $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$4 for Full. This is used to argue that the added routing computations impose negligible overhead relative to the inference savings from smaller prompts.

The ablations emphasize two sensitivities. First, token budget matters. For HotPotQA, AQS rises from $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$5 at $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$6 to $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$7 at $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$8, then saturates near $$\pi_{\mathrm{route}}(C_t^i \mid R_i, S_t, M_t) = \arg\max_{C' \subseteq M_t} \sum_{m \in C'} \alpha(m; R_i, S_t) \quad \text{s.t.} \quad \sum_{m \in C'} \mathrm{TokenLength}(m) \le B_i.$$9 at $\mathrm{Score}_{\mathrm{role}}(m)=1$0, while runtime and tokens increase monotonically. For MuSiQue, AQS rises from $\mathrm{Score}_{\mathrm{role}}(m)=1$1 at $\mathrm{Score}_{\mathrm{role}}(m)=1$2 to $\mathrm{Score}_{\mathrm{role}}(m)=1$3 at $\mathrm{Score}_{\mathrm{role}}(m)=1$4, with a mild gain to $\mathrm{Score}_{\mathrm{role}}(m)=1$5 at $\mathrm{Score}_{\mathrm{role}}(m)=1$6. Second, iterative depth matters. For both HotPotQA and MuSiQue, AQS peaks at $\mathrm{Score}_{\mathrm{role}}(m)=1$7, with HotPotQA reaching $\mathrm{Score}_{\mathrm{role}}(m)=1$8 and lowest tokens of $\mathrm{Score}_{\mathrm{role}}(m)=1$9, after which returns diminish beyond $B_i$00–$B_i$01 rounds. The implementation guidance in the paper therefore states that iterations $B_i$02 are typically at most $B_i$03 for the best trade-off, and routing occurs once per round, with iterative systems re-routing two to three times to refine contexts.

6. Comparisons, limitations, and prospective extensions

Relative to Full-Context Routing, RCR-Router is described as reducing token cost, latency, and redundancy while improving AQS and F1. Relative to Static Routing, it preserves efficiency but adds adaptability by aligning context to role and task stage. The paper’s broader claim is that role-aware, stage-conditioned routing under explicit token budgets is crucial for scalable multi-agent collaboration, and that structured memory plus iterative feedback enables progressive context refinement as the task evolves (Liu et al., 6 Aug 2025).

The limitations are explicit. The scoring policy is heuristic and may miss subtle semantic relevance; tuning $B_i$04, $B_i$05, $B_i$06, and $B_i$07 is task-dependent; role assignment errors or ambiguous stages can misroute context; weak extraction, structuring, or conflict resolution can propagate noise through memory; and the greedy $B_i$08-based selector ignores score-length ratio and diversity, leaving potential redundancy within the selected context. These are methodological rather than incidental constraints: the framework’s efficiency partly derives from the same simplifications that bound its routing fidelity.

The future-work agenda follows directly from those limits. The paper proposes learned routing policies, supervised or RL-based, to optimize $B_i$09 and budgeted selection; diversity-aware selection and redundancy penalties; privacy-preserving exposure controls and per-role visibility policies; enhanced structured memory with graph indices and entity linking; learned update strategies; and improved packing heuristics such as score-length ratio or beam-search knapsack approximations. This suggests that RCR-Router is best understood as a modular baseline architecture: a structured, budgeted routing layer whose current implementation is intentionally lightweight, but whose abstractions could support more sophisticated learned policies without changing the surrounding multi-agent system model.