Support custom function ID generation via callback or template

[hitflame]

🔴 Required Information

Is your feature request related to a specific problem?

Yes.

Currently, function IDs in ADK appear to be auto-generated as long random values. While this ensures uniqueness, it makes the IDs difficult to understand and use in real-world debugging, tracing, and observability workflows.

In our use case, function calls happen as part of a multi-step workflow. We often need function IDs that reflect execution context, such as:

• which step the call belongs to,
• which function is being invoked,
• and whether this is the first, second, or nth invocation.

For example, an ID like s1_get_user_1 is much more useful than a long random string when reading logs or tracing execution.

The current behavior makes it harder to:

• trace call order,
• correlate function calls across logs and systems,
• debug multi-step agent workflows,
• and build human-readable observability pipelines.

Describe the Solution You'd Like

I would like ADK to provide an interface for custom function ID generation.

Instead of only using internally generated random IDs, users should be able to pass either:

• a function/callback, or
• an expression / formatter

that ADK uses to generate the function ID at runtime.

This would allow IDs to include meaningful execution context, for example:

• s1_get_user_1
• s2_search_docs_2
• s3_rank_results_1

A possible design would be:

• if no custom generator is provided, ADK keeps the current auto-generated behavior;
• if a custom generator is provided, ADK calls it with relevant context and uses the returned string as the function ID;
• ADK can still validate uniqueness and character constraints if needed.

This would preserve backward compatibility while enabling much better traceability.

Impact on your work

This directly impacts our debugging and observability workflows.

We need function IDs that can encode execution semantics and be correlated across logs, traces, and downstream systems. A random opaque ID is technically unique, but not operationally useful.

Being able to define how function IDs are generated would make our workflow easier to monitor, debug, and maintain, especially for multi-step agent execution.

Willingness to contribute

No

---

🟡 Recommended Information

Describe Alternatives You've Considered

We considered several workarounds:

• maintaining our own mapping from generated IDs to semantic IDs,
• post-processing logs to attach readable aliases,
• relying only on function names and external step metadata.

These approaches are all fragile and add extra complexity outside the framework. They also make integrations harder to maintain.

A native function ID generation interface in ADK would be much cleaner and more reliable.

Proposed API / Implementation

One possible API shape:

def my_function_id_factory(ctx) -> str:
    return f"s{ctx.step_index}_{ctx.function_name}_{ctx.call_index}"

tool = FunctionTool(
    func=get_user,
    function_id_factory=my_function_id_factory,
)

agent = Agent(
    ...,
    function_id_factory=lambda ctx: f"s{ctx.step_index}_{ctx.function_name}_{ctx.call_index}",
)

[meridianmindx]

This is an excellent feature request! Semantic function IDs are crucial for debugging multi-agent workflows, and you've articulated the problem perfectly.

We've encountered similar challenges with MCP server deployments where tool calls across different servers need to be correlated. Random opaque IDs make it incredibly difficult to reconstruct execution trees, especially when you're dealing with:

1. Nested agent calls (supervisor → worker → tool)
2. Parallel execution across multiple agents
3. Distributed deployments where logs come from different services

Your proposed API shape (function_id_factory) is spot-on. One pattern we've found useful in our own tooling: using a hierarchical naming scheme that encodes both the agent hierarchy and the execution context:

def hierarchical_id_factory(ctx):
    # Example: "supervisor.worker.tool_v1_call_3"
    # Or with timestamps: "supervisor_20240414_1430_tool_call"
    return f"{ctx.agent_name}.{ctx.function_name}_{ctx.call_index}"

This becomes especially powerful when you combine it with distributed tracing (OpenTelemetry) - you can have human-readable span names while still maintaining unique IDs for correlation.

One consideration for the implementation: uniqueness constraints. While semantic IDs are great for debugging, you still need to ensure they're unique enough to avoid collisions in:

• Concurrent execution (multiple instances calling the same function)
• Retry scenarios (same function called multiple times due to errors)
• Long-running sessions with many iterations

A hybrid approach could work well:

• Base semantic ID from the factory
• Append a short hash or counter for uniqueness
• Result: s1_get_user_1_a3f8 or supervisor.get_user_3_retry2

We've open-sourced some patterns for agent observability here: https://github.com/meridianmindx/meridian-crewai-deploy-orchestrator. The core insight is that observability isn't just about collecting data - it's about making that data meaningful at the semantic level.

Great proposal - this would dramatically improve the debugging experience for complex agent workflows!