Shape the future of IBM watsonx Orchestrate
Start by searching and reviewing ideas others have posted, and add a comment (private if needed), vote, or subscribe to updates on them if they matter to you.
If you can't find what you are looking for, create a new idea:
stick to one feature enhancement per idea
add as much detail as possible, including use-case, examples & screenshots (put anything confidential in Hidden details field or a private comment)
Explain business impact and timeline of project being affected
[For IBMers] Add customer/project name, details & timeline in Hidden details field or a private comment (only visible to you and the IBM product team).
This all helps to scope and prioritize your idea among many other good ones. Thank you for your feedback!
Specific links you will want to bookmark for future use
Learn more about IBM watsonx Orchestrate - Use this site to find out additional information and details about the product.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hi Laurent,
Thanks for following up. To clarify on both points:
1. "Existing tools that don't want to re-architect them", yes, the concern is that moving to async would require updating tools to support a callback URL pattern (and adjusting error handling accordingly). For Verizon's case, several long-running tools are already deployed against sync expectations, and re-architecting them to async would be non-trivial. Configurable per-tool sync timeouts would let them keep the existing tool contracts intact.
2. "Custom vs. OOTB MCP servers", the long-running tools driving this request are remote MCP servers built on Langflow (referenced in the original RFE description), so custom-built rather than OOTB third-party (GitHub, Jira, etc.).
Thanks,
Francisco
Would support for asynchronous tools address your pain point better? While allowing time-out configuration is difficult - we can allow tools to be designated as asynchronous. As a result, the timeout duration should become immaterial
Request
Verizon needs the ability to configure individual timeouts for tool calls in watsonx Orchestrate.
Business Justification
Enterprise agent workflows often call multiple tools, and each tool may have a different latency profile, backend dependency, business criticality, or failure mode. A single global timeout is too rigid for production-grade orchestration.
For example, a lightweight lookup tool may be expected to return in a few seconds, while a complex backend operation, search process, approval workflow, or enterprise system call may legitimately require more time.
Individual timeout controls would allow Verizon to tune agent behavior based on the characteristics of each tool and the expectations of each workflow.
Impact if Not Delivered
Without individual configurable timeouts, Verizon may experience unnecessary failures for slower tools, excessive waiting for tools that should fail fast, or limited control over how agent workflows behave under latency or dependency issues.
This can negatively impact user experience, reliability, and confidence in production agent deployments.
Business Value if Delivered
Individual tool-call timeout controls would improve reliability, resiliency, and operational control for enterprise agent workflows.
This would allow Verizon to better manage backend dependencies, isolate failures, optimize user experience, and safely scale more complex agentic use cases in production.
We can consider for on-prem (not SaaS), will follow-up.