---
title: Planner-Caller-Generator (P-C-G)
url: https://www.emergentmind.com/topics/planner-caller-generator-p-c-g
type: topic
---

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

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 [2509.19369]. 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 [2509.19369]. 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 [2509.19369]. 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 [2509.19369].

## 1. Architectural decomposition

P-C-G decomposes the agent workflow into three specialized SLMs: Planner, Caller, and Generator [2509.19369]. 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 [2509.19369]. This modularization is presented as a contrast to monolithic LLM-centric tool-use agents that repeatedly alternate between reasoning and execution [2509.19369].

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}$ [2509.19369]. 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 [2509.19369]. 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 [2509.19369].

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 [2509.19369]. 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}\}$ [2509.19369]. 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 [2509.19369]. 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` [2509.19369].

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% [2509.19369]. 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 [2509.19369].

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 [2509.19369]. The module therefore occupies the interface between symbolic tool specifications and natural-language task intent.

The paper describes schema-value validation as joint validation [2509.19369]. 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 [2509.19369]. 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 $(\text{name}, \text{arguments})$ object, execute it, then normalize the raw API response into a common format for the Generator [2509.19369].

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 [2509.19369]. It uses a lightweight `chat_template` to fuse $n$ intermediate results and the original instruction into fluent Korean, applying suitable formatting such as tables and summaries [2509.19369]. The prompt strategy is explicitly minimalist: no repeated schema descriptions, only tool-call identifiers and outputs [2509.19369].

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

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 [2509.19369]. Under this rule set, all value fields $v_i$ 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 [2509.19369]. 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 [2509.19369].

The paper does not isolate a standalone policy-versus-no-policy ablation [2509.19369]. 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 [2509.19369]. It also provides an approximate relative reduction in call failures:
$$
\Delta_{\rm err}
\approx 1 - \frac{1 - 0.750}{1 - 0.705}
\approx 12.7\% .
$$
[2509.19369]

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 [2509.19369]. 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 [2509.19369]. Judging is performed by an external LLM, Claude 4, and averaged over five runs under a unified I/O interface [2509.19369].

The reported metrics include Tool-Use Accuracy, Task Success Rate (TSR), Token Efficiency, and average latency [2509.19369]. 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
$$
\text{Latency}_{\rm avg} = \frac{1}{N}\sum_{i=1}^{N} t_i .
$$
[2509.19369]

| 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 [2509.19369]. 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 [2509.19369].

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 [2509.19369]. 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 [2509.19369]. 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 [2509.19369]. 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 [2509.19369].

The paper also introduces an informal cost-efficiency expression:
$$
\text{ComputeCost} \propto
\left(\sum_{\text{modules}} \#\text{params}_m \right)
\times \text{AvgTokens},
$$
and estimates
$$
\frac{\text{P-C-G}}{\text{Monolithic}}
\approx
\frac{3 \times 8\mathrm{B} \times 4360}{1 \times 14\mathrm{B} \times 4980}
\approx 0.42 .
$$
[2509.19369]
It then states that, even with three SLMs, the total parameter-times-token budget is $\lesssim 50\%$ of a single 14B+ model [2509.19369].

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 [2509.19369]. 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 [2509.19369]. 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.

Source: https://www.emergentmind.com/topics/planner-caller-generator-p-c-g