Planner-Caller-Generator (P-C-G)

• Planner-Caller-Generator (P-C-G) is an SLM-based agent architecture that segments tool-use tasks into specialized Planner, Caller, and Generator modules.
• The design employs an initial batch planning strategy with limited replanning, reducing token usage, latency, and associated costs.
• Integration of schema-value validation and a Korean-first value policy ensures accurate tool calls and efficient handling of language-specific tasks.

Searching arXiv for the specified paper and closely related tool-use agent papers. Planner-Caller-Generator (P-C-G) is an SLM-based agent architecture for tool use that separates planning, calling, and generation into role-specialized modules, with optimization for Korean tool-use settings (Jeon et al., 19 Sep 2025). In this design, the Planner produces an initial batch plan with limited on-demand replanning, the Caller returns a normalized call object after joint schema-value validation, and the Generator integrates tool outputs to produce the final answer (Jeon et al., 19 Sep 2025). The architecture is motivated by the observation that monolithic LLM-centric agents, including ReAct and Toolformer, repeatedly interleave reasoning and calls, which incurs high token use, latency, and cost, especially as the tool set grows (Jeon et al., 19 Sep 2025). P-C-G addresses this by reducing prompt size per module, avoiding redundant tokenizing of tool descriptions, and lowering overall compute in Korean-first environments (Jeon et al., 19 Sep 2025).

1. Architectural decomposition

P-C-G decomposes the agent workflow into three specialized SLMs: Planner, Caller, and Generator (Jeon et al., 19 Sep 2025). The Planner issues one up-front plan, with limited replanning only when needed; the Caller handles only schema-validated calls; and the Generator fuses results into the final response (Jeon et al., 19 Sep 2025). This modularization is presented as a contrast to monolithic LLM-centric tool-use agents that repeatedly alternate between reasoning and execution (Jeon et al., 19 Sep 2025).

The paper expresses the overall workflow in algorithmic form. Given instruction $I$ and tool catalog $T$, the system initializes an empty context, invokes the Planner to obtain $(\text{plan}, \text{next})$, and enters a loop while $\text{next} = \texttt{caller}$ (Jeon et al., 19 Sep 2025). The Caller is then applied to the current tool and accumulated context, the tool is executed, and the result is checked for validity against the plan; invalid or mismatched results trigger replanning, whereas valid results are appended to context and the plan progresses through its tool chain (Jeon et al., 19 Sep 2025). If $\text{next} = \texttt{conclusion}$, the Generator is called with the instruction and context to produce the final answer; otherwise the system returns a limit message (Jeon et al., 19 Sep 2025).

This suggests that P-C-G is not merely a pipeline but a controlled state machine in which role separation constrains information flow. A plausible implication is that specialization allows each module to operate on a smaller, more targeted prompt representation than a monolithic agent would require.

2. Planner semantics and control flow

On first invocation, the Planner SLM ingests the user’s Korean query as instruction and a tool_info list containing the name and short description of each available API (Jeon et al., 19 Sep 2025). It emits a single tool_chain, defined as an ordered list of tool names, together with a control flag $$next \in \{\texttt{caller}, \texttt{reject}, \texttt{conclusion}\}$$ (Jeon et al., 19 Sep 2025). The paper characterizes this as initial batch planning.

Replanning is intentionally limited. It is triggered only when a tool call fails or returns an unexpected format, when an intermediate result contradicts the planned sequence, or when a missing-parameter or missing-function condition is detected mid-flow (Jeon et al., 19 Sep 2025). In such cases, the Planner is reinvoked with the original instruction plus newly discovered constraints, such as “tool X not found” or an erroneous output, yielding an updated tool_chain (Jeon et al., 19 Sep 2025).

The efficiency rationale is explicit: by avoiding per-call replanning, unlike $P \rightarrow C \rightarrow P \rightarrow C$ loops in ReAct, total tokens spent on {tool_info, text} drops roughly 12–22% (Jeon et al., 19 Sep 2025). The paper further reports that this single-plan strategy attains the highest “As-planned” rate, 92.3%, and the lowest Over-planning, 1.6%, and directly connects these outcomes to token and latency savings (Jeon et al., 19 Sep 2025).

A common misconception would be to treat the Planner as performing continuous deliberation before every tool call. The architecture instead emphasizes one initial plan plus constrained replanning, making plan stability itself a measured property.

3. Caller normalization and schema-value validation

The Caller maps each planned tool into a normalized call object,

$\Call{Call}{} = \bigl(\text{tool\_name}, \{p_i : v_i\}_{i=1}^n \bigr),$

with inputs that include the current dialogue messages and the target tool’s JSON schema, including properties, required fields, types, and enums (Jeon et al., 19 Sep 2025). The module therefore occupies the interface between symbolic tool specifications and natural-language task intent.

The paper describes schema-value validation as joint validation (Jeon et al., 19 Sep 2025). It enforces the presence of all required $p_i$, type checks such as string, integer, and object, and value constraints including enum membership, regex patterns, and min/max conditions (Jeon et al., 19 Sep 2025). The workflow is presented in three steps: synthesize candidate $\{p_i:v_i\}$ via the Caller SLM; apply schema checks and signal reject or missing parameter on violation; and package the valid $T$0 object, execute it, then normalize the raw API response into a common format for the Generator (Jeon et al., 19 Sep 2025).

This normalized-call design is central to P-C-G’s division of labor. The Caller does not perform answer generation; it produces a validated execution object. A plausible implication is that this separation reduces ambiguity between tool-selection errors, argument-construction errors, and final response errors, allowing module-level evaluation under deterministic outputs.

4. Generator fusion and response construction

The Generator receives a minimal context comprising three turns: system metadata, the user request, and the assistant’s list of tool calls and results (Jeon et al., 19 Sep 2025). It uses a lightweight chat_template to fuse $T$1 intermediate results and the original instruction into fluent Korean, applying suitable formatting such as tables and summaries (Jeon et al., 19 Sep 2025). The prompt strategy is explicitly minimalist: no repeated schema descriptions, only tool-call identifiers and outputs (Jeon et al., 19 Sep 2025).

The paper states that the Generator avoids direct enumeration by summarizing via SLM reasoning (Jeon et al., 19 Sep 2025). In training terms, the Generator uses the base SLM without additional fine-tuning, and no new loss functions are reported (Jeon et al., 19 Sep 2025). Coherence and factual grounding are attributed to the standardized context format and the underlying pretrained weights (Jeon et al., 19 Sep 2025).

This indicates that the Generator is designed primarily as a post-execution synthesis layer rather than as a planner or tool interface. A plausible implication is that the architecture seeks factual grounding from standardized tool outputs rather than from additional task-specific optimization of the final-language module.

5. Korean-first value policy

A defining feature of P-C-G is the Korean-first value policy (Jeon et al., 19 Sep 2025). Under this rule set, all value fields $T$2 remain in Korean by default, except for a narrow whitelist of schema-defined fields that explicitly require English, such as certain enumerations or regex fields (Jeon et al., 19 Sep 2025). The stated purpose is to prevent unintended Korean-to-English code switching, including in personal or place names, because such switching otherwise leads to backend execution failures in Korean settings (Jeon et al., 19 Sep 2025).

The paper does not isolate a standalone policy-versus-no-policy ablation (Jeon et al., 19 Sep 2025). It nevertheless reports overall Call Accuracy of 75.0%, which is described as fully +4.5 points above GPT-4o-mini and largely attributable to fewer format errors in Korean contexts (Jeon et al., 19 Sep 2025). It also provides an approximate relative reduction in call failures:

$T$3

(Jeon et al., 19 Sep 2025)

The significance of the policy is domain-specific rather than universal. It is not presented as a general multilingual alignment method; rather, it is a schema-aware convention for Korean queries and Korean tool or parameter specifications. This suggests that language-localized value handling can be a first-order systems issue in tool-use agents, not merely a surface-level prompting preference.

6. Evaluation protocol and empirical results

The evaluation uses 400 Korean queries evenly split into Single-chain, Multi-chain, Missing Parameters, and Missing Functions scenarios (Jeon et al., 19 Sep 2025). Two settings are defined. Setting I is end-to-end evaluation with live APIs on 300 tasks, excluding Missing Parameters; Setting II is module-level evaluation with deterministic API outputs to isolate Caller and Generator quality (Jeon et al., 19 Sep 2025). Judging is performed by an external LLM, Claude 4, and averaged over five runs under a unified I/O interface (Jeon et al., 19 Sep 2025).

The reported metrics include Tool-Use Accuracy, Task Success Rate (TSR), Token Efficiency, and average latency (Jeon et al., 19 Sep 2025). Tool-Use Accuracy is defined as correct calls divided by total calls, TSR is the proportion of queries where intent is addressed, tools are used logically, and the answer is complete, and average latency is

$T$4

(Jeon et al., 19 Sep 2025)

System	Plan As %	Call Acc %	TSR %
GPT-4o-mini	89.6	70.5	79.3
Qwen3-14B	89.5	68.6	76.9
Ours (P-C-G)	92.3	75.0	79.7

The same summary reports token usage of 3747.6 for GPT-4o-mini, 4980.6 for Qwen3-14B, and 4360.3 for P-C-G (Jeon et al., 19 Sep 2025). In scenario-level results, Single-chain Call Accuracy is 95.6% for P-C-G versus 86.0% for GPT-4o-mini; Multi-chain Call Accuracy is 33.8% versus 33.0%; and Missing Functions Accuracy is 91.2%, which is reported as best (Jeon et al., 19 Sep 2025).

These results support a nuanced interpretation. P-C-G is not uniformly dominant across every subcase, but it combines the highest reported planning alignment, the highest Call Accuracy, and slightly higher TSR than GPT-4o-mini under the stated protocol (Jeon et al., 19 Sep 2025). The Multi-chain result, where the margin is small, indicates that longer dependency chains remain difficult even within the specialized architecture.

7. Cost efficiency, positioning, and limitations

P-C-G uses an 8B-parameter SLM per module, while the baselines are described as using 14–32B models (Jeon et al., 19 Sep 2025). The paper reports token usage of 4.36K for P-C-G versus 4.74K–5.34K for other SLMs, corresponding to a 12–22% reduction (Jeon et al., 19 Sep 2025). Reported latency is 9.1 s for P-C-G versus 7.9–9.6 s, which is characterized as competitive given the smaller parameter scale (Jeon et al., 19 Sep 2025).

The paper also introduces an informal cost-efficiency expression:

$T$5

and estimates

$T$6

(Jeon et al., 19 Sep 2025) It then states that, even with three SLMs, the total parameter-times-token budget is $T$7 of a single 14B+ model (Jeon et al., 19 Sep 2025).

The comparative position advanced by the paper is therefore specific: role-specialized SLMs are a cost-effective alternative for Korean tool-use agents, with competitive tool-use accuracy and end-to-end quality, reduced tokens, and acceptable latency (Jeon et al., 19 Sep 2025). At the same time, the evaluation assumptions are narrow by design: Korean queries, Korean tool and parameter specifications, live and deterministic settings separated for analysis, and LLM-as-a-Judge aggregation over five runs (Jeon et al., 19 Sep 2025). A plausible implication is that generalization beyond Korean-centric tool environments would require additional evidence, particularly because the Korean-first value policy is tightly coupled to the target deployment setting.