LLM outputting a trajectory?

OSS Product Help LangChain
1

Hi folks,

Are you aware of models to output a trajectory rather than tool calls?
By a trajectory I mean :

  • tool 1 with arguments

  • tool 2 without arguments fully defined, as it expected tool 1 to run first

  • tool 3 etc.

Since the calls are sequential you can’t compute the exact arguments for tool 2, you need to run tool first 1, but you could still have a rough idea where you going. So I wonder if some models are already able to think in terms of trajectory, built-into the model, rather than outputting tools in a sequential way.

Currently I think this would be done through planning but it’s not as reliable and fast as a tool call.

2

hi @eric-burel

1

look at this GPT-5 prompting guide

2

or a trajectory expressed as code by Anthropic Programmatic tool calling - Claude API Docs

3

or Google Gemini 3 supports multi-step sequential tool use within a single turn

4

or ReWOO pattern

https://arxiv.org/pdf/2305.18323

5

or plan-and-execute - generates a full multi-step plan upfront, then an executor carries out each step. An optional replanner revises remaining steps based on results

5

DAG https://arxiv.org/pdf/2312.04511

  • Directed - each edge has a direction (task A must run before task B)
  • Acyclic - no cycles (you can’t end up back at a task you already completed)
  • Graph - nodes (tasks) connected by edges (dependencies)
3

Hey @pawel-twardziak , thanks for having taken the time to share this very complete list ! I’ve finally had a chance to dig it.
More specificially, I am studying trajectory evaluation, and here are a few conclusions:

  • These tools are mostly relying on a form of reasoning to produce an execution plan, however this reasoning is not following a strict standard - it’s basically either bullet points in an AI message, a Python program (anthropic dynamic approach), or potentially a list of tasks (typically how AI assistant for coding work). It would be interesting that they actually produce partial tool messages for instance, that would be more concrete and allow real-time HIL intervention and standardized observability.
  • I plan to read the last article more thoroughly, but in my understanding modern implementations of ReAct architecture are already able to handle parallel tool calling, since the LLM can produce a list of tools, when the tool happens to be independent. So I don’t see the benefits of this compiler. I haven’t actually ever seen an agent calling multiple tools in my toy projects so I might be wrong? A more interesting scenario is when your tools are actually dependant, so you need to call tool A and B, and then only tool C and D with results from A and B, for instance, but the model could already figure that it will need to call [A,B] then [C,D]

Thanks again for this feedback, I’d make sure to quote you in my work.

1 Like