Tool Runtime은 함수 호출 목록이 아니다

Key takeaways

• The model's tool request is only a suggestion and the actual execution must be controlled by the runtime.
• tool runtime is divided into registry, schema validation, permission gate, executor, and result formatter.
• Read-only tools can be parallelized, but write tools must preserve order.
• Errors and rejections should also be made model-visible results so as not to break the loop.

In this article, we will look at tool runtime.

In an AI agent, a tool is not a simple list of functions. If the model requests “I want to call this tool with these arguments,” the runtime must verify that the request is actually possible. You need to verify that the tool name is correct, that the input schema is valid, that it can be run with the current permissions, and that it is safe to run in parallel.

If you look at Claude Code-type agents from a runtime perspective, tool execution is an independent layer separated from the model loop.

1. Tool request is a suggestion, not an execution command.

A model can “request” a tool call. However, it is up to the application to decide whether to run it or not.

Models can make the following mistakes:

• Create a tool name that does not exist.
• Omitting required arguments.
• Requests a dangerous shell command.
• The file writing order is misjudged.
• I am trying to send sensitive information to an external service.

So a tool request is not an execution command, but rather a suggestion for the runtime to review.

2. Capability registry design

A registry defines “what can run.”

As more tools become available, the registry and executor need to be separated. The registry is a list of possible functions, and the executor is responsible for how to process this request.

3. Schema validation and error messages

Input validation is required before running the tool. Schema validation is not a simple type check but is part of model feedback.

If an incorrect input is received, the runtime should not break the loop with an exception, but should create an error result that the model can understand.

1# How to read: The items below are summarized examples to quickly check the action flow.2Request: file_read(path=null)3→ schema validation failed4to tool result: path must be a string5to model can be retried with different arguments

4. Permission gate and execution order

You should not run it immediately after the schema has passed. Authority judgment is required.

Permission judgment must look at the risk level of the tool itself, input values, current permission mode, workspace trust, user rules, and organizational policy.

5. Parallel and serial execution

Running all tools in parallel is fast. But it's not safe. Read-only tools can be parallelized, but the order of writing files or executing shells is important.

The criterion for parallelization is not speed, but side effects.

6. Result formatter and reinjection

The tool results have different screen output and model-visible messages. A short summary is good for the screen, but the model needs structured observations to make further inferences.

The tool results must contain at least the following information:

• Original tool request id
• Success/Failure
• Model-readable summary of results
• If there is an error, the cause
• Content with sensitive information removed
• Audit summary to leave on the ledger

7. tool runtime viewed through concept code

The code below is newly written code for explanation purposes.

1# How to read: Conceptual code that describes runtime boundaries, not a clone of the actual implementation.2class CapabilitySpec:3    # Initializes runtime dependencies and state storage that the object will reference in later steps.4    def __init__(self, name, schema, risk, can_run, execute, format_result):5        self.name = name6        self.schema = schema7        self.risk = risk8        self.can_run = can_run9        self.execute = execute10        self.format_result = format_result11 12# Processes a single tool request through validation, permission evaluation, execution, and result formatting steps.13async def execute_tool_request(request, runtime):14    spec = runtime.capabilities.find(request.name)15    if spec is None:16        return ToolResult.error(request.id, "This tool cannot be used.")17 18    parsed = spec.schema.validate(request.arguments)19    if not parsed.ok:20        return ToolResult.error(request.id, parsed.message)21 22    if not spec.can_run(runtime.context):23        return ToolResult.error(request.id, "The tool is disabled in the current run mode.")24 25    decision = await runtime.permissions.evaluate(spec, parsed.value)26    await runtime.ledger.write("permission_decision", decision.summary())27 28    if not decision.allowed:29        return ToolResult.denied(request.id, decision.reason)30 31    try:32        raw_output = await spec.execute(parsed.value, runtime.execution_context)33        return spec.format_result(request.id, raw_output)34    except Exception as error:35        return ToolResult.error(request.id, summarize_error(error))36 37# Read-only tools run in parallel, and tools with side effects run in sequence.38async def execute_tool_batch(requests, runtime):39    readonly, ordered = split_by_side_effect(requests, runtime.capabilities)40 41    for result in await run_parallel(readonly, lambda req: execute_tool_request(req, runtime)):42        yield result43 44    for req in ordered:45        yield await execute_tool_request(req, runtime)

Here, error, rejection, and success all becomeToolResult. The key is not to break the loop, but to create observations that can be used for the next model inference.

8. Practical checklist

1# How to read: The items below are summarized examples to quickly check the action flow.2tool runtime Checklist3 4[ ] View tool requests as suggestions to be reviewed, not as execution commands.5[ ] The capability registry and executor are separated.6[ ] Tool name lookup failure also produces a result message.7[ ] Schema validation failure returns to model-visible error.8[ ] Permission check occurs immediately before actual execution.9[ ] read-only can be parallelized, and write preserves order.10[ ] Tool results are divided into screen summary, model message, and ledger summary.11[ ] unknown risk tools are conservatively treated as requiring serialization or approval.

Case of failure: Matching only the tool name and omitting the execution policy

The most common failure is passing the tool definition to the model and deciding, "Now this is a function calling." It works fine in the initial demo. The model selectsread_file, enters the path, and runtime reads the file and returns the result. But problems soon arise in real products. The reader and writer tools run simultaneously in the same queue, permission checks are only performed on UI buttons but not on the executor, and failed tool calls are not left in the transcript.

In this structure, the runtime fluctuates the moment the model creates an invalid argument. For example, if a tool likedelete_cachetakes an optionalscopeargument and schema validation is lax, an empty scope could be interpreted as deleting the entire cache. Alternatively, tools marked as read-only may update the refresh token internally, creating a side effect. Even if the model is not malicious, if the tool's risk rating is not expressed at runtime, it becomes an operational incident.

Implementation example: Specifying pre-execution checkpoints

tool runtime must have at least the following order. The key is to not turn model requests straight into function calls.

1ToolRequest2-> name lookup3-> schema validation4-> capability policy5-> permission check6-> concurrency planner7-> executor8-> normalized ToolResult

1type Risk = "read" | "write" | "external" | "destructive";2 3type ToolCapability = {4  name: string;5  risk: Risk;6  schemaVersion: string;7  requiresApproval: boolean;8};9 10function canExecute(capability: ToolCapability, mode: "auto" | "review") {11  if (capability.risk === "destructive") return false;12  if (capability.requiresApproval && mode === "auto") return false;13  return true;14}

Even this small amount of separation allows the runtime to determine whether the tool can be parallelized, whether user approval is required, and how to explain failure to the model. The important thing is thatcanExecutemust be a policy shared by both the UI and the executor. Even if you block it on the screen, if the executor doesn't check again, there will be a bypass route.

Operational example: Securely exposing a file writer

Let's say we expose thewrite_filetool in our coding agent. Although this tool appears to simply be a function that takes a path and content, it requires at least four checkpoints at runtime. First, check if the path is in the workspace. Second, distinguish whether the target file is created or modified. Third, check if writing is possible in the current authorization mode. Fourth, after execution, the diff and result summary are left in the transcript.

Without this flow, it would be difficult for users to determine the cause when a model accidentally creates an absolute path, overwrites an entire existing file, or runs the same operation twice. In particular, if you only treat “tool execution failure” as an exception, the model will not see the cause of the failure. Failures should also be normalized toToolResultto provide observation values ​​necessary for the next decision, such as "could not write due to permissions," "schema is incorrect," and "target file is outside the workspace."

The point of comparison is clear. An agent that only has a list of function calls becomes more dangerous as more tools are attached to it. On the other hand, an agent with a capability registry and permission gate can consistently manage the risk level and execution conditions of each tool even as the number of tools increases.

finish

tool runtime is the agent's point of contact with the outside world. Rather than immediately executing the model request, the runtime must verify, approve, and record product-level reliability.

The next article covers the last lines of defense: permissions, transcript, and cost. These three are not additional features but core layers that determine agent productivity.