Pith. sign in

REVIEW 4 major objections 6 minor 44 references

Action Engine: Automatic Workflow Generation in FaaS

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Action Engine shows that a structured, tool-augmented LLM pipeline can turn plain-language queries into FaaS workflows with accuracy comparable to direct few-shot prompting, while producing platform- and language-neutral workflow…

desk verdict A useful FaaS workflow generation system whose headline comparison to few-shot LLM baselines is built on an exact-match oracle the authors themselves show to be non-unique. read the letter →

arxiv 2411.19485 v2 pith:GXALB7FP submitted 2024-11-29 cs.DC cs.AIcs.LGcs.SE

Akiharu Esashi , Pawissanutt Lertpongrujikorn , Shinji Kato , Mohsen Amini Salehi This is my paper · ORCID
classification cs.DCcs.AIcs.LGcs.SE
keywords FaaSworkflowgenerationlargelanguagemodelstool-augmentedLLMsdatadependencymanagementdirectedacyclicgraphserverlesscomputingfunctionselectionplatform-agnosticworkflows
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes Action Engine, a system that turns plain-language developer queries into executable Function-as-a-Service (FaaS) workflows. Its central claim is that a structured pipeline—task planning, function retrieval and selection, parameter classification, and platform-neutral DAG construction—performs as well as direct few-shot prompting with GPT-4o on the Reverse Chain benchmark, while adding portability across cloud platforms and languages. The system compiles its generated DAG into executable Argo workflow definitions and can expose the result through an API endpoint for execution. If the claim holds, developers without deep cloud expertise or platform-specific syntax knowledge could generate and deploy workflows automatically, shortening cloud-native development cycles.

What carries the argument

The load-bearing object is the platform-agnostic DAG as the universal workflow representation, together with the parameter-classification rule that constructs its edges. Given subtasks $S = LLM\_plan(q, Q)$, the function selector retrieves top-$k$ candidates by cosine similarity and lets the LLM choose $f_i^* = LLM\_select(q, s_i, F_i^{1..k})$. For each parameter $p_{ij}$, the workflow generator computes $t_{ij} = LLM\_classify(p_{ij}, \theta)$, where $\theta$ is the set of semantic descriptions of outputs from earlier nodes; if $t_{ij} = Input$, an edge $(n_s, n_i)$ is added from a synthetic start node, and if $t_{ij} = Output(n_k)$, an edge $(n_k, n_i)$ is added from the producing node. These edges form $DAG = \langle N, E \rangle$, and a DAG compiler translates the neutral structure into a specific orchestrator such as Argo. This mechanism replaces implicit reasoning about connections with explicit, deterministic data-dependency edges.

What would settle it

Run the 300 filtered Reverse Chain instances through a real FaaS execution environment, replacing each ground-truth API with a stub that records calls, and compare the final results and side effects of Action Engine's generated workflows with the reference solutions. If a large fraction of workflows that the exact-match metrics mark wrong still produce identical correct behavior, the paper's reported F1 and LCS scores misstate the true accuracy comparison.

Watch

Extended reading notes

Core claim

The paper's core discovery is that automatic FaaS workflow generation decomposes cleanly into four sub-processes, and that a system implementing them explicitly can match, and in some metrics surpass, the strongest prompting baselines while keeping generated workflows platform-neutral. Action Engine represents each workflow as a DAG whose nodes are (subtask, selected function) pairs and whose edges are built by classifying every function parameter as either a direct user input or an output of an earlier node. The platform-neutral DAG is then compiled into a specific orchestrator format. On 300 filtered Reverse Chain instances, Action Engine achieves F1 scores of 34%, 38%, and 42% for function selection across the three difficulty levels, comparable to the GPT-4o FewShot and FewShot CoT baselines, and it holds the highest stable LCS score for topological ordering while maintaining a 100% pass rate at every Top-K setting. The paper also reports that apparent accuracy rises with complexity because longer workflows offer more chances to match the reference, and its own ablation finds that multiple valid workflows exist for many queries, so exact-match evaluation against a single reference understates true correctness.

Load-bearing premise

The evaluation assumes each benchmark query has a single correct workflow that can serve as exact-match ground truth, even though the paper's own ablation shows that many queries have several equally valid workflows.

Editorial extensions

If this is right

  • Developers can request a workflow in plain language and receive a deployable API endpoint, with no need to learn platform-specific workflow syntax.
  • A single generated workflow description can be recompiled for different cloud orchestrators, so multi-cloud portability and migration no longer require rewriting the workflow.
  • The system's pass rate stays at 100% even when the function repository offers more candidates, while direct LLM prompting degrades in syntactic validity, suggesting that structured compilation rather than a larger candidate set is what guarantees executable output.
  • Because user inputs are separated from function-produced values, the same generated workflow can run for different users and arguments, making it reusable rather than hard-coded.
  • The finding that a code-specialized open model performs far worse than GPT-4o implies that workflow generation requires decomposition and dependency reasoning, not just code-generation skill.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If correctness were judged by the final output of a workflow instead of exact match to one reference solution, Action Engine's reported F1 and LCS scores would likely rise, and the relative ranking of the top methods could shift in ways the current metrics cannot reveal.
  • The parameter-classification machinery is a reusable recipe for API composition beyond FaaS, applying to any tool-augmented agent that must chain tools with explicit dataflow rather than implicit reasoning.
  • A natural next experiment is to run the compiled Argo workflows on a real orchestrator against stub functions and compare end results, since the paper evaluates generated structure only, not execution behavior.
  • The comparable-accuracy result depends heavily on GPT-4o for key decisions; replicating the pipeline with open-weight models would likely require extra prompt engineering or fine-tuning, so the claim should not be read as model-independent.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes Action Engine, a tool-augmented LLM system that translates natural-language developer queries into DAG-based, platform-agnostic FaaS workflows. The pipeline decomposes queries into subtasks, retrieves candidate functions via embedding cosine similarity with an LLM re-ranking step, classifies each function parameter as either a user input or an output of a preceding function, and then compiles the resulting DAG into orchestrator-specific workflow definitions. The evaluation uses a filtered subset of 300 examples from the Reverse Chain dataset and compares Action Engine against GPT-4o and Qwen-Coder baselines under zero-shot, few-shot, zero-shot CoT, and few-shot CoT prompts, plus a reproduced Reverse Chain method, using F1 and LCS metrics. The central claim is that Action Engine achieves accuracy comparable to the GPT-4o few-shot baselines while adding language- and platform-agnostic workflow generation. The paper also includes ablations on dataset ambiguity, top-k retrieval size, and data-dependency accuracy, and it openly discusses the limitations of exact-match evaluation against a single reference workflow.

Significance. If the central claim survives scrutiny, the work is a useful contribution to automated FaaS workflow generation: it provides an open-source framework, a clean DAG abstraction that decouples workflow construction from platform-specific syntax, and a systematic breakdown of the four sub-processes that prior tool-augmented-LLM work tends to treat monolithically. The paper also deserves credit for explicitly demonstrating, in Section 6.3.1 and Figure 5, that the Reverse Chain benchmark admits multiple functionally equivalent workflows, and for advocating functionally grounded evaluation. These are constructive observations that go beyond the primary system. However, the headline claim of accuracy parity is currently hostage to an evaluation oracle that the authors themselves show to be ambiguous, and the absence of execution-level validation, repeated trials, and error bars means the empirical contribution is suggestive rather than established.

major comments (4)
  1. [§6.1.2, §6.2, §6.3.1, Figure 5] The headline claim of "comparable accuracy" in Section 6.2 is not established because the F1 and LCS metrics are exact-match scores against a single reference workflow, while Section 6.3.1 and Figure 5 demonstrate that the benchmark contains multiple valid solutions. The paper's own example shows that Action Engine's prediction TopRestaurants → GetRestaurantMenu is functionally equivalent to the ground-truth FindRestaurant → GetMenu but is scored as incorrect. Please apply a functionally grounded metric or an explicit multiple-valid-solutions scoring procedure to the headline results, or reframe the claim as "structural similarity to one reference" rather than accuracy.
  2. [§6.1.2, §7, Table 1] The manuscript states in Section 6.1.2 that the dataset does not include function code or online APIs, so execution results cannot be verified, and Section 7 excludes execution performance from scope. Because the system's stated goal is executable FaaS workflows, the absence of an execution-level oracle (even a mock API runtime) leaves the accuracy claim unvalidated against the actual task. Table 1's pass rate measures only syntactic validity and should not be described as evidence of executable correctness without additional runtime validation.
  3. [§6.1.1, §6.2] The evaluation reports a single set of scores with no error bars, multiple seeds, or statistical significance tests. LLM-based generation is stochastic, and with only 300 examples the observed differences between Action Engine and FewShot (GPT-4o), such as 42% vs. 45% F1 at Level 3, are within plausible sampling noise. Please report mean and variance over repeated runs with fixed temperature/sampling settings, and state the sampling configuration in the experimental setup.
  4. [§4.2] The cosine similarity threshold of 0.7 is a free parameter that the authors selected "based on our initial experiments" on the same benchmark. No sensitivity analysis or ablation is provided for this threshold, even though it determines which functions are passed to the LLM selector and therefore directly affects the headline results. Please either provide a threshold sensitivity study or argue more carefully that this choice is not tuned to the specific test set.
minor comments (6)
  1. [Figure 4] The y-axis label in panel (c) reads "LCD" but should be "LCS"; the figure also appears to contain "uni00A0" artifacts in the legend.
  2. [§6.3.4] The claim of a "nearly threefold increase" in data dependency F1 after constraining function selection should be supported with the exact before/after numbers rather than left to visual inference from Figure 8.
  3. [§6.3.1] The explanation that more decision points increase the chance of exact-match correctness is counterintuitive and is not backed by a formal null-model analysis; a small simulation with random node selection would make the argument much more persuasive.
  4. [References] Reference [3] is a Google Scholar search URL rather than a citable source for Amazon States Language, and reference [14] for Argo Workflows points to the Google Cloud Composer URL. Both should be corrected to authoritative and stable sources.
  5. [Abstract and Section 3] Several typos remain, including "lodels" in the abstract and "returns it back" in Section 3.3; a copyediting pass is needed.
  6. [§6.2] The statement that "Action Engine surpasses other methods in both function selection and topological correctness" is stronger than the reported data, since FewShot (GPT-4o) achieves a higher F1 at Level 3; rephrase to "comparable or higher" or qualify the claim by complexity level.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Action Engine is evaluated empirically against an external benchmark, and no central claim reduces to a fitted parameter or self-citation.

full rationale

I walked the paper's derivation chain and found no step that makes a 'prediction' or 'first-principles result' equivalent to its own inputs by construction. The system's components (Task Planner, Function Selector, Workflow Generator, DAG Compiler) are evaluated empirically on the Reverse Chain dataset; no parameter is fitted to the target accuracy metrics in a way that forces the reported comparison. The cosine similarity threshold of 0.7 is described as a design choice 'based on our initial experiments' (Section 4.2), but it is not a fitted parameter renamed as a prediction; it filters candidate functions before the LLM selection and does not by construction determine the F1, LCS, or dependency scores. The paper's self-citations ([11], [12], [36]) are background or future-work references, not load-bearing justifications for the central claim. The limitation passages are evaluation-validity concerns rather than circularity: Section 6.3.1 admits that 'ensuring a singular, absolute reference path remains an unrealistic expectation' and Section 7 states that 'developer intervention and verification remain essential,' but these undermine the strength of the empirical claim without making it circular. The experiment is self-contained against an external benchmark, and the claim of comparable accuracy to FewShot baselines is an empirical finding that could in principle fail, which is the opposite of a circular derivation.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The central claim rests on the validity of the evaluation dataset and on several LLM reliability assumptions. The only hand-tuned numeric parameter is the cosine similarity threshold of 0.7 used in function retrieval. No invented physical or formal entities are introduced.

free parameters (1)
  • Cosine similarity threshold for function retrieval = 0.7
    Set in Section 4.2 based on initial experiments. This threshold filters candidate functions before LLM selection and affects the final accuracy, but its impact is not analyzed in the ablation.
assumptions (3)
  • domain assumption Semantic similarity between subtask descriptions and function descriptions is a reliable proxy for functional correctness
    The Function Selector (Section 4.2) retrieves candidates via cosine similarity before LLM selection. If embeddings fail to surface the right function, the LLM cannot correct it. The paper does not evaluate retrieval quality independently.
  • domain assumption The filtered Reverse Chain dataset contains a single valid ground truth workflow per query
    Used for exact-match evaluation in Section 6.1. The authors themselves question this in Section 6.3.1, noting multiple valid solutions exist, which undermines the reliability of the reported metrics.
  • domain assumption LLMs can reliably decompose queries and classify data dependencies from descriptions alone
    Task Planner (Section 4.1) and Parameter Classification (Section 5.1) rely entirely on in-context LLM reasoning without execution feedback. The paper's results show data dependency F1 is lower than function selection, indicating this assumption is only partially met.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Action Engine: Automatic Workflow Generation in FaaS." pith.science (2026). https://pith.science/paper/GXALB7FP

@misc{pith2026241119485,
  author       = {Pith},
  title        = {Pith review of: Action Engine: Automatic Workflow Generation in FaaS},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GXALB7FP}},
  note         = {Machine review of arXiv:2411.19485}
}
read the original abstract

Function as a Service (FaaS) is poised to become the foundation of the next generation of cloud systems due to its inherent advantages in scalability, cost-efficiency, and ease of use. However, challenges such as the need for specialized knowledge, platform dependence, and difficulty in scalability in building functional workflows persist for cloud-native application developers. To overcome these challenges and mitigate the burden of developing FaaS-based applications, in this paper, we propose a mechanism called Action Engine, that makes use of tool-augmented large language models (LLMs) at its kernel to interpret human language queries and automates FaaS workflow generation, thereby, reducing the need for specialized expertise and manual design. Action Engine includes modules to identify relevant functions from the FaaS repository and seamlessly manage the data dependency between them, ensuring the developer's query is processed and resolved. Beyond that, Action Engine can execute the generated workflow by injecting the user-provided arguments. On another front, this work addresses a gap in tool-augmented LLM research via adopting an Automatic FaaS Workflow Generation perspective to systematically evaluate methodologies across four fundamental sub-processes. Through benchmarking various parameters, this research provides critical insights into streamlining workflow automation for real-world applications, specifically in the FaaS continuum. Our evaluations demonstrate that the Action Engine achieves comparable performance to the few-shot learning approach while maintaining platform- and language-agnosticism, thereby, mitigating provider-specific dependencies in workflow generation. We notice that Action Engine can unlock FaaS workflow generation for non-cloud-savvy developers and expedite the development cycles of cloud-native applications.

Figures

Figures reproduced from arXiv: 2411.19485 by the authors.

Figure 1
Figure 1. The high-level overview of Action Engine. The developer submits the workflow description to Action Engine to automatically generate the workflow and return the ready-to￾use API endpoint backed by the FaaS platform and workflow orchestrator. Provider Dependence: FaaS applications are tightly cou￾pled with provider-specific APIs, tools, and orchestration frameworks, introducing a significant platform dependence. Altho… view at source ↗
Figure 2
Figure 2. Comparison between the four standard steps of tool-augmented LLMs vs the proposed processes for the FaaS workflow automation. flow, and reproducibility. Recall that tool-augmented LLM workflows follow a four-stage process: task planning, tool selection, tool invocation, and response generation. While effective for general-purpose applications, these stages are not held for the complexities of FaaS workflows that re￾… view at source ↗
Figure 3
Figure 3. Overview of the Action Engine architecture for FaaS workflow generation and execution. The system comprises two main modules: (1) Text-to-Workflow, which interprets user queries and constructs platform-agnostic DAGs through components such as LLM Engine, Function Identifier, Workflow Generator, and finally DAG Compiler turns it into the platform-specific workflow. (2) Workflow Execution, which deploys and executes t… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Measuring workflow correctness of Action Engine against the following baselines: Zero-Shot, Zero-Shot CoT, Few-Shot, Few-Shot CoT (each evaluated using both GPT-4o and Qwen-Coder-32B-Instruct), and Reverse Chain. These variations are evaluated against the same FaaS dat…
Figure 5
Figure 5. Figure 5: Example of multiple correct solutions in the Reverse Chain dataset. often do not account for this probabilistic effect, leading to a misinterpretation of the relationship between complexity and accuracy. While this may seem unexpected, further analysis re￾veals that th…
Figure 6
Figure 6. Figure 6: Precision and recall comparison for function selection and data dependency tasks. Reverse Chain shows high recall but low precision, reflecting a tendency to over-select, while Action Engine and FewShot (GPT-4o) offer more balanced performance. top-10 top-20 top-30 top…
Figure 7
Figure 7. Figure 7: Impact of increasing Top-K candidate functions on workflow generation performance. Method top-10 top-20 top-30 top-40 ActionEngine 100 100 100 100 FewShot 91 99 84 81 FewShot-CoT 99 99 98 92 ReverseChain 59 59 57 55 [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: Data dependency F1 scores across the top three methods (FewShot, FewShot CoT, and Action Engine) after constraining function selection to the ground truth function set. threefold increase in accuracy across all methods. This sig￾nificant improvement underscores the cri…
Figure 9
Figure 9. Figure 9: The prompt used in Task Planner to divide a user-provided query into actionable sub-tasks. SYSTEM_PROMPT = f''' Instruction: User Request: {user_query} Given a user request. Your goal is to divide the user request into subtasks if the user request is a compound workloa…
Figure 10
Figure 10. Figure 10: The prompt used in Func Selector to select the most aligned function to a subtask description from candidate functions. SYSTEM_PROMPT = f''' Instruction: Objective: {user_query}, Subtask: {task_list[i]}, Available APIs: {extracted_data} Given a Subtask, and Available …
Figure 12
Figure 12. Figure 12: Both Few-Shot and Few-Shot-CoT prompts templates used in evaluations follow the same structure with Zero-Shot and Zero-Shot-CoT format, respectively, with Few-Shot and Few-Shot-CoT incorporating an additional example of Argo Workflow generation demonstrations shown be…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 26 canonical work pages

  1. [1]

    https://aws.amazon.com/pm/lambda/,

    Aws lambda. https://aws.amazon.com/pm/lambda/, . Accessed: 2025- 03-10

    work page 2025

  2. [2]

    https://aws.amazon.com/step-functions/,

    Aws step functions. https://aws.amazon.com/step-functions/, . Ac- cessed: 2025-03-10

    work page 2025

  3. [3]

    https://scholar.google.com/scholar?hl=en&as_sdt=0%2C44&q= Amazon+States+Language+&btnG=

    Using amazon states language to define step functions work- flows. https://scholar.google.com/scholar?hl=en&as_sdt=0%2C44&q= Amazon+States+Language+&btnG=. Accessed: 2025-03-10

    work page 2025

  4. [4]

    https://airflow.apache.org/.Accessed:2025-03-10

    Apacheairflow. https://airflow.apache.org/.Accessed:2025-03-10

    work page 2025

  5. [5]

    https://learn.microsoft.com/en-us/azure/ azure-functions/durable/,

    Azure durable functions. https://learn.microsoft.com/en-us/azure/ azure-functions/durable/, . Accessed: 2025-03-10

    work page 2025

  6. [6]

    https://azure.microsoft.com/en-us/products/ functions,

    Azure functions. https://azure.microsoft.com/en-us/products/ functions, . Accessed: 2025-03-10

    work page 2025

  7. [7]

    https://cloud.google.com/composer,

    Cloud composer. https://cloud.google.com/composer, . Accessed: 2025-03-10

    work page 2025

  8. [8]

    https://cloud.google.com/functions,

    Cloud run functions. https://cloud.google.com/functions, . Ac- cessed: 2025-03-10

    work page 2025

Show all 44 references
  1. [9]

    Cloud Object Storage | Amazon S3 – Amazon Web Services

    Amazon. Cloud Object Storage | Amazon S3 – Amazon Web Services. https://aws.amazon.com/s3/. Online; Accessed on 11 June. 2024

    2024

  2. [10]

    Language models are few-shot learners

    TomBrown,BenjaminMann,NickRyder,MelanieSubbiah,JaredD Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. Language models are few-shot learners. Advances in neural information processing systems , 33: 1877–1901, 2020

    1901

  3. [11]

    Harnessing the poten- tial of function-reuse in multimedia cloud systems.IEEE Transac- tions on Parallel and Distributed Systems, 33(3):617–629, 2021

    Chavit Denninnart and Mohsen Amini Salehi. Harnessing the poten- tial of function-reuse in multimedia cloud systems.IEEE Transac- tions on Parallel and Distributed Systems, 33(3):617–629, 2021

    2021

  4. [12]

    Efficiency in the serverless cloud paradigm: A survey on the reusing and approximation aspects

    Chavit Denninnart, Thanawat Chanikaphon, and Mohsen Amini Salehi. Efficiency in the serverless cloud paradigm: A survey on the reusing and approximation aspects. Journal of Software-Practice and Experience (SPE), 53(10):1853–1886, 2023

    2023

  5. [13]

    Asurveyonin-context learning

    Qingxiu Dong, Lei Li, Damai Dai, Ce Zheng, Zhiyong Wu, Baobao Chang,XuSun,JingjingXu,andZhifangSui. Asurveyonin-context learning. arXiv preprint arXiv:2301.00234, 2022

    2022 arXiv

  6. [14]

    Argo Workflows.https://cloud.google

    Cloud Native Foundation. Argo Workflows.https://cloud.google. com/composer. Online; Accessed on 23 Aug. 2024

    2024

  7. [15]

    Robotic process automation

    Peter Hofmann, Caroline Samp, and Nils Urbach. Robotic process automation. Electronic markets, 30(1):99–106, 2020

    2020

  8. [16]

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang,TianyuLiu,JiajunZhang,BowenYu,KaiDang,etal. Qwen2. 5-coder technical report.arXiv preprint arXiv:2409.12186, 2024

    2024 arXiv

  9. [17]

    Xfaas: Cross-platform orchestration of faas workflows on hybrid clouds

    Aakash Khochare, Tuhin Khare, Varad Kulkarni, and Yogesh Simmhan. Xfaas: Cross-platform orchestration of faas workflows on hybrid clouds. In 2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computing (CCGrid),pages498–512. IEEE, 2023

    2023

  10. [18]

    Large language models are zero-shot reason- ers

    Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. Large language models are zero-shot reason- ers. Advances in neural information processing systems , 35:22199– 22213, 2022

    2022

  11. [19]

    Reverse chain: A third-party reimple- mentation, 2023

    Abhishek Singh Kushwaha. Reverse chain: A third-party reimple- mentation, 2023. URL https://github.com/ASK-03/Reverse-Chain. GitHub repository, accessed January 2025

    2023

  12. [20]

    Api-bank: A comprehensive benchmark for tool-augmented llms.arXiv preprint arXiv:2304.08244, 2023

    Minghao Li, Yingxiu Zhao, Bowen Yu, Feifan Song, Hangyu Li, Haiyang Yu, Zhoujun Li, Fei Huang, and Yongbin Li. Api-bank: A comprehensive benchmark for tool-augmented llms.arXiv preprint arXiv:2304.08244, 2023

    2023 arXiv

  13. [21]

    Autoflow:Automated workflow generation for large language model agents.arXiv preprint arXiv:2407.12821, 2024

    ZelongLi,ShuyuanXu,KaiMei,WenyueHua,BalajiRama,OmRa- heja,HaoWang,HeZhu,andYongfengZhang. Autoflow:Automated workflow generation for large language model agents.arXiv preprint arXiv:2407.12821, 2024

    2024 arXiv

  14. [22]

    Toolnet: Connecting large lan- guage models with massive tools via tool graph

    Xukun Liu, Zhiyuan Peng, Xiaoyuan Yi, Xing Xie, Lirong Xiang, Yuchen Liu, and Dongkuan Xu. Toolnet: Connecting large lan- guage models with massive tools via tool graph. arXiv preprint arXiv:2403.00839, 2024

    2024 arXiv

  15. [23]

    Controlllm: Augment language models with tools by searching on graphs

    Zhaoyang Liu, Zeqiang Lai, Zhangwei Gao, Erfei Cui, Zhiheng Li, Xizhou Zhu, Lewei Lu, Qifeng Chen, Yu Qiao, Jifeng Dai, et al. Controlllm: Augment language models with tools by searching on graphs. arXiv preprint arXiv:2310.17796, 2023

    arXiv

  16. [24]

    Hello gpt-4o, 2024

    OpenAI. Hello gpt-4o, 2024. URL https://openai.com/index/ hello-gpt-4o/. Accessed: 2025-01-25

    2024

  17. [25]

    Gorilla: Large language model connected with massive apis.arXiv preprint arXiv:2305.15334, 2023

    Shishir G Patil, Tianjun Zhang, Xin Wang, and Joseph E Gonzalez. Gorilla: Large language model connected with massive apis.arXiv preprint arXiv:2305.15334, 2023

    2023 arXiv

  18. [26]

    Toolllm: Facilitatinglargelanguagemodelstomaster16000+real-worldapis

    Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, et al. Toolllm: Facilitatinglargelanguagemodelstomaster16000+real-worldapis. arXiv preprint arXiv:2307.16789, 2023

    2023 arXiv

  19. [27]

    Toollearningwithlarge language models: A survey.arXiv preprint arXiv:2405.17935, 2024

    Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang,DaweiYin,JunXu,andJi-RongWen. Toollearningwithlarge language models: A survey.arXiv preprint arXiv:2405.17935, 2024

    2024 arXiv

  20. [28]

    Code:Codeonce,deployeverywhereserverlessfunctions in federated faas

    SashkoRistov,SimonBrandacher,MikaHautz,MichaelFelderer,and RuthBreu. Code:Codeonce,deployeverywhereserverlessfunctions in federated faas. Future Generation Computer Systems , 160:442– 456, 2024

    2024

  21. [29]

    Tptu: Task planning and tool usage of large language model-based ai agents

    Jingqing Ruan, Yihong Chen, Bin Zhang, Zhiwei Xu, Tianpeng Bao, Hangyu Mao, Ziyue Li, Xingyu Zeng, Rui Zhao, et al. Tptu: Task planning and tool usage of large language model-based ai agents. In NeurIPS 2023 Foundation Models for Decision Making Workshop , 2023

    2023

  22. [30]

    Toolformer: Language models can teach themselves to use tools.Advances in Neural Information Processing Systems, 36, 2024

    Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools.Advances in Neural Information Processing Systems, 36, 2024

    2024

  23. [31]

    Taskbench: Benchmarking large language models for task automation

    YongliangShen, KaitaoSong, XuTan,Wenqi Zhang,KanRen, Siyu Yuan,WeimingLu,DongshengLi,andYuetingZhuang. Taskbench: Benchmarking large language models for task automation. arXiv preprint arXiv:2311.18760, 2023

    2023 arXiv

  24. [32]

    Hugginggpt: Solving ai tasks with chatgpt and its friends in hugging face

    Yongliang Shen, Kaitao Song, Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang. Hugginggpt: Solving ai tasks with chatgpt and its friends in hugging face. Advances in Neural Information Processing Systems, 36, 2024

    2024

  25. [33]

    Restgpt: Connecting large language models with real-world restful apis

    Yifan Song, Weimin Xiong, Dawei Zhu, Wenhao Wu, Han Qian, MingboSong,HailiangHuang,ChengLi,KeWang,RongYao,etal. Restgpt: Connecting large language models with real-world restful apis. arXiv preprint arXiv:2306.06624, 2023

    2023 arXiv

  26. [34]

    Chain-of-thought prompting elicits reasoning in large language models.Advances in neural information processing systems, 35:24824–24837, 2022

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thought prompting elicits reasoning in large language models.Advances in neural information processing systems, 35:24824–24837, 2022

    2022

  27. [35]

    Seal-tools: Self-instruct tool learning dataset for agent tuning and detailed benchmark

    Mengsong Wu, Tong Zhu, Han Han, Chuanyuan Tan, Xiang Zhang, and Wenliang Chen. Seal-tools: Self-instruct tool learning dataset for agent tuning and detailed benchmark. arXiv preprint arXiv:2405.08355, 2024. Akiharu Esashi.: Preprint submitted to Elsevier Page 12 of 17 Automati...

    2024 arXiv

  28. [36]

    Convex set reliability-based optimal attitude control for space solar power sta- tion with bounded and correlated uncertainties.Chaos, Solitons & Fractals, 190:115769, 2025

    Chen Yang, Jiayu Wu, Ziyao Fan, and Wanze Lu. Convex set reliability-based optimal attitude control for space solar power sta- tion with bounded and correlated uncertainties.Chaos, Solitons & Fractals, 190:115769, 2025

    2025

  29. [37]

    Craft: Customizing llms by creating and retrieving from specialized toolsets.arXiv preprint arXiv:2309.17428, 2023

    LifanYuan,YangyiChen,XingyaoWang,YiRFung,HaoPeng,and Heng Ji. Craft: Customizing llms by creating and retrieving from specialized toolsets.arXiv preprint arXiv:2309.17428, 2023

    2023 arXiv

  30. [38]

    Flowmind: automatic workflow generation with llms

    Zhen Zeng, William Watson, Nicole Cho, Saba Rahimi, Shayleen Reynolds, Tucker Balch, and Manuela Veloso. Flowmind: automatic workflow generation with llms. InProceedings of the Fourth ACM International Conference on AI in Finance, pages 73–81, 2023

    2023

  31. [39]

    Reversechain:Ageneric-ruleforllmstomastermulti-api planning

    Yinger Zhang, Hui Cai, Xeirui Song, Yicheng Chen, Rui Sun, and JingZheng. Reversechain:Ageneric-ruleforllmstomastermulti-api planning. arXiv preprint arXiv:2310.04474, 2023

    2023 arXiv

  32. [40]

    Can you add the song 'Imagine' by John Lennon to Jenny's 'Chill Vibes' playlist?

    Terry Yue Zhuo, Minh Chien Vu, Jenny Chim, Han Hu, Wenhao Yu, RatnadiraWidyasari,ImamNurBaniYusuf,HaolanZhan,JundaHe, Indraneil Paul, et al. Bigcodebench: Benchmarking code generation with diverse function calls and complex instructions.arXiv preprint arXiv:2406.15877, 2024. A...

    2024 arXiv

  33. [41]

    Select one API from available APIs that is most suitable for the given subtask

  34. [42]

    subtask_number

    Extract the information of "subtask_number", "subtask_description", and "selected_API_name". Please compare given subtask_description and API information carefully and select an API. You must select one API that is the most closest, so please make sure that one API is selected...

  35. [43]

    ""User Query: {query}APIs: {topk_functions} Please generate the Argo HTTP DAG workflows in YAML format:

    Ensure the workflow is generated in a valid Argo YAML format without any additional text. ''' USER_PROMPT = f"""User Query: {query}APIs: {topk_functions} Please generate the Argo HTTP DAG workflows in YAML format:""" (b) Zero-Shot-CoT Prompt Template SYSTEM_PROMPT = f''' Your ...

  36. [44]

    ""User Query: {query}APIs: {topk_functions} Please generate the Argo HTTP DAG workflows in YAML format, let's think step by step:

    Ensure the workflow is generated in a valid Argo YAML format without any additional text. ''' USER_PROMPT = f"""User Query: {query}APIs: {topk_functions} Please generate the Argo HTTP DAG workflows in YAML format, let's think step by step:""" Akiharu Esashi.: Preprint submitte...

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.