Anshul Mittal
Author directory2026
JTPRO: A Joint Tool–Prompt Reflective Optimization Framework for Language Agents
Sandip Ghoshal | Anshul Mittal | Jyotika Singh | Miguel Ballesteros | Weiyi Sun | Fang Tu | Shailender Singh | Yassine Benajiba | Fahad Shah | Sujeeth Bharadwaj | Sujith Ravi | Dan Roth
Findings of the Association for Computational Linguistics: ACL 2026
Sandip Ghoshal | Anshul Mittal | Jyotika Singh | Miguel Ballesteros | Weiyi Sun | Fang Tu | Shailender Singh | Yassine Benajiba | Fahad Shah | Sujeeth Bharadwaj | Sujith Ravi | Dan Roth
Findings of the Association for Computational Linguistics: ACL 2026
Large language model (LLM) agents augmented with external tools often struggle as number of tools grow large and become domain-specific. In such settings, ambiguous tool descriptions and under-specified agent instructions frequently lead to tool mis-selection and incorrect slot/value instantiation. We hypothesize that this is due to two root causes: generic, one-size-fits-all prompts that ignore tool-specific nuances, and underspecified tool schemas that lack clear guidance on when and how to use each tool and how to format its parameters. We introduce Joint Tool-Prompt Reflective Optimization (JTPRO), a framework for improving tool-calling reliability in trace-supervised settings by iteratively using rollout-driven reflection to co-optimize global instructions and per-tool schema/argument descriptions for accurate tool selection and argument instantiation in large tool inventories. JTPRO is designed to preserve only tool-local cues needed for correct disambiguation and slot filling. We evaluate JTPRO across multi-tool benchmarks, which account for different number of tools using three metrics: Tool Selection Accuracy (TSA), Slot Filling Accuracy(SFA), and Overall Success Rate(OSR) (correct tool + correct slots + correct values). JTPRO consistently outperforms strong baselines, including CoT-style agents, and reflective prompt optimizers such as GEPA by 5%–20% (relative) on OSR. Ablations show that joint optimization of instructions and tool schemas is more effective and robust than optimizing either component in isolation.
Scaling Enterprise Cloud Agents to Thousands of APIs: An Empirical Study of Agent Architecture and MCP Tool Boundaries
Sandip Ghoshal | Khalil Mrini | Maram Assi | Yadan Fan | Jyotika Singh | Miguel Ballesteros | Weiyi Sun | Anshul Mittal | Yassine Benajiba | Sujeeth Bharadwaj | Sujith Ravi | Dan Roth
Proceedings of the 2026 Conference on Empirical Methods in Natural Language Processing: Industry Track
Sandip Ghoshal | Khalil Mrini | Maram Assi | Yadan Fan | Jyotika Singh | Miguel Ballesteros | Weiyi Sun | Anshul Mittal | Yassine Benajiba | Sujeeth Bharadwaj | Sujith Ravi | Dan Roth
Proceedings of the 2026 Conference on Empirical Methods in Natural Language Processing: Industry Track
Enterprise cloud agents increasingly operate over thousands of APIs and SDK operations. Tool use therefore becomes a large-scale classification and grounding problem over API operations, not a simple function-calling task. Earlier production-derived architectures either expose broad operation catalogs to the model or hide selection inside planner agents, causing excessive context growth, repeated discovery calls, and preventable invocation errors. We propose the Operation-Visible Agent Architecture, which keeps operation search, schema inspection, validation feedback, and API invocation visible to a centralized ReAct loop through a deterministic Operation-Resolver MCP. We compare this architecture with lead-worker planning and ReAct-based execution variants to assess how agent orchestration and MCP tool-boundary design affect enterprise-agent performance. On internal cloud-management benchmark tasks spanning 280+ SDK clients and approximately 8K operations, the proposed architecture improves full-success rate from 68% to 77% over the production-derived baseline, while reducing total token usage by 54.1%, median latency by 43.3%, LLM calls by 37.8%, and tool errors by 52.4%. The main lesson is that, at enterprise API scale, tool-boundary design is not an implementation detail: parallel tool calling improves efficiency, but task success improves most when operation resolution remains visible to the main reasoning loop.