Pith. sign in

REVIEW 4 major objections 7 minor 67 references

Towards an Agent Operating System - Lessons from Classical and Cloud OS

T0 review · 4 major / 7 minor · reviewed 2026-07-31 · grok-4.5

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

Pith's one-line read Agentic AI needs an operating system: stable, portable abstractions extended from classical and cloud OS primitives, not more frameworks.

desk verdict Useful Phase-2 taxonomy of agent platform gaps; the POSIX/K8s “specify then consolidate” history is oversold, but the primitive set and open agenda still deserve referee time. read the letter →

arxiv 2607.25076 v1 pith:U5JZNVVS submitted 2026-07-27 cs.AI

Gosia Steinder , Hubertus Franke This is my paper · ORCID
classification cs.AI
keywords agentoperatingsystemLLMagentsplatformabstractionsPOSIXKubernetessemanticgaptoolmediationcontextmanagement
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 argues that autonomous LLM agents are in the same early, fragmented phase that classical operating systems and cloud platforms once occupied—lots of competing frameworks, no agreed platform guarantees. Without a small set of stable abstractions with precise semantics, agent applications cannot be portable, platforms cannot compose across vendors, and production systems stay bespoke. The authors claim the way out is the same path POSIX and Kubernetes took: extend proven OS and cloud primitives to handle stochastic, natural-language-mediated, externally acting agents, specify what the platform must enforce, and consolidate around those guarantees. They propose thirteen such primitives—from agent lifecycle and tool mediation to context management, guardrails, and trajectory observability—and show that a subset can already be implemented on Kubernetes rather than replacing it. A sympathetic reader cares because enterprise agent deployments are already failing on reliability, governance, and integration; the paper says those are infrastructure problems, not model problems.

What carries the argument

Semantic-gap derivation of thirteen Agent-OS primitives: for each classical or cloud OS abstraction, ask what guarantee it gave, whether that guarantee holds for agents, and what must change for stochastic, natural-language, real-world action—then treat only the genuine gaps as new platform work.

What would settle it

If, after serious attempts to specify and implement the proposed primitives (especially context eviction, natural-language guardrails, and failure detection under self-concealment), independent platforms still cannot offer portable guarantees and production agent systems remain framework-tied or best-effort, the consolidation claim fails.

Watch

Extended reading notes

Core claim

Agentic systems will not mature past prototypes until the field articulates and standardizes an Agent-OS: a platform layer that extends classical OS and Cloud-OS abstractions to stochastic, natural-language-mediated, externally acting agents, specifies enforceable semantics for those abstractions, and consolidates so applications can target them portably—exactly as POSIX and Kubernetes did for prior waves.

Load-bearing premise

That useful, portable, platform-enforceable semantics can actually be written for intrinsically stochastic agents with open-ended natural-language goals and strategic self-concealment, the way POSIX and Kubernetes semantics were written for deterministic programs and services.

Editorial extensions

If this is right

  • Portable agent applications become possible only after agreed semantics for lifecycle, tools, memory, auth, and observability—not after more agent frameworks.
  • Reliability, safety, and cost bounds for agents must be enforced by infrastructure (schedulers, mediation, immutable audit), not by prompts or model self-checks.
  • Agent-OS should extend Kubernetes and related cloud primitives rather than replace them; multi-cloud and on-prem operation stay first-class.
  • Open specification work concentrates on genuine gaps: stochastic scheduling, semantic skill contracts, NL policy languages, principled context eviction, and agent-aware failure recovery.
  • Frameworks that ignore platform-enforceable guarantees will keep being discarded when systems move from prototype to production.

Reading between the lines

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

  • If self-concealment and open failure spaces resist decidable detection, Agent-OS may need mandatory human-in-the-loop and risk-tiered enforcement as permanent architecture, not temporary scaffolding.
  • The same three-phase arc argument predicts that MCP-style communication standards alone will not yield production reliability until execution guarantees (authorization, reversibility, observability) are specified beside them.
  • Success of the thirteen-primitive taxonomy would pressure cloud vendors to compete on Agent-OS conformance the way they compete on Kubernetes distributions today.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 7 minor

Summary. This is a position paper arguing that agentic AI is in the "pre-POSIX" experimentation phase of a third platform wave, and that the field should follow the methodology of the classical-OS and cloud-OS eras: articulate a small set of stable abstractions with precise, platform-enforceable semantics, then consolidate. The paper (i) presents a three-phase historical arc (experimentation → articulation → consolidation) anchored on POSIX and Kubernetes; (ii) gives a semantic-gap analysis (§III) distinguishing structural breaks (external-world action, irreversibility, dynamic authorization) from stochasticity-intrinsic breaks (no WCET, no replay, no temporal locality, self-concealment); (iii) derives thirteen "Agent-OS primitives" (Table I) via a stated three-question method, each with OS and Cloud-OS origins and an open specification problem; (iv) describes rossoctl, an open-source Kubernetes-based prototype implementing a subset; and (v) closes with four "lessons" and an eight-item research agenda.

Significance. If the framing is repaired, the durable contributions are real: the §III split between structural gaps (which have classical precedents — compensating transactions, capability security) and stochasticity-intrinsic gaps (which do not) is a genuinely useful analytic distinction that disciplines what needs new theory versus engineering extension; Table I is a well-organized consolidation artifact mapping each primitive to its gap, status, and horizon; and the eight open problems in §VII are concrete and mostly falsifiable (e.g., "bound the cost of eviction errors in terms of downstream task failure" in §IV-E). The three-question derivation method is stated explicitly and the taxonomy is honestly disclaimed as neither complete nor minimal. The gap analysis is well-sourced on failure modes, self-concealment, and supply-chain statistics. These strengths survive the framing problems below, which is why I do not recommend rejection.

major comments (4)
  1. [§II.A and §VI, Lesson 1] The three-phase arc is historically inverted for both exemplars, and this is load-bearing because Lesson 1 ('standardization is the exit from experimentation') and the Abstract's prescription ('specify their semantics precisely, and consolidate around them — just as POSIX and Kubernetes consolidated their respective waves') rest on it. POSIX (IEEE 1003.1-1988) codified an already-dominant Unix practice after years of de facto portability via C and the v7/BSD/System V source culture; it ratified a winner. Kubernetes won an implementation contest against Mesos/Swarm/Nomad with a concrete Borg-descended system; its pod/reconciliation semantics became standard because the implementation dominated, not because the community agreed on semantics first. The paper's Phase-2-before-Phase-3 ordering is therefore not 'the same methodology the prior eras used.' This does not invalidate the taxonomy,
  2. [§IV, esp. §IV-B, §IV-K, §IV-M] The thirteen 'primitives' are heterogeneous in kind, and several entries contradict the paper's own definition of a primitive as a platform-enforced abstraction with specified semantics. §IV-B's Agent-OS primitive for orchestration is literally 'CrewAI, LangGraph, AutoGen ... extended with token-budget quotas, semantic loop detection' — i.e., the Phase-1 frameworks the paper elsewhere criticizes as non-composable, plus unbuilt features. §IV-K's observability primitive is a list of products (LangFlow, Arize, MLFlow). §IV-M's is 'alternative lightweight implementations (Rust-based) emerge.' In contrast, §IV-D (tool mediation with a reversibility model) and §IV-E (context management with a stated open theory) do describe abstractions with semantic content. The paper should either re-specify the weak entries at the same level of abstraction as the strong ones (what guarantee, enforced where,
  3. [§VIII and [63]] The empirical urgency claim rests almost entirely on [63] (MIT NANDA, '95% of enterprise GenAI deployments fail'). That report's methodology (52 interviews, self-reported outcomes, non-standard definition of 'failure' as no measurable P&L impact within six months) has been widely contested, and the 95% figure is doing real work in the Conclusion ('the answer is not more frameworks'). The inference is also weaker than stated: the report attributes failure to brittle workflows and integration gaps, which is consistent with, but does not establish, the need for standardized platform semantics rather than, say, better engineering practice. The claim should be qualified (e.g., 'attributed by one industry study') and ideally corroborated with the production-deployment evidence the paper already cites ([11]).
  4. [§V] The rossoctl section is presented as 'demonstrating that the primitives are implementable within the existing Cloud-OS substrate,' but it contains no evaluation at all — no description of workloads run, policies enforced, overhead measured, or even which of the thirteen primitives are implemented versus planned. For a position paper a full evaluation is not required, but the implementability claim should be scoped honestly: a sentence stating which primitives rossoctl currently enforces (identity attestation and MCP-gateway authorization, per Figure 2, appear to be the real ones) and which remain unimplemented would convert an assertion into evidence. Table I's 'Partial' status column presumably encodes this, but the mapping is never made explicit.
minor comments (7)
  1. [§IV-D and [27]] Reference [27] is cited for 'MCP standardizes via schema-documented server wrappers,' but [27] is an IBM tech report on the Kagenti/Kuadrant MCP gateway, not the MCP specification. Cite the actual MCP spec (Anthropic/modelcontextprotocol) for the protocol claim.
  2. [Table I] The Status (Open/Partial/Early) and Horizon (Near/Mid/Long) columns are assigned with no stated methodology. A one-paragraph rationale (what distinguishes 'Partial' from 'Early'; what evidence places context management at 'Long' but tool mediation at 'Mid') would make the table's most decision-relevant content defensible.
  3. [§IV-D, §IV-M] 'uTCP' is used repeatedly without citation or definition on first use. Also, the claim that 'MCP/uTCP/A2A evolve faster than Envoy release cycles' is asserted without support.
  4. [§IV-A] Heading typo: 'Agent as an first-class entity' → 'a first-class entity.' The same subsection introduces 'context-assemble → infer → tool-call → update' as the agent lifecycle, which differs in terminology from the §II.2 loop (perception/planning/action); unify.
  5. [§I, §VI] Several typesetting artifacts suggest missing italics commands: 'theclassical server era,' 'thecloud era,' 'PersistentV olumes,' 'agentic erais,' 'evaluateable' (§VII.6). Figure 2's caption has an unbalanced parenthesis ('run above the platform layer').
  6. [§I and references] Reference [4] cites a conference keynote with a timestamp for the 'LLM-OS framing'; Karpathy's later written articulation (or [62], already cited) would be a more stable source. Reference [62] is described as a 'blog post' — give a URL. Several arXiv citations ([5], [7], [8], [10], [17]–[21], [28]–[32]) are 2026 preprints; a sentence noting which are peer-reviewed would help readers weight the evidence.
  7. [§II.A] The claim that 'an agent written for LangGraph does not run on CrewAI' is true of framework internals but should acknowledge emerging portability layers the paper itself cites (A2A, MCP) more precisely — the portability gap is at the platform-guarantee level, not the wire level, and saying so would sharpen rather than weaken the argument.

Circularity Check

1 steps flagged · score 1.0 of 10

No load-bearing circular derivation; mild rhetorical tautology only in equating field progress with the proposed consensus layer.

  1. other [Abstract; §II.A Phase 1–3; §VI Lesson 1; §VIII]
    "Without that consensus, agentic applications cannot be written portably, platforms cannot compose reliably, and the field cannot advance beyond prototype deployments. We argue that the path forward is to follow the prior-wave methodology: derive new agentic abstractions... specify their semantics precisely, and consolidate around them — just as POSIX and Kubernetes consolidated their respective waves."

    Progress beyond prototypes is identified with achieving portable, agreed platform abstractions; the necessity of Agent-OS consensus is then inferred from the current lack of those same abstractions. This is a mild definitional loop in the success criterion, not a fitted prediction or self-citation chain that forces the thirteen primitives.

full rationale

This is a position/taxonomy paper, not a fitted-model or theorem paper. The claimed chain is historical analogy (POSIX/Kubernetes three-phase arc) plus a three-question semantic-gap method that maps OS/Cloud-OS primitives onto agent workloads and lists open specification problems. Nothing is predicted from a parameter fitted to the same quantity; there is no uniqueness theorem imported from the authors; rossoctl and related prototypes are offered as implementability illustrations, not as the sole warrant for the thirteen primitives. The only mild circularity is rhetorical: success is partly defined as portable consensus abstractions, so “without Agent-OS consensus the field cannot advance beyond prototypes” is close to true by the paper’s own success criterion rather than an independent empirical law. That does not collapse the taxonomy or the gap analysis into their inputs by construction. Historical-causality disputes (whether POSIX/K8s ratified winners rather than preceding them) are correctness concerns, not circularity. Score 1 reflects that single non-load-bearing rhetorical loop; steps are otherwise empty of construction-level reductions.

Assumptions & free parameters 0 free parameters · 5 assumptions · 4 invented entities

Load-bearing content is almost entirely domain assumptions and historical methodology claims, plus named platform constructs treated as the target abstraction set. No fitted free parameters. The main invented bundle is the Agent-OS primitive set as a consolidation interface; individual pieces have partial prior art, so independent evidence is mixed and mostly external to this paper’s validation.

assumptions (5)
  • domain assumption Major platform waves follow experimentation → articulation → consolidation, with POSIX and Kubernetes as the canonical consolidation milestones for classical and cloud eras.
    Used throughout Abstract, §I, §II.A, and §VI as the predictive template for the agentic era; historical pattern, not a proved law.
  • domain assumption Reliability, safety, cost control, and auditability of agent systems are infrastructure properties the platform must enforce; agents/prompts alone cannot provide them.
    Stated in §II (What an Agent-OS Is; lifecycle; multi-agent coordination) and Lesson 4; central to why an Agent-OS is required.
  • domain assumption OS and Cloud-OS semantics rest on outcome determinism and truthful self-reported health, which agents break via stochastic trajectories and possible strategic self-concealment.
    Core of §III semantic-gap analysis; supported by citations but still an idealized reading of prior platforms (which already tolerate some nondeterminism).
  • domain assumption Where prior-wave primitives still suffice (e.g., namespaces, filesystems), Agent-OS should extend rather than replace OS/Cloud-OS.
    Methodological rule in §IV intro and Lesson 2; shapes the entire primitive derivation.
  • ad hoc to paper Useful portable semantics can eventually be specified for stochastic scheduling, NL guardrails, principled context eviction, and related open problems listed in §VII.
    Required for the consolidation thesis to mirror POSIX/K8s; paper correctly marks many as Open/Long but still treats specification-led consolidation as the path forward.
invented entities (4)
  • Agent-OS as a canonical third platform layer
    purpose: Name the missing portable infrastructure beneath agent applications, analogous to OS and Cloud-OS.
    Framing device for the paper; related names exist (AIOS, LLM-OS), but this paper’s enterprise multi-environment Agent-OS scope is a postulated consolidation target.
  • Thirteen Agent-OS primitives taxonomy (Table I)
    purpose: Provide the candidate stable abstraction set for articulation/standardization.
    Derived by semantic-gap method; not claimed complete/minimal; several entries bundle existing partial systems under new platform semantics.
  • Semantic SBOM for skills
    purpose: Extend package provenance to NL skills with domain, model compatibility, and tool declarations enforced at load time.
    Proposed in §IV-C as required Agent-OS mechanism beyond Helm/OCI.
  • Formal theory of token relevance / principled context eviction
    purpose: Replace best-effort context management with guarantees analogous to virtual-memory eviction theory.
    Explicitly open in §IV-E and §VII.7; postulated research object rather than delivered theory.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards an Agent Operating System - Lessons from Classical and Cloud OS." pith.science (2026). https://pith.science/paper/U5JZNVVS

@misc{pith2026260725076,
  author       = {Pith},
  title        = {Pith review of: Towards an Agent Operating System - Lessons from Classical and Cloud OS},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/U5JZNVVS}},
  note         = {Machine review of arXiv:2607.25076}
}
read the original abstract

Every major wave of platform software follows the same arc: an initial period of experimentation with competing frameworks and ad-hoc implementations, followed by the articulation of a small set of stable abstractions with well-defined semantics, and finally consolidation around those abstractions into a platform that applications can portably target. POSIX did this for classical operating systems; Kubernetes did it for the cloud. Agentic AI systems - autonomous, LLM-driven agents that plan, use tools, maintain memory, and collaborate - are currently in the experimentation phase of the third such wave. dozens of frameworks and protocols have emerged, but no community consensus exists on what the core abstractions are or what guarantees they carry. Without that consensus, agentic applications cannot be written portably, platforms cannot compose reliably, and the field cannot advance beyond prototype deployments. We argue that the path forward is to follow the prior-wave methodology: derive new agentic abstractions by extending classical OS and cloud OS primitives to stochastic, natural-language-mediated execution, specify their semantics precisely, and consolidate around them - just as POSIX and Kubernetes consolidated their respective waves.

Figures

Figures reproduced from arXiv: 2607.25076 by the authors.

Figure 1
Figure 1. The Autonomous Agent Paradigm [14] with a practical build-deploy [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The rossoctl architecture, implementing several Agent-OS primitives [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

67 extracted references · 21 linked inside Pith

  1. [63]

    The GenAI divide: State of AI in business 2025,

    A. Challapally, C. Pease, R. Raskar, and P. Chari, “The GenAI divide: State of AI in business 2025,” MIT Media Lab, Project NANDA (Networked Agents and Decentralized Architecture), Tech. Rep., Jul

    2025

  2. [11]

    Why do multi-agent LLM systems fail?

    M. Cemri, M. Z. Pan, S. Yang, L. A. Agrawal, B. Chopra, R. Tiwari, K. Keutzer, A. Parameswaran, D. Klein, K. Ramchandran, M. Zaharia, J. E. Gonzalez, and I. Stoica, “Why do multi-agent LLM systems fail?” inAdvances in Neural Information Processing Systems (NeurIPS), Track on Datasets and Benchmarks, 2025, arXiv:2503.13657

    arXiv 2025

  3. [1]

    AIOS: LLM agent operating system,

    K. Mei, X. Zhu, W. Xu, W. Hua, M. Jin, Z. Li, S. Xu, R. Ye, Y . Ge, and Y . Zhang, “AIOS: LLM agent operating system,” inProceedings of the Conference on Language Modeling (COLM), 2025. [Online]. Available: https://arxiv.org/abs/2403.16971

    arXiv 2025

  4. [2]

    MemGPT: Towards LLMs as operating systems,

    C. Packeret al., “MemGPT: Towards LLMs as operating systems,”arXiv preprint, 2023, arXiv:2310.08560

    arXiv 2023

  5. [3]

    AgentRM: An OS-inspired resource manager for LLM agent systems,

    J. She, “AgentRM: An OS-inspired resource manager for LLM agent systems,” 2026. [Online]. Available: https://arxiv.org/abs/2603.13110

    arXiv 2026

  6. [4]

    State of GPT,

    A. Karpathy, “State of GPT,” Keynote, Microsoft Build 2023, 2023, LLM-as-OS framing introduced at timestamp ∼18:00. [Online]. Available: https://www.youtube.com/watch?v=bZQun8Y4L2A

    2023

  7. [5]

    Agentos: From application silos to a natural language-driven data ecosystem,

    R. Liu, T. Zhe, D. Wang, Z. Yao, K. Liu, Y . Fu, H. Liu, and J. Pei, “Agentos: From application silos to a natural language-driven data ecosystem,”arXiv preprint arXiv:2603.08938, 2026

    arXiv 2026

  8. [6]

    Frontier models are capable of in-context scheming,

    A. Meinke, B. Schoen, J. Scheurer, M. Balesni, R. Shah, and M. Hobbhahn, “Frontier models are capable of in-context scheming,”

Show all 67 references
  1. [7]

    “I Must Delete the Evidence

    T. Rivasseau and B. Fung, ““I Must Delete the Evidence”: AI agents explicitly cover up fraud and violent crime,” 2026. [Online]. Available: https://arxiv.org/abs/2604.02500

    2026 arXiv

  2. [8]

    ReliabilityBench: Evaluating LLM agent reliability under production-like stress conditions,

    A. Gupta, “ReliabilityBench: Evaluating LLM agent reliability under production-like stress conditions,” 2026. [Online]. Available: https://arxiv.org/abs/2601.06112

    2026

  3. [9]

    SagaLLM: Context management, validation, and transaction guarantees for multi-agent LLM planning,

    E. Y . Chang and L. Geng, “SagaLLM: Context management, validation, and transaction guarantees for multi-agent LLM planning,”Proceedings of the VLDB Endowment, vol. 18, no. 12, 2025, arXiv:2503.11951

    2025 arXiv

  4. [10]

    AI harness engineering: A runtime substrate for foundation-model software agents,

    H. Zhong and S. Zhu, “AI harness engineering: A runtime substrate for foundation-model software agents,” 2026. [Online]. Available: https://arxiv.org/abs/2605.13357

    2026 arXiv

  5. [12]

    AgentCompass: Towards reliable evaluation of agentic workflows in production,

    N. Kartik, G. Sapra, R. Hada, and N. Pareek, “AgentCompass: Towards reliable evaluation of agentic workflows in production,” 2025. [Online]. Available: https://arxiv.org/abs/2509.14647

    2025

  6. [13]

    Taming various privilege escalation in LLM-based agent systems: A mandatory access control framework,

    Z. Ji, D. Wu, W. Jiang, P. Ma, Z. Li, Y . Gao, S. Wang, and Y . Li, “Taming various privilege escalation in LLM-based agent systems: A mandatory access control framework,” 2026. [Online]. Available: https://arxiv.org/abs/2601.11893

    2026

  7. [14]

    AI agent systems: Architectures, applications, and evaluation,

    B. Xu, “AI agent systems: Architectures, applications, and evaluation,” arXiv preprint arXiv:2601.01743, 2026. [Online]. Available: https: //doi.org/10.48550/arXiv.2601.01743

    2026 doi

  8. [15]

    Memory os of ai agent,

    J. Kang, M. Ji, Z. Zhao, and T. Bai, “Memory os of ai agent,” 2025. [Online]. Available: https://arxiv.org/abs/2506.06326

    2025 arXiv

  9. [16]

    MemOS: Memory management as an operating system primitive for LLM agents,

    Liet al., “MemOS: Memory management as an operating system primitive for LLM agents,”arXiv preprint, 2025

    2025

  10. [17]

    AC4A: Access control for agents,

    R. K. Sharma and D. Grossman, “AC4A: Access control for agents,”

  11. [18]

    SkVM: Compiling skills for efficient execution everywhere,

    L. Chen, E. Feng, Y . Xia, and H. Chen, “SkVM: Compiling skills for efficient execution everywhere,” 2026, 26 primitive capability dimensions; up to 40% token reduction and 3.2 × speedup over baseline execution. [Online]. Available: https://arxiv.org/abs/2604.03088

    2026 arXiv

  12. [19]

    Quine: Realizing llm agents as native posix processes,

    H. Ke, “Quine: Realizing llm agents as native posix processes,” 2026. [Online]. Available: https://arxiv.org/abs/2603.18030

    2026 arXiv

  13. [20]

    Crab: A semantics-aware checkpoint/restore runtime for agent sandboxes,

    T. Wu, C. Chang, L. Cao, W. Gao, and W. Wang, “Crab: A semantics-aware checkpoint/restore runtime for agent sandboxes,” 2026. [Online]. Available: https://arxiv.org/pdf/2604.28138

    2026 arXiv

  14. [21]

    AgentCgroup: Understanding and controlling OS resources of AI agents,

    Y . Zheng, J. Fan, Q. Fu, Y . Yang, W. Zhang, and A. Quinn, “AgentCgroup: Understanding and controlling OS resources of AI agents,” 2026. [Online]. Available: https://arxiv.org/abs/2602.09345

    2026 arXiv

  15. [22]

    The transaction concept: Virtues and limitations,

    J. Gray, “The transaction concept: Virtues and limitations,” in Proceedings of the 7th International Conference on Very Large Data Bases (VLDB), Cannes, France, 1981. [Online]. Available: https://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf

    1981

  16. [23]

    The protection of information in computer systems,

    J. H. Saltzer and M. D. Schroeder, “The protection of information in computer systems,”Proceedings of the IEEE, vol. 63, no. 9, 1975

    1975

  17. [24]

    Can LLMs detect their own hallucinations?

    S. Kadotani, K. Nishida, and K. Nishida, “Can LLMs detect their own hallucinations?”arxiv:2511.11087, 2025

    2025

  18. [25]

    Large language models cannot self-correct reasoning yet,

    J. Huanget al., “Large language models cannot self-correct reasoning yet,” inProceedings of the International Conference on Learning Representations (ICLR), 2024

    2024

  19. [26]

    Agent skills in the wild: Security vulnerability analysis,

    Liuet al., “Agent skills in the wild: Security vulnerability analysis,” arXiv preprint, 2026, 26% of skills contain at least one vulnerability

    2026

  20. [27]

    Kagenti/Kuadrant MCP gateway: Kubernetes-native control plane for agent tool access,

    IBM Research, “Kagenti/Kuadrant MCP gateway: Kubernetes-native control plane for agent tool access,” IBM Research, Tech. Rep., 2026

    2026

  21. [28]

    Verify before you commit: Towards faithful reasoning in LLM agents via self-auditing,

    W. Yuan, C. Lin, J. Chen, J. Xu, X. Wang, and E. C. H. Ngai, “Verify before you commit: Towards faithful reasoning in LLM agents via self-auditing,” 2026. [Online]. Available: https://arxiv.org/abs/2604.08401

    2026 arXiv

  22. [29]

    Building effective AI coding agents for the terminal: Scaffolding, harness, context engineering, and lessons learned,

    N. D. Q. Bui, “Building effective AI coding agents for the terminal: Scaffolding, harness, context engineering, and lessons learned,” 2026. [Online]. Available: https://arxiv.org/abs/2603.05344

    2026

  23. [30]

    ClawVM: Harness-managed virtual memory for stateful tool-using LLM agents,

    M. Rafique and L. Bindschaedler, “ClawVM: Harness-managed virtual memory for stateful tool-using LLM agents,” 2026. [Online]. Available: https://arxiv.org/abs/2604.10352

    2026 arXiv

  24. [31]

    Context Kubernetes: Declarative orchestration of enterprise knowledge for agentic AI systems,

    C. Mouzouni, “Context Kubernetes: Declarative orchestration of enterprise knowledge for agentic AI systems,” 2026. [Online]. Available: https://arxiv.org/abs/2604.11623

    2026 arXiv

  25. [32]

    InfiAgent: An infinite-horizon framework for general-purpose autonomous agents,

    C. Yu, Y . Wang, S. Wang, H. Yang, and M. Li, “InfiAgent: An infinite-horizon framework for general-purpose autonomous agents,”

  26. [33]

    Mem0: Scalable agent memory via structured retrieval,

    P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav, “Mem0: Scalable agent memory via structured retrieval,”arXiv preprint, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2504.19413

    2025 doi arXiv

  27. [34]

    Zep/Graphiti: Knowledge graph memory for production AI agents,

    D. Rasmussenet al., “Zep/Graphiti: Knowledge graph memory for production AI agents,”arXiv preprint, 2025

    2025

  28. [35]

    Available: https://arxiv.org/abs/2601.03204

    [Online]. Available: https://arxiv.org/abs/2601.03204

  29. [36]

    Spiffe-based zero-trust authen- tication for ai agent ecosystems,

    K. Pappu, B. Bhushan, and A. Mittal, “Spiffe-based zero-trust authen- tication for ai agent ecosystems,” in2025 International Conference on Computer and Applications (ICCA), 2025

    2025

  30. [37]

    Feature request: Stacking multiple workload attestors for composite identity verification #6640

    S. developer community, “Feature request: Stacking multiple workload attestors for composite identity verification #6640.” [Online]. Available: https://github.com/spiffe/spire/issues/6640

  31. [38]

    Evermemos: A self-organizing memory operating system for structured long-horizon reasoning,

    C. Hu, X. Gao, Z. Zhou, D. Xu, Y . Bai, X. Li, H. Zhang, T. Li, C. Zhang, L. Bing, and Y . Deng, “Evermemos: A self-organizing memory operating system for structured long-horizon reasoning,” 2026. [Online]. Available: https://arxiv.org/abs/2601.02163

    2026

  32. [39]

    AgenTRIM: Tool risk mitigation for agentic AI,

    R. Betser, S. Bose, A. Giloni, C. Picardi, S. Padakandla, and R. Vainshtein, “AgenTRIM: Tool risk mitigation for agentic AI,” 2026. [Online]. Available: https://arxiv.org/abs/2601.12449

    2026

  33. [40]

    Options, not clicks: Lattice refinement for consent-driven MCP authorization,

    Y . Li, Y . Chen, P. Wang, I. Khabra, F. H. Shezan, Y . Feng, and Y . Tian, “Options, not clicks: Lattice refinement for consent-driven MCP authorization,” 2026. [Online]. Available: https://arxiv.org/abs/2605.11360

    2026 arXiv

  34. [41]

    Uncertainty-aware, risk- adaptive access control for agentic systems using an LLM-judged TBAC model,

    C. Fleming, A. Kundu, and R. Kompella, “Uncertainty-aware, risk- adaptive access control for agentic systems using an LLM-judged TBAC model,” 2025. [Online]. Available: https://arxiv.org/abs/2510.11414

    2025

  35. [42]

    Where llm agents fail and how they can learn from failures,

    K. Zhu, Z. Liu, B. Li, M. Tian, Y . Yingxuan, and J. e. Zhang, “Where llm agents fail and how they can learn from failures,” 2025. [Online]. Available: https://arxiv.org/abs/2509.25370

    2025

  36. [43]

    Langflow

    “Langflow.” [Online]. Available: https://www.langflow.org/

  37. [44]

    Unreliable failure detectors for reliable distributed systems,

    T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,”Journal of the ACM, vol. 43, no. 2, 1996

    1996

  38. [45]

    Available: https://mlflow.org/

    “Mlflow.” [Online]. Available: https://mlflow.org/

  39. [46]

    Security analysis of AI-generated code: 45% fail security tests; failure rates flat across model sizes,

    Veracode Research Report, “Security analysis of AI-generated code: 45% fail security tests; failure rates flat across model sizes,” Aug. 2025

    2025

  40. [47]

    Available: https://arize.com/phoenix/

    “arize.” [Online]. Available: https://arize.com/phoenix/

  41. [48]

    Human-written vs. AI-generated code: A large-scale study of defects, vulnerabilities, and complexity,

    D. Cotroneo, C. Improta, and P. Liguori, “Human-written vs. AI-generated code: A large-scale study of defects, vulnerabilities, and complexity,” inProceedings of the 36th IEEE International Symposium on Software Reliability Engineering (ISSRE), 2025, arXiv:2508.21634

    2025 arXiv

  42. [49]

    Hallucinated packages: AI-assisted software supply chain risk,

    Mend.io, “Hallucinated packages: AI-assisted software supply chain risk,” Mend.io Security Report, Aug. 2025, 43% of hallucinated names repeated; proof-of-concept package downloaded 30,000+ times

    2025

  43. [50]

    State of AI vs. human code generation: Security, quality, and defect analysis,

    CodeRabbit, “State of AI vs. human code generation: Security, quality, and defect analysis,” CodeRabbit Industry Report, Dec. 2025. [Online]. Available: https://www.coderabbit.ai/blog/ state-of-ai-vs-human-code-generation-report

    2025

  44. [51]

    Praxis: A new network foundation for AI workloads,

    IBM Research, “Praxis: A new network foundation for AI workloads,” https://github.com/praxis-proxy/praxis, 2026

    2026

  45. [52]

    [Online]

    Solo.io. [Online]. Available: https://agentgateway.dev/

  46. [53]

    We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs,

    J. Spracklen, R. Wijewickrama, A. H. M. N. Sakib, A. Maiti, B. Viswanath, and M. Jadliwala, “We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs,” inProceedings of the 34th USENIX Security Symposium, 2025, arXiv:2406.10279

    2025 arXiv

  47. [54]

    AutoGen: Enabling next-gen LLM applications via multi-agent conversation,

    Q. Wu, G. Bansal, J. Zhang, Y . Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang, “AutoGen: Enabling next-gen LLM applications via multi-agent conversation,” GitHub & arXiv:2308.08155, 2023. [Online]. Available: http...

    2023 arXiv

  48. [55]

    LangChain: Building applications with LLMs through composability,

    H. Chaseet al., “LangChain: Building applications with LLMs through composability,” GitHub, 2023, includes LangGraph for stateful multi- agent orchestration. [Online]. Available: https://github.com/langchain-ai/ langchain

    2023

  49. [56]

    Rossoctl: An open-source agent platform on kubernetes,

    IBM Research, “Rossoctl: An open-source agent platform on kubernetes,” GitHub, 2025. [Online]. Available: ibm.biz/rossoctl

    2025

  50. [57]

    Available: https://github.com/kagent-dev/kagent

    “kagent.” [Online]. Available: https://github.com/kagent-dev/kagent

  51. [58]

    openshell

    “openshell.” [Online]. Available: https://github.com/NVIDIA/OpenShell

  52. [59]

    Swarm: An experimental multi-agent orchestration framework,

    OpenAI, “Swarm: An experimental multi-agent orchestration framework,” GitHub, 2024, open-source experimental multi-agent framework. [Online]. Available: https://github.com/openai/swarm

    2024

  53. [60]

    Probguard: Probabilistic runtime monitoring for llm agent safety,

    H. Wang, C. M. Poskitt, J. Wei, and J. Sun, “Probguard: Probabilistic runtime monitoring for llm agent safety,” 2026. [Online]. Available: https://arxiv.org/abs/2508.00500

    2026

  54. [61]

    Deontic temporal logic for formal verification of ai ethics,

    P. T. V . and S. Rao, “Deontic temporal logic for formal verification of ai ethics,” 2026. [Online]. Available: https://arxiv.org/abs/2501.05765

    2026

  55. [62]

    AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents,

    H. Wang, C. M. Poskitt, and J. Sun, “AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents,” inProceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE), 2026. [Online]. Available: https://arxiv.org/abs/2503.18666

    2026 arXiv

  56. [65]

    LLM wiki: Notes toward LLMs as operating systems,

    A. Karpathy, “LLM wiki: Notes toward LLMs as operating systems,” Online blog post, 2025

    2025

  57. [2024]

    Available: https://arxiv.org/abs/2412.04984

    [Online]. Available: https://arxiv.org/abs/2412.04984

    arXiv

  58. [2025]

    Available: https://nanda.media.mit.edu

    [Online]. Available: https://nanda.media.mit.edu

  59. [2026]

    Available: https://arxiv.org/abs/2603.20933

    [Online]. Available: https://arxiv.org/abs/2603.20933

Pith tools

Reviewed July 31, 2026 · model on record in the stance chip above.