How to pass inputs from flow action tool to catalog item tool in AI agent

[ShivaPraniA]

I am working to build an AI Agent. I have used 2 tools:
1. Catalog item
2. Flow action
Previously when I used a sub flow instead of flow action, it was working fine. But my senior suggested to try it with flow action tool. Now it is not working. The problem is not with the flow action. When I tested it separately it is working fine. But I think the catalog item is not taking input from the flow action output variables.
So there are 2 sys_ids returned in the string format and in the catalog item they are reference variables.
I have given in the instructions and in tool description as well clearly. But it seems not to work.
Is there anything wrong in what I'm doing ?
Please let me know. It'll be useful for me.

here are the instructions that I've given to the AI Agent :

You are a ServiceNow Group Access Request Assistant.

Your objective is to help request access to ServiceNow groups.

Follow these steps for every group access request:

1. Extract the following information:
- Requested user
- Requested group
- Business justification

2. The requested user may provide:
- User name or
- User ID

Never ask for a sys_id.

3. The requested group will be provided as a group name. Do not consider the word "group" as part of the actual group name.

Never ask for a sys_id.

4. If a reason is present in the user's request, automatically use it as the business justification.

Examples:
- because he is new to the team
- because she needs access for incident support
- for project onboarding
- to support database administration

Do not ask for business justification again if it is already present.

5. Run the "Checking group access eligibility before submitting the catalog item request" flow action tool.

Pass:
- requested_for
- requested_group
- business_justification
as inputs from collected information from user.

6. Review the outputs:
- is_eligible
- message
- current_groups
- resolved_user_sys_id
- resolved_group_sys_id

7. If the output variable "is_eligible" is "false":
- Display the "message" output from the flow action output in a user-friendly manner.
- Do not submit the catalog item.
- Ask for the correct information. After 3 incorrect information provided by the user, end the conversation.

8. If the output variable "is_eligible" is "true":
Display a summary similar to:

"'I found "requested_for" user.

Current group memberships:
• "current_groups" output variable

Requested group:
• "requested_group"

Business justification:
• "business_justification"

The user is eligible for the requested access."'

9. Do not ask the user for confirmation.

10. Use:
resolved_user_sys_id and resolved_group_sys_id are the sys_id of user and group for the reference variables requested_for and requested_group in the catalog item.
- business_justification = use the business justification collected earlier.
Pass these as inputs for the tool "Submit Request Group Access catalog item" and submit the catalog item request.

11. After successful catalog item submission, provide a friendly confirmation.

Example:

The group access request has been submitted successfully and is now awaiting approval.

12. Never directly add users to groups.

13. Never ask again for information that was already collected during the conversation.

This is the catalog item description:

After executing the flow action "Checking group access eligibility before submitting the catalog item request" and if "is_eligible" is true only then submit the Request Group Access catalog item request.

When submitting the catalog item:
- Use the sys_id from "resolved_user_sys_id" from flow action tool "Checking group access eligibility before submitting the catalog item request" output. And pass it as input for requested_for reference variable.
- Use the sys_id from "resolved_group_sys_id" from flow action tool "Checking group access eligibility before submitting the catalog item request" output. And pass it as input for requested_group reference variable.
- Map business_justification to the justification collected from the requester.

After successful submission, provide a clear confirmation that the request has been submitted and is awaiting approval.

This is the flow action tool description:

Validate a group access request.

This action:
- Resolves the requested user
- Resolves the requested group
- Retrieves current group memberships
- Verifies user and group validity
- Checks whether the user is already a member of the requested group

Outputs:
- is_eligible
- message
- current_groups
- resolved_user_sys_id
- resolved_group_sys_id

If the output variable "is_eligible" = "false", do not execute the tool "Submit Request Group Access catalog item" and do not submit the Request Group Access catalog item. Inform the user that he/she is not eligible and display the "message" output.

If the output varibale "is_eligible" = "true", only then execute the tool "Submit Request Group Access catalog item" and submit the catalog item request.

[kmohammed]

Nothing is wrong with the idea, but the handoff itself is the weak point: two separate agent tools do not share values the way a Flow does. The agent is guessing, from text, what to pass next. That is almost certainly why the subflow version worked and the two-tool version does not.

With a subflow, the eligibility check and the catalog submission were one deterministic sequence: the same flow held resolved_user_sys_id and resolved_group_sys_id and passed them on directly. Once you split that into two independent tools, the agent has to read the flow action outputs and then re-enter them as catalog item inputs. Instructions and tool descriptions help, but they do not guarantee that the agent copies the exact sys_id, in the exact format, into the exact reference variable. A common failure is the agent passing a user name, a group name, or an empty value instead of the sys_id, or passing a sys_id into the wrong variable.

Recommended pattern: keep the handoff inside Flow Designer, not in agent instructions.

1. Expose one tool to the agent that runs a flow which does the whole sequence: validate eligibility, and only if is_eligible is true, submit the catalog request using the resolved sys_ids. Return the result and the message to the agent.

2. Keep the agent instructions simple: collect the user, group, and business justification, call that one tool, and report its result. Do not ask the agent to copy sys_ids between tools, and do not let it submit the catalog item directly.

3. Keep the eligibility gate in the flow, not in a prompt. If is_eligible is false, the flow stops and returns the message, so no catalog request can be created even if the agent makes a mistake.

If you need to keep two tools for now, debug it in this order before changing more instructions:

1. Test each tool on its own. You already confirmed the flow action works alone. Next, test the catalog item tool on its own with known sys_ids for a user and a group, to confirm its reference variables accept sys_id values in the format you are passing.

2. Check the agent execution log for a failed run. Look at what the agent actually passed to the catalog item tool: was it the sys_id, a name, or nothing at all? That one detail usually identifies the break.

3. Align names and types exactly. The flow action output names, the catalog item variable names, and the values the agent sees must match. A string sys_id that the catalog tool treats as a display value rather than a reference value will fail or resolve to the wrong record.

In short: do not rely on the language model to carry sys_ids between tools. Let Flow Designer carry them, and let the agent only collect the request and report the outcome. That is also the safer design for the eligibility rule, because the no-submit-when-ineligible check is enforced by the flow rather than by prompt wording.