Tool name uniqueness alignment (company tools vs skill packs)
Context
Group discussion (Jul 20) between Qontak development and the AI team on whether AI agent
action / tool name values may be duplicated across company tools, skills, and agents.
Driven by the product requirement to expose tool_name to users, plus a naming mismatch
observed in the skill-pack refiner. Both the AI Team and Qontak's development team have
already aligned on the outcome.
Thread: https://chat.google.com/room/AAAAizggz-I/Hu3zHsgo4lA/Hu3zHsgo4lA?cls=10
Notes
- Eko Aprianto (9:30 AM) asked four questions: may tool
namebe duplicated (1) within company tools, (2) within a skill, (3) between a company tool and a tool inside a skill, (4) between one skill and another skill or another agent? - Wava Carissa Putri (11:26 AM) answered points 1 & 2: no duplicates — for the LLM the tool name is an identifier.
- Dhita Putri Pratama (1:00 PM), assuming the autonomous agent context:
- Point 3: because tools are created in an agent via a draft skill pack, and refining the skill pack populates tools into company tools, a company tool name may match a skill pack tool name as long as the essence/function refers to the same "tool".
- Point 4: likewise, a tool name in one skill may match one in another skill or agent, as
long as it is within the same
cidand the function genuinely refers to the same tool. - Noted that AI-service tool naming is already of the form
<nama>_<timestamp>(cmiiw), so names should already be unique (plus there is a tool id) unless they intentionally refer to the same tool.
- Eko Aprianto (1:24 PM): the case is that product wants
tool_nameexposed to the user, so technically the tool has to be copied and the user must renametool_name, because the user may edit the tool inside the skill. Asked whether for the non-autonomous ai-agenttool_namemay be the same across agents. - Eko Aprianto (1:45 PM): we cannot guarantee a company tool has the same parameters as
the one in the skill — so is the recommendation that the user always renames
tool_namewhen adding it into a skill? - Dimas Fauzi Hidayat (2:13 PM): when testing the refiner, asking it to change something
on the action side surfaced
<nama>_<timestamp>. User expectation is that what happens in configuration — down to the action name — appears 1:1 with what is in the refiner, so users are not confused/afraid when they named the action "Assign to Division" but<nama>_<timestamp>shows up. This is a naming concern. - Dhita Putri Pratama (3:41 PM): by process in AI service the tool name becomes the function name; the LLM reads the instruction and picks which function to call by the tool name. So the essentials are: (1) make sure the tool name is valid per Python convention, and (2) the tool name is 1:1 with its function — otherwise it errors.
Decisions / changes
- Eko Aprianto (3:49 PM), aligned by AI Team + Qontak development team: given the dynamic
behaviour that "a user can edit inside a skill without it reflecting to the company tool,
and vice versa", the most sensible rule is that every
tool_name— in company tools and inside skills — must be unique within one company. - Consequence: the user must edit
tool_nameinside the skill/capabilities every time they add a tool from company tools, so thetool_namediffers. - Tool names must be valid Python-convention identifiers and map 1:1 to their function.
- Open gap flagged by Eko: the
<nama>_<timestamp>display vs the user-authored action name is a gap between ai-service and the prototype page (the italicised part of his message).
Follow-ups
- Reflect the company-wide
tool_nameuniqueness rule in the relevant PRD/RFC for the autonomous AI agent (and the non-autonomous ai-agent action config, if separate) — TBD. - Resolve the
<nama>_<timestamp>vs user-facing action-name gap between ai-service and the prototype page; decide whether the exposedtool_nameis the raw function name or a display name — Eko Aprianto / Dimas Fauzi Hidayat. - Confirm whether the non-autonomous ai-agent follows the same uniqueness rule (question was asked but not answered explicitly in-thread) — TBD.