Tool Execution<Support custom tool executors / tool execution interception>

[kardwalker]

Motivation

I'm evaluating Microsoft Agent Framework for an enterprise agent platform.

One requirement is that the framework should allow the LLM to decide which tool to call, but not execute the tool automatically.

Instead, I would like the build custom workflow to intercept the tool call, perform custom logic, execute the tool externally, and then return the result back to the agent.

This is needed for scenarios such as:

• RBAC / authorization (group by tenant id)
• Policy enforcement
• Approval workflows
• Audit logging
• Rate limiting
• Secret management
• Remote tool execution
• Custom security check on Tool Response

---

Desired execution flow

User
   │
   ▼
Agent
   │
   ▼
LLM
   │
   ▼
Tool Call
   │
   ▼
Host Application (intercept)
   ├── validate
   ├── RBAC
   ├── policy engine
   ├── approval
   ├── audit
   ├── execute tool
   ▼
Tool Result
   │
   ▼
Agent continues reasoning

The important part is that the framework should emit the tool call without executing it.

---

Current behavior

From the documentation, it appears that:

• tools can require approval
• after approval, the framework executes the tool

However, I couldn't find an extension point that allows replacing the default tool executor or intercepting every tool invocation before execution.

Another option would be exposing tool calls as events, allowing the host application to execute them and submit the result back to the agent.

---

Question

Is there already a supported way to implement this?

If not, is a custom tool execution pipeline or tool executor planned for a future release?

[armorer-labs]

This is the extension point I would want for the same class of enterprise platform use case. Approval-before-execution is useful, but it is not quite the same as host-owned execution.

The distinction I would make in the API is:

• the model proposes a tool call with a stable call id, normalized arguments, tool identity/version, and run/session context;
• the host receives that proposed call before any side effect occurs;
• the host can allow, deny, revise, route, rate-limit, require approval, or execute through an external service;
• the host submits a structured result back to the agent, including whether the original call was executed, replaced, denied, or failed;
• the framework preserves that decision in the event stream so audit and replay do not depend on scraping logs.

For RBAC, tenant policy, secret handling, or remote execution, the important property is that the framework does not collapse "LLM selected a tool" and "tool side effect happened" into one internal step. Those need to be separate states with an operation id between them.

A useful minimum contract would be something like a ToolCallProposed event plus a submitToolResult(callId, result) path, where the result has a small terminal taxonomy: executed, denied, canceled, revised, timed_out, failed. That makes approvals and audit logging much easier to reason about because the host can bind policy and human approval to the exact proposed operation, not just to the natural-language turn.

Disclosure: I work on Armorer Labs.

[moonbox3]

Hi @kardwalker,

Yes, for Python workflows the supported pattern for this is declaration-only tools plus the workflow request_info / responses handshake.

approval_mode="always_require" is a different feature: it pauses for approval, but once approved the framework executes the registered local tool. For host-owned execution, define the tool as a FunctionTool with func=None and an input schema. The schema is still advertised to the model, but there is no implementation for the framework to execute.

When the model selects that tool, the workflow pauses and emits a request_info event containing the function_call. The host can inspect the tool name, arguments, and call_id, run RBAC/policy/approval/audit/remote execution, then resume the workflow with a matching Content.from_function_result(...).

Sketch:

from agent_framework import Agent, Content, FunctionTool, WorkflowBuilder

lookup_customer = FunctionTool(
    name="lookup_customer",
    func=None,
    description="Lookup customer information through the host-controlled service.",
    input_model={
        "type": "object",
        "properties": {
            "customer_id": {"type": "string"},
        },
        "required": ["customer_id"],
    },
)

agent = Agent(
    client=client,
    instructions="Use lookup_customer when customer data is needed.",
    tools=[lookup_customer],
)

workflow = WorkflowBuilder(start_executor=agent).build()

result = await workflow.run("Find customer C123")
requests = result.get_request_info_events()

responses = {}
for event in requests:
    call = event.data
    args = call.parse_arguments()

    external_result = await execute_tool_externally(
        name=call.name,
        arguments=args,
        call_id=call.call_id,
    )

    responses[event.request_id] = Content.from_function_result(
        call_id=call.call_id,
        result=external_result,
    )

result = await workflow.run(responses=responses)

There is a sample of this exact shape in samples/03-workflows/human-in-the-loop/agents_with_declaration_only_tools.py.
If you do not need the workflow to pause, there is also an in-process interception point: FunctionMiddleware. Function middleware runs after the model has selected a FunctionTool and arguments have been parsed/validated, but before the underlying Python callable is invoked. A middleware can perform policy checks, execute through an external service, set context.result, and return without calling call_next(). That keeps the normal agent tool loop moving while replacing the actual tool execution path.

[ofsardarson92-code]

Tool Execution with support for custom tool executors and tool execution interception offers greater flexibility for adapting workflows to different needs. It allows users to customize how tools run while maintaining better control over execution. I’ve found this especially useful when exploring utilities like jjsploit, as a configurable execution system can improve organization, consistency, and the overall user experience.

[ofsardarson92-code]

Tool execution interception and support for custom tool executors make workflows more flexible and easier to customize. For users exploring automation, a Roblox script executor iOS solution with reliable execution, smooth compatibility, and consistent updates can improve the overall experience. When implemented thoughtfully, these features help create a more streamlined and user-friendly environment.