Bolo: Verified Model Hub for Next-Generation AI Databases

Bolo: Verified Model Hub for Next-Generation AI Databases Extended Abstracts Yunqi Li

Ila Petrovic

Yongjoo Park

yunqili4@illinois.edu Univ. of Illinois Urbana-Champaign

ilacp2@illinois.edu Univ. of Illinois Urbana-Champaign

yongjoo@illinois.edu Univ. of Illinois Urbana-Champaign

arXiv:2608.20525v1 [cs.DB] 20 Aug 2026

ABSTRACT Verified, ready-to-use inference pipelines are a cornerstone of future AI databases. They allow multi-modal databases to incorporate specialized language, vision, and tabular models that can deliver both high accuracy and efficiency. Unfortunately, existing model platforms such as Hugging Face fall short of this goal. While they host millions of model repositories, many contain only raw weights without runnable pipelines. Even well-documented models often fail due to missing dependencies, unsupported model classes, or incorrect task assignments. Moreover, different models fail for different reasons, with no uniform solution. Constructing a large-scale, verified model hub is nearly impossible with human effort alone. We argue that AI agents can achieve this at scale. We present Bolo, a model platform that hosts verified, ready-to-use inference pipelines, powered by a multi-stage agentic system for model remediation. For models that fail under standard usage, the agent inspects errors and repairs broken pipelines (Type I). For models outside the scope of existing interfaces, it synthesizes pipelines from scratch using model metadata and documentation (Type II & III). To prevent incorrect pipelines from entering the database, the agent applies multi-stage verification—checking not only program structure but also semantic model behavior, ensuring pipelines produce meaningful outputs rather than merely executing without error. In preliminary experiments, Bolo achieves 97.27% and 86.08% runnable coverage for Type II and Type III models, respectively, demonstrating that agentic synthesis with targeted verification can transform large collections of unusable model weights into a verified database of ready-to-use inference pipelines. The preliminary database is open-sourced at https://bolobao.ai/.

1

INTRODUCTION

Specialized models can greatly strengthen multimodal data processing. Unlike GPT-like frontier models [3, 7, 12], specialized language/vision/tabular models offer high accuracy at a fraction of compute cost for target domains (e.g., legal, medical). This opportunity is actively leveraged by AI-powered databases. For example, DocETL [14] decomposes a natural language request into smaller subtasks, where each subtask may be processed by a more efficient model. Data science agents (e.g., DS-Agent [8], AutoKaggle [11], notebook agent [6]) can dynamically synthesize modelbased scripts, which may include pre-trained public models. These multimodal databases will become more successful if a variety of specialized models are readily available for user-specific tasks. Unfortunately, existing model platforms fail to offer readily available models. Platforms like Hugging Face [1] and ModelScope [2] host millions of models, aiming to provide end-to-end services such as fine-tuning, inference, and deployment. Nearly any researcher can create model repositories and upload model (weights)

to share them publicly. While the resources are extremely valuable, many repositories only contain weights rather than runnable inference pipelines. As we analyze in §2, a majority of the models are not runnable due to architectural mismatch, missing configuration files, poor documentation, and so on. Moreover, manually fixing the issues is non-trivial because different models fail due to different reasons, requiring model-specific repairs. Our Goal. To address this, we are building a new model platform (called Bolo) that hosts verified, ready-to-use models. Our core idea is as follows: while it is prohibitively expensive for humans to test and repair millions of (broken) models, AI agents [4, 13, 16, 18– 20] could achieve it in a scalable way. That is, if we could build a novel AI agent specialized for model remediation (e.g., inspecting errors, generating model-specific code, and verifying end-to-end inference), we could use the agent to turn millions of (broken) models into verified, ready-to-use inference pipelines. These verified models can then be directly plugged into AI databases to offer compelling accuracy/efficiency for a wide range of multimodal tasks. Challenge. Our project faces the following challenges (C1–C3). (C1) Existing model interfaces are incomplete. Interfaces like Hugging Face’s Transformers [5] cover only a subset of hosted models— only 3,163 of 5,293 object detection models are supported—and extending such manually curated collections to millions of continuously uploaded models is infeasible. (C2) Even well-documented models have broken or missing inference pipelines. Reference usages found in documentation and model cards are frequently outdated, incomplete, or scattered, causing failures due to missing dependencies, unsupported model classes, or incorrect task assignments. (C3) Verifying a generated pipeline requires unique semantic checks. Conventional software engineering may only involve deterministic tests. Yet, ML models are black boxes. A pipeline may be syntactically correct and may run without error; however, it could produce semantically meaningless outputs. Our Approach. To achieve a large-scale hub of verified models, we have built (and are continuously improving) a multi-stage agentic system that directly addresses each challenge above. (A1) To overcome the coverage limitation of Transformers, our system synthesizes model-specific inference pipelines from scratch for models outside its supported scope, using each model’s metadata and documentation as context. (A2) For models within the Transformers scope that fail under standard usage, the system inspects errors and repairs their pipelines by resolving missing dependencies, correcting model class assignments, and updating outdated usage patterns. (A3) To prevent incorrect pipelines, we introduce multi-stage verification procedures that go beyond structural checks: the system tests model behavior end-to-end, ensuring that pipelines not only execute but also produce semantically meaningful outputs under the intended task setting.

Baseline Coverage (%)

Yunqi Li, Ila Petrovic, and Yongjoo Park

(a) Model size vs. usage

100 80 60 40 20

67.1% (n=1869)

61.5% (n=304)

28.5% (n=624)

93.8% (n=680)

81.2% 88.7% (n=462)(n=719) 42.5% (n=73)

27.3% (n=165)

0

Text Gen.

Image Cls.

Feat. Extract. Img-Text-to-Text

Fill Mask

Text Cls.

Img. Feat. Ext.

Token Cls.

en. e Cls. tract. o-Text Mask t Cls. t. Ext. n Cls. tG Tex . Fea Toke Fill Tex Imag at. Ex -Text-t Fe Img Img

ImportError ValueError

(b) Fraction of runnable models in baseline

(c) Failed models - error type distribution

Error Type

OSError ZeroDivisionError

RuntimeError KeyError

AttributeError ModuleNotFoundError

Figure 1: We analyzed Hugging Face models to understand (a) the relationship between model sizes and their usages, (b) the fractions of runnable and non-runnable models, and (c) the distribution of unique error types. The volume of models to support and the diversity of errors are vast, thus motivating agentic approaches toward a verified model hub.

2

MOTIVATION & SCOPE

We understand why fixing broken models with humans is nearly impossible (§2.1). Then, we clarify the scope of this work (§2.2).

2.1

Motivation

To understand the current state, we collected 2,250,578 models from Hugging Face.1 We make three observations (O1-3). O1: Both small/large models are widely used. Fig. 1a illustrates the relationship between model size and usage. First, models across a broad range of sizes, and both small and large models are widely used. Second, a substantial fraction of models receive relatively low usage, with download counts between 10 and 1K. O2: Many models are unusable. Transformers [5] covers 810,572 models, and the pipeline API aims to provide a universal interface for all Transformers models. To set up it as a baseline, we selected models with downloads exceeding the average (which, after excluding models with zero downloads, stood at 48,754). Then, we copied the pipeline inference code with dependencies from the official documentations of Hugging Face,2 to run inference on GPU. Fig. 1b shows the fraction of runnable models (i.e., coverage) for each task. Many models failed due to various errors (see below). O3: No common fix; we need both agents & human experts. We collected those non-runnable models and analyzed the errors. For ease of presentation, we report only error types that occur more than three times across all tasks (without error details). Fig. 1c shows that 1) all tasks have a substantial number of ImportError cases, indicating missing task-specific dependencies. 2) Each task still exhibits a diverse set of error types, and different tasks show distinct error distributions. For example, the most frequent error type for image classification models is ImportError, whereas for token classification models it is ValueError. For the diverse error types, human is good at identifying and configuring missing dependencies while agents are suitable to understand other code-related errors then patch the current pipeline API.

2.2

Scope of This Work

Supported Models. The 2.8M models on Hugging Face can be grouped into three categories. Type I models (studied in §2.1) are 1 Models were collected as of February 6, 2026. 2 https://huggingface.co/docs/transformers/en/tasks/<TASK_NAME>

directly supported by the pipeline API and span 22 tasks; the task associated with each model is indicated by the pipeline_tag field in its model card. Type II models are still tagged as Transformers, but either lack a clear pipeline_tag or correspond to tasks outside the current scope of pipeline support. Type III models are non-Transformers models. For (a small number of) large models, engines like vLLM [10] provide strong support. We therefore exclude them from our scope. Verifying inference pipelines. When executing agent-generated inference programs, different types of errors may arise. The first type is the runtime error, which is raised during program execution and indicates that the generated code fails to execute correctly. The second type is code hallucination [9, 15]: even if the program runs without runtime errors, it may fail to implement the intended inference semantics. For example, a pipeline generated for model A may incorrectly use model B as the model instance during inference. In addition, a correct inference pipeline does not guarantee correct model outputs, since the model itself may be buggy or misaligned with its intended task. We therefore introduce test-specific data verification, where task-specific test cases are prepared for each fine-grained task. The resulting outputs are evaluated by human experts or an LLM-as-judge against the expected results. We currently focus on the first two verifications.

3

AGENTIC SYSTEM

To construct a large-scale verified model hub, we introduce a specialized agentic system. Fig. 2a presents its overall workflow. Our system adopts a three-stage process to compose the inference pipeline for a given model. The system takes different inputs depending on the model type. For Type I models, our system only considers models that fail in the baseline described in §2.1. It starts from the original pipeline-based inference code used in the baseline, together with model-specific metadata such as the README.md file. For Type II & III models, the system instead takes model weight files and model-specific metadata as input. The first (§3.1) and second (§3.2, §3.3) stages focus on inference pipeline generation and runtime error verification. The generation strategy differs across model types: for Type I models, the system patches the existing pipeline-based code; for Type II & III models, it generates inference pipelines as Jinja2 templates along with

Bolo: Verified Model Hub for Next-Generation AI Databases

(a) Workflow of our agentic system

(b) Hallucinated inference template

Figure 2: Our agentic system converts unusable model-weight repositories into verified inference pipelines. As shown in (a), Type I models are repaired by patching the pipeline API, while Type II and Type III models are handled by generating model-specific Jinja2 inference templates. The generated code is then passed to a hallucination-detection stage, where hallucinated templates, such as the example in (b), are filtered out and sent for review. model-specific dependencies. Finally, Stage III (§3.4) performs code hallucination verification on all inference programs from Stage II.

the model’s metadata and weights files to the generation workflow (see below).

3.1

3.3

Stage I: Repair Dependencies

As shown in §2.1-O3, each model may require additional modelspecific dependencies for inference (e.g., a text generation model may rely on a tokenizer that requires an additional Python package). Indeed, identifying model-specific dependencies could repair a substantial portion of previously non-runnable Type I models. Repair-1. For a non-runnable Type I model, our system uses the baseline pipeline inference program as input. It identifies the model’s task and runs the program in a fresh virtual environment with pre-configured task-specific dependencies. These dependencies are prepared during baseline verification by manually analyzing task-level error messages and identifying missing packages. The program is then executed once as runtime error verification. If it succeeds, it proceeds to Stage III for hallucination detection, which should pass since the program remains unchanged. Otherwise, the program, dependencies, and model-specific metadata are sent to Stage II for further repair.

3.2

Stage II: Finalize Type I Model Repair

In Stage II, our system invokes agents to derive runnable inference programs for Type I models in two steps. Repair-2.1. For a Type I model failing at Stage I runtime error verification, our system invokes an agent to patch the inference program (e.g., editing the model class definition to add missing configuration variables), and keep the inference library and dependencies unchanged. The tool set of our patching agent involves runtime error verification and read-only file system functions to explore the metadata. A budget on the number of tool calls is applied to the patching agent; once the budget is exceeded, the model along with the current state will be sent to Repair-2.2. Repair-2.2. For Type I models failing at Repair-2.1 runtime error verification, our system will treat it as a Type II model, and send only

Stage II: Repair Type II & III Models

Given a Type II or III model, our system takes its weights files and metadata as input, then invokes a coding agent. The tool set of this agent includes runtime error verification and venv management functions (e.g., install/uninstall packages). The coding agent emits the Jinja2 template along with a model-specific requirements.txt. At the time the agent invokes runtime error verification, our system will first configure dependencies in a fresh venv then executes the template by rendering its variables (e.g., input) with default values. The same budget is applied on coding agent. Once the agent fails to derive the inference program that passes runtime error verification for a model, the system will mark the model as failed.

3.4

Stage III: Code Hallucination Verification

Both patching and coding agents may generate hallucinated code that does not implement the correct inference semantics but passes the verification. A hallucinated template (shown in fig. 2b) may bypass the input data and contain only a few meaningless print calls. Code hallucination verification is therefore designed to filter out such templates. The filtered inference programs are then reviewed by an LLM judge or a human expert to confirm whether the filtering decision is correct. We start with a framework for characterizing non-hallucinated inference programs, and then derive the verification algorithm HalluVer. Formal Framework. We formalize inference semantics as a tuple (X, Y, 𝑀), where X is the input space, Y is the output space, and 𝑀 is the model specification. To realize such semantics, a nonhallucinated inference program 𝑃 should contain three steps: 1 load the target model; 2 perform computation on task input; and 3 construct the final output. Let 𝐿(𝑃) denote the inference library (e.g., Transformers) imported by 𝑃. And 𝑔𝑃 is 𝑃’s data-flow graph, where 𝑢 ⇝𝑃 𝑣 means that 𝑢 can flow to 𝑣. 𝑃 should satisfy the following:

Yunqi Li, Ila Petrovic, and Yongjoo Park

Baseline

Runnable Coverage (%)

100.0% 99.4% 100.0%

100

After Repair-1 100.0%

96.2%

95.7%

92.9%

94.1% 94.1%

After Repair-2.1

After Repair-2.2

98.6% 97.0% 100.0%100.0% 99.6% 100.0% 95.5% 99.0% 98.5% 99.3% 95.5%

Table 1: Coverage and cost: Type II & III. mini-swe

74.4%

44.4%

50

)

gFe at (n

Im

14)

624 Im

(n=

n= ls (

gC Im

Ma sk

=7 3) gSe g( n= Im 69) g2T xt (n= 164 Vid ) Cls (n= 26) An y2A ny (n= Tx 9) t2A ud (n= Ta 14) ble QA (n= 14) ZS Ob j (n =1 Fea 7) tEx t (n =3 0 4 ZS ) Im g( n= Tex 74) tG en (n= 175 2) Do cQ A( n= 4) Ob jDe t (n =4 Fil 5) lM as k (n= 462 ) ZS Cls (n= 50) De p th (n= 22) Tex tCl s (n =7 19) AS R( n= 264 To ) kC ls ( n= 680 Au ) dC ls ( n= 44)

0

Ours

Type

Coverage

Cost

Coverage

Cost

Type II Type III

93.05% 73.12%

$36.65 $53.60

97.27% 86.08%

$37.26 $134.54

Table 2: Code hallucination verification. Category

TP

FP

TN

FN

Recall

Precision

Type I models Type II models

67 71

24 (7) 48 (29)

90 119

1 0

98.5% 100.0%

79.8% 78.9%

Figure 3: Stage-by-stage runnable coverage improvement for Type I models.

∃𝑥, 𝑚, 𝑧, 𝑦 : 𝑥 ∈ X ∧ 𝑚 ← 𝑓 (𝑀 ),

𝑓 ∈ 𝐿 (𝑃 )

∧ 𝑧 ← 𝑞 (𝑚, 𝑥 ′ ),

𝑞 ∈ 𝐿 (𝑃 )

∧ 𝑦 ∈ Y ∧ 𝑧 ⇝𝑃 𝑦

1 load target model 2 compute on input 3 construct output.

Here, 𝑥 ′ denotes the possibly pre-processed input, and the reachability condition 𝑧 ⇝𝑃 𝑦 allows arbitrary post-processing between the raw inference output and the final result. 𝑓 and 𝑞 are model loading and computation API calls from 𝐿(𝑃). Algorithm: HalluVer. HalluVer takes 𝑃 as input, parses 𝑃 into an abstract syntax tree (AST), and constructs its data-flow graph 𝑔𝑃 . It then verifies whether 𝑃 implements the above three steps correctly. If any of these checks fails, HalluVer flags 𝑃 as hallucinated; otherwise, 𝑃 passes code hallucination verification. To identify 𝑓 and 𝑞 in 𝐿(𝑃), HalluVer relies on an offline curated API collection 𝐶 for each inference library.

4 PRELIMINARY RESULTS 4.1 Evaluation Setup Models. Following the baseline setup in §2.1, we collected Hugging Face models with greater-than-average download counts. Then, we excluded the models larger than 16GB and those with external service agreements. Finally, we obtained 5,444 Type I models, 1,353 Type II models, and 1,581 Type III models. Agents. For Type II & III models, we compare our agentic system (§3.3, noted Ours) to mini-swe-agent [17]. mini-swe is configured to use Apptainer sandbox for arbitrary bash commands. The budget for all agents is 50 tool calls. We set 20-min timeout for each model in Stage II. The LLM backend is ChatGPT-5.1-CodeX-mini. Configurations. All experiments were conducted on an NVIDIA A40 GPU with CUDA version 12.8. The GPU was used for runtime error verification. LLM calls were remote. For the baseline of Type I models, we used v5.3.0 Transformers by Hugging Face.

4.2

For Some Models, Agent Boosts Coverage

Fig. 3 presents the coverage (i.e., fraction of runnable inference programs after runtime error verification) improvements of Type I models, which echoes Fig. 1c. The average coverage of the baseline across all tasks is 69.3%, then after Stage I fixing (dependencies configuration) it comes to 88%, leaving the last 10% to be covered. Our

proposed agentic strategy could resolve this “last-mile” problem, increasing the coverage to 96.1% (Repair-2.1) and 97.3% (Repair-2.2) on average.

4.3

For Other Models, Agent is Essential

For Type II & III models, tab. 1 reports (1) the coverage after runtime error verification and (2) the total API costs in US Dollars. Ours reached higher coverage than mini-swe for both Type II & III models. We attribute this improvement to our more task-oriented tool set used. That is, compared with unrestricted bash commands, our tool design guided the agent toward inference-pipeline generation and reduced cases where the tool-call budget or wall-time limit was exhausted. However, Ours incurred higher API costs than mini-swe on Type III models. Although our agent used fewer steps, its prompt was longer than that of mini-swe. Moreover, since the two agents followed the same core reasoning and action steps, the longer prompt led Ours to consume more reasoning tokens overall. Further investigation and cost reduction are left as ongoing work.

4.4

Hallucination Verification is Important

Finally, we evaluated HalluVer for verifying code hallucination in runtime-error-free inference programs for Type I and Type II models. We first curated an API collection 𝐶 for Transformers, covering model-loading APIs and inference-related computation APIs. Using this collection, HalluVer flagged 91 hallucinated programs among 481 runnable Type I inference programs, and 119 hallucinated programs among 1,316 runnable Type II inference programs. After filtering these programs, the average runnable coverage was reduced to 95.3% after Repair-2.1 and 95.6% after Repair-2.2 for Type I models, and to 88.5% for Type II models. To evaluate these filtering decisions, a human expert annotated all programs flagged as hallucinated, together with an equally sized sample of unflagged programs. Tab. 2 reports the resulting false positives and false negatives. The results show that HalluVer minimizes false negatives by aggressively flagging suspicious pipelines, but incurs non-negligible false positives. Specifically, 24 Type I and 48 Type II valid programs were incorrectly flagged, motivating a final human or LLM-based review before exclusion. The bracketed numbers denote programs outside the current Transformers-based coverage of HalluVer, which we exclude when calculating precision.

Bolo: Verified Model Hub for Next-Generation AI Databases

REFERENCES [1] [n.d.]. Hugging Face Hub. https://huggingface.co/ Accessed: 2026-05-28. [2] [n.d.]. ModelScope. https://www.modelscope.ai Accessed: 2026-05-28. [3] Anthropic. 2026. Claude Opus 4.8. https://www.anthropic.com/news/claudeopus-4-8. Accessed: May 31, 2026. [4] Yinfang Chen, Jiaqi Pan, Jackson Clark, Yiming Su, Noah Zheutlin, Bhavya Bhavya, Rohan Arora, Yu Deng, Saurabh Jha, and Tianyin Xu. 2026. STRATUS: A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds. arXiv:2506.02009 [cs.DC] https://arxiv.org/abs/2506.02009 [5] Thomas Wolf et al. 2020. HuggingFace’s Transformers: State-of-the-art Natural Language Processing. arXiv:1910.03771 [cs.CL] https://arxiv.org/abs/1910.03771 [6] Hanxi Fang, Supawit Chockchowwat, Hari Sundaram, and Yongjoo Park. 2025. Large-scale Evaluation of Notebook Checkpointing with AI Agents. In Proceedings of the Extended Abstracts of the CHI Conference on Human Factors in Computing Systems. 1–8. [7] Google. 2026. Gemini 3.5 Flash. https://blog.google/technology/ai/google-io2026-all-our-announcements/. Accessed: May 31, 2026. [8] S Guo, C Deng, Y Wen, H Chen, Y Chang, and J Wang. 2024. DS-Agent: Automated Data Science by Empowering Large Language Models with Case-Based Reasoning. In Proceedings of Machine Learning Research, Vol. 235. Association for Computing Machinery, 16813–16848. [9] Dipin Khati, Daniel Rodriguez-Cardenas, Paul Pantzer, and Denys Poshyvanyk. 2026. Detecting and Correcting Hallucinations in LLM-Generated Code via Deterministic AST Analysis. arXiv:2601.19106 [cs.SE] https://arxiv.org/abs/ 2601.19106 [10] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. 2023. Efficient Memory Management for Large Language Model Serving with PagedAttention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles. [11] Ziming Li, Qianbo Zang, David Ma, Jiawei Guo, Tianyu Zheng, Minghao Liu, Xinyao Niu, Yue Wang, Jian Yang, Jiaheng Liu, et al. [n.d.]. AutoKaggle: A MultiAgent Framework for Autonomous Data Science Competitions. In ICLR 2025

Third Workshop on Deep Learning for Code. [12] OpenAI. 2026. GPT-5.5. https://openai.com/index/introducing-gpt-5-5/. Accessed: May 31, 2026. [13] Matthew Russo and Tim Kraska. 2025. Deep Research is the New Analytics System: Towards Building the Runtime for AI-Driven Analytics. arXiv:2509.02751 [cs.AI] https://arxiv.org/abs/2509.02751 [14] Shreya Shankar, Tristan Chambers, Tarak Shah, Aditya G Parameswaran, and Eugene Wu. 2025. DocETL: Agentic Query Rewriting and Evaluation for Complex Document Processing. Proceedings of the VLDB Endowment 18, 9 (2025), 3035– 3048. [15] Yuchen Tian, Weixiang Yan, Qian Yang, Xuandong Zhao, Qian Chen, Wen Wang, Ziyang Luo, Lei Ma, and Dawn Song. 2025. CodeHalu: Investigating Code Hallucinations in LLMs via Execution-based Verification. Proceedings of the AAAI Conference on Artificial Intelligence 39, 24 (Apr. 2025), 25300–25308. https: //doi.org/10.1609/aaai.v39i24.34717 [16] Chunqiu Steven Xia, Zhe Wang, Yan Yang, Yuxiang Wei, and Lingming Zhang. 2025. Live-SWE-agent: Can Software Engineering Agents Self-Evolve on the Fly? arXiv:2511.13646 [cs.SE] https://arxiv.org/abs/2511.13646 [17] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv:2405.15793 [cs.SE] https://arxiv.org/abs/2405.15793 [18] Zhiqiang Yuan, Weitong Chen, Hanlin Wang, Xin Peng, Zhenpeng Chen, and Yiling Lou. 2026. TransAgent: Enhancing LLM-Based Code Translation via FineGrained Execution Alignment. arXiv:2409.19894 [cs.SE] https://arxiv.org/abs/ 2409.19894 [19] Jinghan Zeng, Eugene Wu, and Sanjay Krishnan. 2024. A Simple and Fast Way to Handle Semantic Errors in Transactions. arXiv:2412.12493 [cs.DB] https://arxiv.org/abs/2412.12493 [20] Hongbin Zhong, Fazle Faisal, Luis França, Tanakorn Leesatapornwongsa, Adriana Szekeres, Kexin Rong, and Suman Nath. 2026. ActionEngine: From Reactive to Programmatic GUI Agents via State Machine Memory. arXiv:2602.20502 [cs.AI] https://arxiv.org/abs/2602.20502

Related documents

• Bolo: Verified Model Hub for Next-Generation AI Databases#659090
• Bolo: Verified Model Hub for Next-Generation AI Databases#656954
• Supporting Trustworthy AI Through Machine Unlearning#107145
• AgentCite: Trustworthy AI Agents for Information Verification Across Referenced Documents#307614
• ASCEND: Personal AI Agents for Autonomous Scientific Computing Across HPC Clusters and GPU Workstations#1117581