Papers for

enterprise ai teams

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Occupation-focused benchmark tests large language models on real work tasks

ORQA: An Occupation-Realistic Question and Answer Framework for LLM Professional Knowledge

Abstract: We present ORQA, a method for testing occupation-level knowledge in large language models. Prior methods either map abstract LLM skills to occupations via task definitions or utilize expert knowledge which is difficult to obtain at scale and expensive. ORQA complements both of these methods by connecting O*NET occupations to trusted occupation-specific websites (such as regulatory agencies, licensing bodies, professional organizations, and government publications) and converting these into source-traceable question-answer pairs. A combination of an automated pipeline and human review produces a set of high quality questions about occupations. The question set created via our method covers 116 occupations from all 21 major groups in the SOC, with 480 questions sourced from 187 different websites. Each question is designed to probe a real-world skill question that is relevant to the occupation in question. We test 15 state-of-the-art frontier and open-weight models via this method. Claude Opus 4.6, GPT-5.4 and Claude Sonnet 4.6 all perform the best at approximately 58-62% while smaller open-weight models achieve approximately 33-41% performance. Performance varies significantly across occupations. Healthcare-related occupations achieve the highest performance (78%) while Office and Administrative Support achieve approximately 40%. Performance on individual occupations (e.g. Sheet Metal Workers and Fish and Game Wardens) is essentially zero. We also find that open-ended questions and weighting by wage bill do not significantly affect the ranking of models on this benchmark. We believe that leveraging existing trusted occupation-specific information to test LLM knowledge in professional domains may be a scalable and useful method for evaluating occupation-level AI performance in the future. Results and data are available at orqabench.org.

Fri 11 SeptComputation and LanguageArtificial Intelligence
The gist
It can be hard to test how well AI programs understand real jobs because good questions are expensive and rare. The authors created ORQA, which uses trusted job-related websites to make real work questions for AI to answer. They tested many popular AI models and found some do quite well on healthcare jobs but struggle on others like office support. This method helps see what kinds of professional knowledge these AIs really have and where they still need improvement.
Open 2609.12366v1

Enterprise AI system performance measured by serving route not model ID

IBIB: A Protocol for Measuring Enterprise AI Systems by Serving Route, Not Model Identifier

Abstract: Enterprises deploy systems, not checkpoints. Usable capability depends jointly on weights, serving route, precision, output contract, and harness, yet all 18 audited benchmarks score advertised model identifiers. We treat this as measurement error and give a protocol that makes it reportable. It has three parts. A gold-blind capability-binding preflight verifies that a route can execute the evaluation contract before any task reaches it; a reliability-inclusive first-pass scoring rule keeps failure in the score while keeping unsupported capability out; and adjudication is structurally score-blind. We call the protocol IB2 and release its algorithms, classification tables, request contract, and manifest schemas. Its reference instantiation, 128 locked tasks and 987 assertions over document, spreadsheet, chart, tool and database work, stays sealed: the procedure is the artifact, not the corpus. Across eleven systems, four results. Capability availability is measurable: two complete single-route runs on identical weights later failed distinct predicates of the finalized binding gate, while a third passed that gate before a fresh run. The advertised identifier exposed neither limit. Discrimination is not uniform: four of seven suites saturate under a six-system band, with the spread almost entirely from governed database work and multi-tab joins, so we report interval-backed resolution groups, not ranks; two of the nominal five-label output's four cuts fail multiplicity adjustment. Serving-arm choice moved one declared revision and precision from 77.38 to 82.54, paired interval [0.11,10.60], though the arms differ in access mode, harness generation, and the serving tool-call parser, and harness generation is a property of our evaluator, not any endpoint. Excluding failed responses from denominators changes the point ordering, so reliability inclusion changes a conclusion, not its wording.

Wed 9 SeptComputation and LanguageArtificial IntelligenceMachine Learning
The gist
Measuring AI in companies is tricky because AI systems aren't just a single model but a combination of software and how it is served or run. The paper shows that measuring only by the model's name or version misses important details, leading to errors in performance evaluation. The authors propose a new testing method called IB2 that checks AI systems based on the actual route used to serve the AI, including reliability and how well it meets task conditions. Their method reveals that even the same AI model can behave differently depending on how it is served, which is important for understanding real-world AI capabilities.
Open 2609.10494v1

Maverick speeds up private and verifiable large language model inference

Maverick: Private and Verifiable LLM Inference Made Practical via Matrix-Vector Multiplication Delegation

Abstract: Open-source large language models (LLMs) are increasingly competitive with closed-source models while offering transparency and the ability to run inference without exposing user inputs to a service provider. However, running large-scale models locally requires substantial computational resources. In practice, users may still resort to a third-party provider, giving rise to privacy and correctness concerns. Existing solutions that address these problems often impose substantial server overhead or introduce additional trust assumptions. In this paper, we present Maverick, a novel approach to private and verifiable LLM inference based on a protocol for delegating matrix-vector multiplication, a dominant operation in LLMs. At its core, Maverick provides, to our knowledge, the first information-theoretically sound verification protocol for matrix-vector multiplication delegation with transparent preprocessing, efficient (batch) verification, and virtually no server overhead. We combine this verification primitive with LPN-based pseudorandom masking to provide input privacy. We implement our matrix-vector delegation primitive and use it to build an end-to-end prototype of Maverick, which we evaluate on Qwen3-4B by measuring throughput in tokens per second. We evaluate client configurations with 1-8 threads. With one client thread and a CPU server using up to 128 threads, Maverick achieves throughput gains over local inference of up to 17x when privacy masks are generated online, 45x when they are precomputed, and 44x when only verification is required. With four client threads, the corresponding gains are 13x, 18x, and 17x. When server computation is no longer the bottleneck, client-side microbenchmarks with simulated network delay show speedups of 12x-20x, 34x-135x, and 38x-157x.

Wed 9 SeptCryptography and SecurityMachine Learning
The gist
Running large language models (LLMs) can be expensive and slow, especially when users want to keep their inputs private and verify the results. The authors present Maverick, a way to let a server do the heavy work of large model calculations while ensuring the server’s work is correct and the user’s data stays private. Maverick uses a clever method to check matrix-vector multiplications, which are key in large models, without much extra work for the server. Their tests show big speedups compared to running models locally, making private and trustworthy language model use more practical.
Open 2609.10264v1

Kernel manages shared memory to improve AI personalization and efficiency

Kernel-Managed Shared Memory for System-Wide Personalization

Abstract: AI systems become more useful when they can adapt to the people using them, but in multi-agent systems, useful context learned by one agent often remains unavailable to others. We present kernel-managed shared memory, a system-level abstraction in which specialized agents write structured, tagged memories while the agent-system kernel, not individual agents, governs retrieval, privacy enforcement, and prompt injection. We implement and evaluate this design on AIOS and compare it against three alternatives across three assistant models (GPT-4o, Llama-3.1:8B, Qwen-2.5:7B) and 1,800 total trials. Against an unmanaged external memory backend (Mem0) using identical underlying storage, kernel-managed retrieval and injection improve personalization scores by 2.4-4.0 points on a 5-point scale (e.g., 1.05 to 4.69 profile usage on GPT-4o), with every comparison significant at p < 10^-18. Against standard retrieval-augmented injection, gains are similarly large and consistent across all three models. Against full, unfiltered context concatenation, a soft ceiling on available context rather than on response quality, kernel-managed injection statistically matches performance on two of three models and shows a small, model-specific deficit on the third, while using substantially shorter prompts: end-to-end latency is 15-61% lower across all three models, with corresponding reductions in per-call token usage and inference cost. These results indicate that centralizing memory management in the agent-system kernel, rather than leaving retrieval and privacy enforcement to individual agents, delivers most of the personalization benefit of unconstrained context at a fraction of its cost.

Wed 9 SeptArtificial IntelligenceMachine Learning
The gist
AI assistants get better when they remember useful information about you, but often this memory isn’t shared well between different AI helpers. The authors introduce a system where a central kernel controls how multiple AI agents store, retrieve, and protect shared memories, rather than each AI managing its own memory alone. Their tests show this method lets assistants personalize responses more accurately while using less computing power and time. This approach balances good memory use with privacy, making AI interactions smoother and faster.
Open 2609.10144v1

Split learning secures privacy in federated fine-tuning of large language models

Privacy-Preserving Split Learning for Federated LLM Fine-Tuning

Abstract: Fine-tuning large language models (LLMs) on domain-specific data is essential for downstream adaptation. In many deployments, a participant cannot hold the complete model locally. This happens because the model owner keeps the full model proprietary, or because the participant lacks sufficient compute resources. Split Learning (SL) addresses this by partitioning the model between the participant and a server so that only a small portion runs locally. When the underlying data is additionally distributed across multiple institutions with privacy requirements, Federated Learning (FL) further enables collaborative training across participants by sharing only model updates instead of raw data. In this combined setting, each client transmits intermediate activations to the server, and for LLM fine-tuning, this exchange poses an inherent privacy paradox. The autoregressive nature of LLMs causes the transmitted activations to leak the input, and existing perturbation-based defenses are fundamentally ineffective in this setting. We address this leakage through a learned obfuscate-and-recover scheme that protects participants' private datasets while still allowing an independently deployable model to be trained on the server side. Experiments demonstrate that our approach achieves strong privacy protection with modest utility loss and system overhead, making split-based federated LLM fine-tuning practically viable.

Wed 9 SeptMachine Learning
The gist
Fine-tuning large language models on special data is important but hard when the full model can't be kept locally, or privacy rules prevent sharing raw data. The paper addresses a privacy problem that happens when parts of the model run on different machines and data is distributed across several places. The authors create a way to hide private information in signals sent between participant and server, so the model can still learn without exposing sensitive data. Their method keeps privacy strong while keeping the model useful and efficient to run.
Open 2609.09794v1

Selective revalidation reduces conflicts for long-running AI decisions

From Version Conflicts to Decision Conflicts: Selective Revalidation for Long-Running AI Agents

Abstract: Long-running AI agents may read state, reason, wait for tools or human approval, and perform an external action much later. The state that justified the action can change in the meantime. For example, after an agent proposes an 80 GBP refund under a limit of 100, a customer-name change affects only presentation metadata, a new limit of 90 still permits the refund, a limit of 50 invalidates it, and a refund issued by another worker must prevent a duplicate. Standard optimistic concurrency control and version checks can detect that previously read state has changed, but by themselves do not determine whether that change invalidates the pending action's justification. We call any detected version change a version conflict; when that change invalidates the action's justification, it is also a decision conflict. ATR records the explicit, executable conditions that justify a pending action and rechecks only the conditions affected by a change before releasing the external operation. It can retain the action, refresh non-decisive metadata, require replanning, or block execution; a target-side transaction or compare-and-set binds checked state to commit. Across 210,000 controlled executions over 15 mutation cases, ATR matched every developer-specified outcome with no false allows or blocks. In ten durable SQLite checkpoint/resume cells, it evaluated 0.6 conditions per change versus 6.0 for FullScan. At 4,093 recorded reads, ATR took 9.3 microseconds versus 2595.9 microseconds for FullScan. These deterministic results establish controlled feasibility, not production generality or automatic extraction of the required conditions.

Mon 7 SeptArtificial IntelligenceDatabases
The gist
Sometimes AI systems plan actions based on information that changes by the time they act. The researchers show a way to check only the parts of the information that matter when changes happen, rather than rechecking everything. This approach helps avoid mistakes like acting on outdated data or unnecessarily blocking valid actions. Their tests showed the method worked accurately and much faster than checking all conditions every time.
Open 2609.08015v1

Accountability layers in multi-agent AI pipelines often fail to catch errors

Audit Without Verification: When LLM Accountability Layers Relay Rather Than Check

Abstract: Multi-agent LLM pipelines increasingly span organisational boundaries; when a fault surfaces, someone must determine where it entered. The artifact available is rarely a full execution trace: it is the reports each agent filed, and a filed report can state a conclusion alongside its observations. Using a pre-registered, institutionally partitioned pipeline of six agents with process-level information boundaries, balanced defect injection and matched clean twins (345,600 requests per chain model, two models), we first report that our pre-registered hypothesis -- that collective responsibility framing degrades escalation with chain length -- is not supported. The layer nevertheless fails asymmetrically. It originates almost nothing: zero allegations across 7,996 clean episodes where every agent stayed silent. It filters upstream error poorly, naming an innocent party in 34.4% and 62.6% of clean episodes where an agent raised a false alarm. Conditional on no agent proposing the true origin (59.5% of episodes on one chain model), an auditor reading the reports recovers it in 4.1% of cases -- below a uniform guess (20%) and the best fixed-link accuser (31.0%) -- while reaching 60.3% from the raw documentation of the same episodes. Deleting one clause, the field carrying the agents' own conclusion, isolates the cause at constant observations: accuracy rises to 45.2% (+41.2 pp, 95% CI +35.3 to +46.9) and adherence collapses from 94.4% to 3.4%; where the suggestion was correct the same deletion instead costs accuracy, 70.5% to 55.7%. The harm replicates on two frontier auditors in four conditions out of four (+8.5 to +39.0 pp) and in a second domain (+47.7 and +61.1 pp), where the cost disappears. The net effect is governed by upstream reliability together with both conditional magnitudes. An accountability layer needs evidence sufficiently independent of the conclusions it verifies.

Mon 7 SeptMultiagent Systems
The gist
When multiple AI agents work together across different organizations, it’s hard to find who made a mistake just by reading their reports. The paper shows that these accountability layers often relay information without properly checking it, sometimes blaming innocent parties or missing the real source of errors. The authors found that removing agents’ own conclusions from reports improved error detection but reduced how much the system relied on those reports. This means effective audit layers need evidence independent of agents’ final statements to work well.
Open 2609.07680v1