How can the output of one tool become the input to another tool?

The output of one tool can become the input to another tool by extracting the needed value from the first result, validating it, storing it in working state, and mapping it into the next tool's expected arguments.

This is one of the core mechanics behind multi-step agent workflows.

A simple example

Suppose the user asks:

“Find my unpaid invoice and create a payment link.”

The agent may first call:

search_customer(email)

The result might contain:

• customer_id = C123
• name = Rahul
• status = active

The next tool requires a customer ID:

get_unpaid_invoices(customer_id)

So the agent takes:

customer_id = C123

and passes it into the next call.

The whole output usually should not be forwarded

A tool may return many fields, while the next tool needs only one or two.

For example:

Tool 1 returns:

• customer_id
• name
• email
• address
• account_status

Tool 2 requires:

• customer_id

The agent should pass only the required value.

This keeps the workflow cleaner and reduces unnecessary context.

Structured outputs make this easier

Tool-to-tool transfer works best when tools return predictable structured data.

For example:

• customer_id
• invoice_id
• order_id
• file_path
• payment_url

These values are easier to extract reliably than information buried inside free-form text.

Field names may need mapping

The first tool and second tool may use different field names.

For example:

Tool 1 output: user_id

Tool 2 input: customer_id

The workflow may explicitly map:

customer_id = user_id

This mapping can be handled by the agent or by deterministic workflow code.

Validate before passing values forward

The agent should not assume that every returned value is valid.

Before using an output downstream, check things such as:

• is the field present?
• is the type correct?
• is the value empty?
• are there multiple possible matches?
• is the result authorized for the current user?
• is the value still valid or fresh?

For example, if search_customer returns three customers, the agent should not blindly pick the first ID.

Store important outputs in workflow state

Intermediate values can be stored in agent state.

For example:

• customer_id = C123
• invoice_id = INV42
• payment_url = https://...

Later tools can use these values without repeating earlier calls.

This makes the workflow more efficient.

Example of a longer chain

A multi-step flow might look like:

1. search_customer(email)

Returns customer_id = C123

1. get_unpaid_invoices(customer_id = C123)

Returns invoice_id = INV42

1. create_payment_link(invoice_id = INV42)

Returns payment_url

1. send_email(payment_url)

Sends the link to the customer

Each step produces a value that unlocks the next step.

The next tool should receive only trusted inputs

Not every value in a tool response should automatically become an argument.

For example, an external tool may return free-form text containing instructions.

Those instructions should not be treated as trusted commands.

Only validated data should be mapped into the next tool.

Deterministic workflows can perform the mapping

The model does not always need to handle field transfer itself.

A workflow engine may define:

output.customer_id → next_input.customer_id

This is useful when the relationship between steps is fixed and predictable.

It reduces unnecessary reasoning and makes the flow easier to test.

Model-based mapping is useful when interpretation is needed

Sometimes the output is less structured.

For example:

Tool result: “The primary account for this customer is ACC-42.”

The agent may need to interpret that text and extract:

account_id = ACC-42

Model reasoning can help here, but structured outputs are generally more reliable when available.

Missing data can change the flow

Suppose the first tool does not return the field needed by the next tool.

The agent may need to:

• call another tool
• ask the user for missing information
• choose a different path
• stop the workflow

The agent should not invent missing identifiers.

Type compatibility matters

A tool may return:

amount = "500"

while the next tool expects:

amount: number

The workflow should convert or validate the value before calling the next tool.

Passing incompatible values can cause downstream failures.

Arrays may need filtering

A tool may return multiple records.

For example:

get_unpaid_invoices

returns five invoice IDs.

The next step may need:

• all invoices
• only the oldest invoice
• only invoices above a certain amount
• one invoice chosen by the user

The agent must determine which values should move forward.

Tool outputs can be transformed

The value does not always need to be copied directly.

For example:

Tool 1 output: first_name = Rahul, last_name = Kumar

The next tool may require:

full_name = Rahul Kumar

The workflow can transform values before passing them onward.

Sensitive data should not flow unnecessarily

Suppose a customer lookup returns:

• customer_id
• email
• phone
• billing address

If the next tool only needs customer_id, there is no reason to forward all the other fields.

Passing the minimum required data reduces privacy and security risk.

Failed outputs should stop propagation

If a tool returns:

status = error

its output should not be treated as valid input for the next tool.

The workflow should first handle the failure.

Otherwise, one bad result can cause several downstream errors.

A practical transfer process

A reliable tool-to-tool handoff often looks like:

1. Execute Tool A.
2. Confirm Tool A succeeded.
3. Extract the required field.
4. Validate its type and meaning.
5. Store it in working state.
6. Map it to Tool B's input schema.
7. Validate Tool B's arguments.
8. Execute Tool B.

In short

The output of one tool becomes the input to another by extracting the required data, validating it, storing it in state, and mapping it into the next tool's expected schema.

Reliable agent systems pass only the necessary values, avoid inventing missing data, validate intermediate outputs, and use deterministic mappings whenever the relationship between tools is known in advance.