Pith. sign in

REVIEW 3 major objections 4 minor 66 references

The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems

T0 review · 3 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read This paper proposes AOS, a vendor-neutral reference operating architecture for making distributed AI agents governable, observable, and interoperable.

desk verdict A well-scoped agentic architecture proposal that is honest about its open dependency on semantic interoperability; worth refereeing, not yet a validated solution. read the letter →

arxiv 2608.03214 v1 pith:YQZZJD65 submitted 2026-08-04 cs.AI

Ankur Sharma , Deep Shah This is my paper
classification cs.AI
keywords agentoperatingsystemreferencearchitectureagenticAIcapabilitydiscoverydelegationconfidencesemanticobservabilitydistributedsystems
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

This paper proposes a vendor-neutral reference operating architecture, the Agent Operating System (AOS), for distributed agentic systems — software in which large language models reason, call tools, retrieve state, delegate subtasks, and act on behalf of users. The central claim is that today's execution-centric stacks, however capable individually, lack a stable layer for governing intent, authority, delegation, and uncertainty, so every application invents its own mapping from objective to policy to provider. AOS draws one boundary around two planes: a Control & Governance Plane that owns intent, policy, trust, confidence, and audit, and a Runtime & Coordination Plane that owns agent lifecycle, routing, scheduling, context, and assurance. If the architecture is sound, heterogeneous providers become substitutable behind stable capability contracts, delegated authority stays bounded and traceable, and confidence becomes an action trigger rather than a dashboard number — which is why the paper matters to anyone building or operating multi-provider agent systems.

What carries the argument

The load-bearing mechanism is the two-plane boundary plus its canonical objects. Plane 1, the Control & Governance Plane, is the semantic authority: it owns IntentEnvelope, capability query and manifest, PolicyDecision, TrustDecision, DelegationContext, ConfidenceRecord, and the authorized ExecutionDirective. Plane 2, the Runtime & Coordination Plane, owns ExecutionEvent, ExecutionResult, lifecycle state, scheduling queues, and protocol adapters. The coupling objects are the ExecutionDirective (a bounded contract carrying capability, provider, policy references, delegation context, confidence thresholds, and evidence obligations) and the ExecutionResult (outcome plus evidence, residual risk,

What would settle it

Two independent AOS-conformant implementations could settle the claim: have each advertise ai.case.summary.generate with a different actual meaning of 'cited', run one intent through capability discovery against the other's registry, and check whether the selected provider's output satisfies the requester's success criteria; a mis-selection producing an uncited or wrongly-scoped summary falsifies capability-centric interoperability. A second test: register a provider declaring side_effects: none that nevertheless writes external state and confirm whether runtime assurance or audit catches the

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is architectural: distributed agentic systems compose cleanly and fail safely only when a dedicated operating boundary manages the semantic resources of agency — intent, capability, authority, delegation, confidence, and evidence — in the disciplined way conventional operating systems manage processes, memory, and files. AOS defines this boundary with two internal planes. The Control & Governance Plane converts an objective into an authorized execution directive: it normalizes intent, discovers eligible capabilities through stable identifiers such as ai.case.summary.generate, applies hard policy constraints before any utility ranking, evaluates trust a

Load-bearing premise

The load-bearing premise is that a stable capability name such as ai.case.summary.generate denotes the same input/output contract, side-effect semantics, and success criteria no matter which provider advertises it — the paper itself notes in Section 15.4 that if two providers interpret 'case' or 'cited' differently, discovery creates false interoperability.

Editorial extensions

If this is right

  • Applications can request capabilities by stable name and swap providers — model, workflow, human service — without changing consumer code, with hard policy constraints such as residency, authorization, protocol, and evidence applied before any quality or cost ranking.
  • Delegation becomes a first-class, observable object: an operator can reconstruct which actions and data accesses occurred under a particular delegated authority, closing the gap where conventional traces cannot attribute actions to delegations.
  • Confidence thresholds gate behavior: low confidence can trigger retry, fallback, escalation, or termination, and high-impact actions can require higher confidence plus human approval, rather than treating model probability as operational confidence.
  • AOS deployments can range from embedded single-process to federated multi-organization without changing the architecture; local domains keep authority, and capability discovery is separated from permission to invoke.
  • Existing protocols, telemetry systems, and kernel mechanisms become adapters and enforcement substrates inside the AOS boundary, so adoption does not require replacing the ecosystem.

Reading between the lines

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

  • Editorial extension: the capability contract makes AOS testable where reference architectures usually are not — two independent conforming registries should mutually discover and invoke providers for the same identifier. A federation stress test with a model, a workflow engine, and a human service implementing one capability under identical hard constraints would be the cleanest early probe.
  • Editorial extension: if the architecture is right, the contested asset shifts from model quality to capability-contract quality; the semantic stability of manifests and the evidence they carry becomes the scarce resource, so domain-ontology work in finance, healthcare, and telecom will likely decide whether AOS gains traction.
  • Editorial extension: the paper's own limitation list names the sharpest falsifiable targets — false interoperability, undeclared side effects, and confidence double-counting when two assessments derive from the same evidence — each of which a conformance test suite could target directly.
  • Editorial extension: the authority-monotonicity invariant assumes atomic budget accounting across concurrent child delegations, a distributed-transaction problem the paper leaves open; a test hammering concurrent delegation with mid-flight revocation would probe whether revocation semantics can actually be preserved across domains.
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

3 major / 4 minor

Summary. The paper proposes the Agent Operating System (AOS), a vendor-neutral reference operating architecture for distributed agentic systems. AOS is defined by two internal planes: a Control & Governance Plane (intent, policy, authority, confidence, audit, human oversight) and a Runtime & Coordination Plane (agent lifecycle, routing, scheduling, context, reliability, protocol mediation). The architecture is capability-centric: consumers request stable capability identifiers and providers are treated as substitutable behind that contract. The manuscript specifies canonical objects (IntentEnvelope, CapabilityManifest, DelegationContext, ExecutionDirective, ConfidenceRecord, AuditEvent), a set of architectural invariants, a mathematical model (feasibility, provider selection, delegation attenuation, confidence aggregation, scheduling, placement), deployment profiles (embedded, centralized, regional, federated, edge, sovereign), reliability dimensions, a threat model, and conformance profiles. The paper is openly positioned as a research architecture proposal; it does not claim empirical benchmark superiority and explicitly defers several detailed mechanisms to planned AOS specifications (AOS-0002 through AOS-0010), of which only the prior AOS-0000 paper [1] is published.

Significance. If adopted, AOS could provide a much-needed common vocabulary and architectural template for the rapidly fragmenting agentic AI ecosystem. The paper's principal strengths are its clear conceptual decomposition (two planes), the explicit treatment of authority-preserving delegation and confidence as a control signal, the detailed canonical object definitions, and the honest labeling of the mathematical model as decomposition/accounting identities rather than analytic results (Section 12.1). The threat model, conformance profiles, and reliability framework are useful contributions. However, the paper is a proposal, not a validated architecture: the central claims of governance, reliability, observability, and interoperability are not demonstrated by an implementation or empirical study, and two load-bearing dependencies are explicitly deferred to unpublished future specifications. The work remains significant as a well-structured architectural foundation, provided these dependencies are resolved or the claims are appropriately scoped.

major comments (3)
  1. [§15.4, §9.3, §11.4] The core capability-centric abstraction—stable capability ids with substitutable providers—requires semantic equivalence of contracts. §15.4 admits the failure mode: 'If two providers both advertise ai.case.summary.generate but interpret "case" or "cited" differently, discovery creates false interoperability.' §9.3 checks only schema-level input/output compatibility; §11.4 manifests carry schema URNs and versions but no mechanism for semantic equivalence. AOS-0004 and AOS-0005, which are planned and not yet published, are supposed to define contracts, evaluation profiles, and ontologies. Thus the central claim that heterogeneous components can be composed into interoperable systems (Abstract) is conditional on an unsolved standardization problem. The paper should either provide a concrete mechanism (e.g., a semantic-equivalence verification protocol or explicit scoping of the claim to en
  2. [Appendix C.1 / Appendix F] INV-002 requires that 'a consequential action MUST NOT proceed without a valid authority chain and an applicable policy decision.' But 'consequential action' is defined only in Appendix F, and the definition explicitly states that 'The full side-effect taxonomy is deferred to AOS-0004.' Without such a taxonomy, the architecture cannot determine which actions trigger INV-002 and the associated human-oversight requirements. §15.10 acknowledges this dependency: 'whether an action is consequential depends on declared side effects, so detection of undeclared side effects falls to runtime assurance and lower-level enforcement.' This dependency should be resolved in AOS-0001 or the invariant should be explicitly scoped to declared side effects with a residual-risk caveat. As written, a central invariant of the architecture rests on a not-yet-defined taxonomy.
  3. [§14.12, §15.10] The abstract claims AOS can compose heterogeneous components into 'governable, reliable, observable, and interoperable agentic systems.' However, §15.10 states that 'the paper proposes an architecture and mathematical model but does not present a large-scale empirical evaluation,' and Table 15 offers only a proposed evaluation methodology (conformance tests, fault injection, delegation observability studies, etc.) without results. No prototype results, aos-core evidence, or scenario studies are presented. For a reference architecture, a conceptual contribution can be valuable, but the strong claims in the abstract should either be demonstrated in at least a limited proof-of-concept evaluation or reformulated as testable hypotheses and open questions. The paper would be strengthened by a concrete walkthrough of the reference sequences in Appendix B against a lightweight implementation.
minor comments (4)
  1. [§11.5] The ExecutionDirective example contains duplicate keys: 'component_warn_below' appears twice. One occurrence should be removed or renamed.
  2. [§12.12] Equations (17) and (18) are presented as a general control-loop formulation but are never used in any subsequent analysis or example. Consider either deleting them or connecting them to a concrete scenario (e.g., the fallback sequence in Appendix B.2) to make their role explicit.
  3. [§12.2] The notation section redefines symbols (C, P, R, etc.) with meanings that differ from Section 6. The paper says 'Object-model symbols from Section 6 ... are redefined here,' but the transition is abrupt. A small table mapping old and new notation would improve readability.
  4. [Appendix F] The term 'consequential action' is used throughout the main text (§6.15, §8, §14) but defined only in the glossary. Move the definition (or a pointer to it) to Section 6, since it plays a central role in the invariants.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the AOS proposal is self-contained, makes no fitted predictions, and its self-citations are provenance rather than load-bearing evidence.

full rationale

This paper is a reference-architecture proposal, not an empirical derivation. Its mathematical model (Equations 5, 9, 12, 14) contains free weights, illustrative values, and decomposition or accounting identities, and the paper explicitly states that 'Several equations are decomposition or accounting identities rather than analytical results' (Section 12.1) and that 'Worked examples are illustrative and do not represent benchmark results' (Section 3.5, Table 2). No parameter is fitted to data and then relabeled as a prediction, and no capability score, confidence aggregate, or provider ranking is claimed as an empirical result. The self-citation to Sharma and Shah [1] (Appendix G, AC-003) establishes provenance of the AOS concept and describes AOS-0001 as an extension of that work, not as proof of the architecture's validity; it is not used to import a uniqueness theorem or to forbid alternatives. References to planned AOS-0004/AOS-0005 are explicitly deferred future work and are not presented as established results. The acknowledged semantic-interoperability risk (Section 15.4) and the limitation that consequential-action detection depends on declared side effects (Section 15.10) are honest assumptions and limitations, not circular reductions: the architecture does not derive the existence of shared semantics from its own definitions. Therefore no load-bearing step reduces to its own inputs, and the circularity score is 0.

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

The paper introduces no new physical or causal entities. Its two planes, canonical objects, and semantic resource categories are architectural abstractions, not proposed mechanisms needing independent evidence.

free parameters (4)
  • provider selection utility weights {w_f, w_t, w_c, w_r, w_g, w_l, w_k, w_e, w_q}
    Introduced in Eq (5) as intent- and policy-dependent weights for multi-objective provider ranking; no values or calibration method are specified.
  • confidence aggregation weights {alpha_j}
    Introduced in Eq (9); non-negative, sum to 1, but exact values and dependence handling deferred to AOS-0005.
  • confidence floor epsilon = small positive constant
    Introduced in Eq (9) to prevent zero collapse of geometric mean; value unspecified.
  • placement objective weights {w_L, w_K, w_E, w_Q, w_R}
    Introduced in Eq (14) for placement optimization; no values or learning procedure specified.
assumptions (6)
  • domain assumption Agentic systems combine probabilistic decision components with deterministic external effects and may span multiple runtimes and administrative domains.
    Stated in Section 3.5, Table 2 as an assumption; the entire architecture is predicated on this characterization.
  • domain assumption Conventional operating systems and platform services remain present and provide lower-level execution and enforcement.
    Stated in Section 3.5; boundary between AOS and external dependencies depends on this.
  • domain assumption Capability contracts can be made semantically interoperable across providers using schemas, side-effect declarations, and domain ontologies.
    Required for capability-centric discovery; Section 15.4 acknowledges ontology risk and defers to future profiles.
  • domain assumption Delegation scope, budget, and validity can be compared monotonically using profile-defined scope semantics.
    Needed for authority monotonicity (Eqs 6-8); Section 12.6 says 'AOS profiles must define how scopes are compared.'
  • standard math Standard math results used: M/G/1 queueing delay formula (Eq 12), probability and reliability formulas (Eqs 19-20).
    Used to motivate scheduling and reliability; standard results, correctly cited.
  • ad hoc to paper The two-plane separation is the right decomposition for an agentic operating architecture.
    Architectural postulate in Sections 8 and 15.2; not derived from requirements and not empirically tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems." pith.science (2026). https://pith.science/paper/YQZZJD65

@misc{pith2026260803214,
  author       = {Pith},
  title        = {Pith review of: The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YQZZJD65}},
  note         = {Machine review of arXiv:2608.03214}
}
read the original abstract

Large language models have transformed artificial intelligence from isolated prediction services into components of long-running, distributed systems that reason, invoke tools, retrieve external state, delegate tasks, and act on behalf of users and organizations. The surrounding ecosystem has responded with agent frameworks, workflow engines, model-serving platforms, memory systems, communication protocols, and observability tools. These technologies improve execution, but they do not provide a stable, implementation-independent operating architecture for governing intent, selecting capabilities, preserving authority across delegation, controlling uncertainty, coordinating runtime behavior, and reconstructing why consequential actions occurred. This paper proposes the Agent Operating System (AOS), a vendor-neutral reference operating architecture for distributed agentic systems. AOS contains two internal planes: a Control & Governance Plane responsible for intent, policy, trust, authority, confidence, auditability, observability, and human oversight; and a Runtime & Coordination Plane responsible for agent lifecycle, workflow coordination, model and tool routing, context and memory coordination, scheduling, traffic management, and runtime assurance. Platform services, Linux or Windows, container runtimes, and physical infrastructure remain outside the AOS boundary and are integrated through explicit interfaces. The paper specifies AOS concepts, invariants, interface objects, optimization objectives, deployment profiles, and reliability responsibilities. It also identifies tradeoffs and unresolved research questions. AOS is not presented as a replacement for existing frameworks or infrastructure; it is proposed as the operating architecture through which heterogeneous components can be composed into governable, reliable, observable, and interoperable agentic systems.

Figures

Figures reproduced from arXiv: 2608.03214 by the authors.

Figure 1
Figure 1. From an execution-centric agent stack to an operating architecture with explicit governance, authority, assurance, and feedback. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Traditional computing organizes execution resources; agentic computing adds a semantic hierarchy from objective and intent to capability, [PITH_FULL_IMAGE:figures/full_fig_p015_2.png] view at source ↗
Figure 3
Figure 3. Evidence-driven AOS control loop. The architecture reconciles intended, authorized, observed, and resulting state through an auditable closed [PITH_FULL_IMAGE:figures/full_fig_p024_3.png] view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: AOS unified reference architecture. Only the Control & Governance Plane and Runtime & Coordination Plane are inside the AOS boundary; [PITH_FULL_IMAGE:figures/full_fig_p026_4.png]
Figure 5
Figure 5. Figure 5: Identical AOS planes operate over Linux and Windows through platform adapters while sharing external services and hardware resources. [PITH_FULL_IMAGE:figures/full_fig_p028_5.png]
Figure 6
Figure 6. Figure 6: Authority and delegation chain from human objective to kernel or system execution, with scope and lineage preserved at every transition. [PITH_FULL_IMAGE:figures/full_fig_p031_6.png]
Figure 7
Figure 7. Figure 7: Agentic trace and delegation graph enriched with intent, policy, confidence, capability, context, causal, and lineage edges. [PITH_FULL_IMAGE:figures/full_fig_p038_7.png]
Figure 8
Figure 8. Figure 8: Capability selection and fallback. Hard constraints define the feasible set before utility ranking; failed verification triggers bounded fallback [PITH_FULL_IMAGE:figures/full_fig_p041_8.png]
Figure 9
Figure 9. Figure 9: Canonical AOS intent and execution lifecycle with explicit terminal outcomes and bounded retry or fallback transitions. [PITH_FULL_IMAGE:figures/full_fig_p044_9.png]
Figure 10
Figure 10. Figure 10: Federated multi-region AOS. Regional control and runtime domains share capability and policy federation while retaining local execution and [PITH_FULL_IMAGE:figures/full_fig_p046_10.png]
Figure 11
Figure 11. Figure 11: Deployment profiles: embedded, centralized, regional, federated, edge, and sovereign. [PITH_FULL_IMAGE:figures/full_fig_p047_11.png]
Figure 12
Figure 12. Figure 12: Reliability is produced across control, runtime, platform, operating-system, and infrastructure layers and governed end to end. [PITH_FULL_IMAGE:figures/full_fig_p048_12.png]
Figure 13
Figure 13. Figure 13: End-to-end AOS sequence from human intent through discovery, policy and trust, runtime execution, provider and operating-system [PITH_FULL_IMAGE:figures/full_fig_p061_13.png]
Figure 14
Figure 14. Figure 14: Provider failure and regional fallback sequence with feasibility re-evaluation, bounded attempt budgets, confidence verification, and audit [PITH_FULL_IMAGE:figures/full_fig_p062_14.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

66 extracted references · 59 canonical work pages

  1. [1]

    Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems

    A. Sharma and D. Shah, “Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems,” arXiv:2606.01508, 2026

    work page Pith review arXiv 2026

  2. [2]

    AIOS: LLM Agent Operating System,

    K. Mei et al., “AIOS: LLM Agent Operating System,” arXiv:2403.16971, 2024

    arXiv 2024

  3. [3]

    TopoClaw: A Human-Centric and Topology-Aware Agent Operating System

    H. Huang et al., “TopoClaw: A Human-Centric and Topology-Aware Agent Operating System,” arXiv:2605.15556, 2026

    work page Pith review arXiv 2026

  4. [4]

    Observability for Delegated Execution in Agentic AI Systems

    A. Mishra and K. Sharad, “Observability for Delegated Execution in Agentic AI Systems,” arXiv:2606.09692, 2026

    work page Pith review arXiv 2026

  5. [5]

    Artificial Intelligence Risk Management Framework (AI RMF 1.0),

    E. Tabassi, “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” NIST AI 100-1, National Institute of Standards and Technology, 2023

    work page 2023

  6. [6]

    Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,

    C. Autio et al., “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1, National Institute of Standards and Technology, 2024

    2024

  7. [7]

    Model Context Protocol Specification, revision 2025-11-25,

    Model Context Protocol, “Model Context Protocol Specification, revision 2025-11-25,” 2025

    work page 2025

  8. [8]

    Agent2Agent Protocol Specification and Documentation,

    A2A Project, “Agent2Agent Protocol Specification and Documentation,” Linux Foundation project, accessed 2026

    work page 2026

Show all 66 references
  1. [9]

    OpenTelemetry Concepts and Signals,

    OpenTelemetry, “OpenTelemetry Concepts and Signals,” documentation, accessed 2026

    2026

  2. [10]

    Trace Context,

    W3C, “Trace Context,” W3C Recommendation, 23 November 2021

    2021

  3. [11]

    Kubernetes Components and Cluster Architecture,

    Kubernetes Authors, “Kubernetes Components and Cluster Architecture,” Kubernetes Documentation, accessed 2026

    2026

  4. [12]

    Key words for use in RFCs to Indicate Requirement Levels,

    S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, 1997

    1997

  5. [13]

    Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words,

    B. Leiba, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words,” RFC 8174, 2017

    2017

  6. [14]

    Time, Clocks, and the Ordering of Events in a Distributed System,

    L. Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System,” Communications of the ACM, vol. 21, no. 7, pp. 558–565, 1978

    1978

  7. [15]

    The Part-Time Parliament,

    L. Lamport, “The Part-Time Parliament,” ACM Transactions on Computer Systems, vol. 16, no. 2, pp. 133–169, 1998

    1998

  8. [16]

    Dapper, a Large-Scale Distributed Systems Tracing Infrastructure,

    B. H. Sigelman et al., “Dapper, a Large-Scale Distributed Systems Tracing Infrastructure,” Google Research, 2010

    2010

  9. [17]

    The Tail at Scale,

    J. Dean and L. A. Barroso, “The Tail at Scale,” Communications of the ACM, vol. 56, no. 2, pp. 74–80, 2013

    2013

  10. [18]

    Burns and A

    A. Burns and A. Wellings, Real-Time Systems and Programming Languages, 4th ed., Addison-Wesley, 2009

    2009

  11. [19]

    J. L. Hennessy and D. A. Patterson, Computer Architecture: A Quantitative Approach, 6th ed., Morgan Kaufmann, 2017

    2017

  12. [20]

    Silberschatz, P

    A. Silberschatz, P. B. Galvin, and G. Gagne, Operating System Concepts, 10th ed., Wiley, 2018

    2018

  13. [21]

    A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed., Pearson, 2014

    2014

  14. [22]

    OPA Documentation and Policy Language,

    Open Policy Agent, “OPA Documentation and Policy Language,” Cloud Native Computing Foundation project, accessed 2026

    2026

  15. [23]

    SPIFFE Standards and Workload Identity Specification,

    SPIFFE, “SPIFFE Standards and Workload Identity Specification,” Cloud Native Computing Foundation project, accessed 2026

    2026

  16. [24]

    Seccomp BPF (Secure Computing with Filters),

    Linux Kernel Documentation, “Seccomp BPF (Secure Computing with Filters),” accessed 2026

    2026

  17. [25]

    Control Group v2,

    T. Heo, “Control Group v2,” Linux Kernel Documentation, accessed 2026

    2026

  18. [26]

    PROV-O: The PROV Ontology,

    W3C, “PROV-O: The PROV Ontology,” W3C Recommendation, 2013

    2013

  19. [27]

    in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes,

    L. Torres-Arias et al., “in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes,” USENIX Security Symposium, 2019

    2019

  20. [28]

    Supply-chain Levels for Software Artifacts (SLSA),

    OpenSSF, “Supply-chain Levels for Software Artifacts (SLSA),” specification, accessed 2026

    2026

  21. [29]

    Constitutional AI: Harmlessness from AI Feedback,

    Y. Bai et al., “Constitutional AI: Harmlessness from AI Feedback,” arXiv:2212.08073, 2022

    2022 arXiv

  22. [30]

    AI Safety via Debate,

    G. Irving, P. Christiano, and D. Amodei, “AI Safety via Debate,” arXiv:1805.00899, 2018

    2018 arXiv

  23. [31]

    A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions,

    L. Huang et al., “A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions,” arXiv:2311.05232, 2023

    2023 arXiv

  24. [32]

    ReAct: Synergizing Reasoning and Acting in Language Models,

    S. Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” arXiv:2210.03629, 2022

    2022 arXiv

  25. [33]

    Toolformer: Language Models Can Teach Themselves to Use Tools,

    T. Schick et al., “Toolformer: Language Models Can Teach Themselves to Use Tools,” Advances in Neural Information Processing Systems, 2023

    2023

  26. [34]

    AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation,

    Q. Wu et al., “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation,” arXiv:2308.08155, 2023

    2023 arXiv

  27. [35]

    LangGraph Documentation,

    LangChain, “LangGraph Documentation,” accessed 2026

    2026

  28. [36]

    CrewAI Documentation,

    CrewAI, “CrewAI Documentation,” accessed 2026

    2026

  29. [37]

    Ray: A Distributed Framework for Emerging AI Applications,

    P. Moritz et al., “Ray: A Distributed Framework for Emerging AI Applications,” USENIX OSDI, 2018

    2018

  30. [38]

    Naiad: A Timely Dataflow System,

    D. G. Murray et al., “Naiad: A Timely Dataflow System,” ACM SOSP, 2013

    2013

  31. [39]

    Large-Scale Cluster Management at Google with Borg,

    A. Verma et al., “Large-Scale Cluster Management at Google with Borg,” EuroSys, 2015

    2015

  32. [40]

    Omega: Flexible, Scalable Schedulers for Large Compute Clusters,

    M. Schwarzkopf et al., “Omega: Flexible, Scalable Schedulers for Large Compute Clusters,” EuroSys, 2013

    2013

  33. [41]

    Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center,

    B. Hindman et al., “Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center,” USENIX NSDI, 2011

    2011

  34. [42]

    K. J. Åström and R. M. Murray, Feedback Systems: An Introduction for Scientists and Engineers, Princeton University Press, 2008

    2008

  35. [43]

    Kleinrock, Queueing Systems, Volume I: Theory, Wiley, 1975

    L. Kleinrock, Queueing Systems, Volume I: Theory, Wiley, 1975

    1975

  36. [44]

    Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services,

    S. Gilbert and N. Lynch, “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services,” SIGACT News, 2002

    2002

  37. [45]

    Impossibility of Distributed Consensus with One Faulty Process,

    M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of Distributed Consensus with One Faulty Process,” Journal of the ACM, 1985

    1985

  38. [46]

    Green AI,

    R. Schwartz et al., “Green AI,” Communications of the ACM, vol. 63, no. 12, pp. 54–63, 2020

    2020

  39. [47]

    Guidelines for Human-AI Interaction,

    S. Amershi et al., “Guidelines for Human-AI Interaction,” ACM CHI, 2019

    2019

  40. [48]

    V. Vovk, A. Gammerman, and G. Shafer, Algorithmic Learning in a Random World, Springer, 2005

    2005

  41. [49]

    Zero Trust Architecture,

    NIST, “Zero Trust Architecture,” NIST SP 800-207, 2020

    2020

  42. [50]

    CloudEvents Specification,

    Cloud Native Computing Foundation, “CloudEvents Specification,” accessed 2026

    2026

  43. [51]

    The OAuth 2.0 Authorization Framework,

    D. Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749, 2012

    2012

  44. [52]

    OpenID Connect Core 1.0,

    OpenID Foundation, “OpenID Connect Core 1.0,” 2014. AOS-0001 | AOS Specification Series | Lead Editor: Ankur Sharma | Page 71

    2014

  45. [53]

    Web Authentication: An API for accessing Public Key Credentials (WebAuthn),

    W3C, “Web Authentication: An API for accessing Public Key Credentials (WebAuthn),” W3C Recommendation, accessed 2026

    2026

  46. [54]

    ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system

    2023

  47. [55]

    ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management

    2023

  48. [56]

    Beyer et al., Site Reliability Engineering: How Google Runs Production Systems, O’Reilly Media, 2016

    B. Beyer et al., Site Reliability Engineering: How Google Runs Production Systems, O’Reilly Media, 2016

    2016

  49. [57]

    Lamport, Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers, Addison-Wesley, 2002

    L. Lamport, Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers, Addison-Wesley, 2002

    2002

  50. [58]

    Security and Privacy Controls for Information Systems and Organizations,

    NIST, “Security and Privacy Controls for Information Systems and Organizations,” NIST SP 800-53 Rev. 5, 2020

    2020

  51. [59]

    Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS),

    MITRE, “Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS),” knowledge base, accessed 2026

    2026

  52. [60]

    A. D. Kshemkalyani and M. Singhal, Distributed Computing: Principles, Algorithms, and Systems, Cambridge University Press, 2008

    2008

  53. [61]

    Programming Semantics for Multiprogrammed Computations,

    J. B. Dennis and E. C. Van Horn, "Programming Semantics for Multiprogrammed Computations," Communications of the ACM, vol. 9, no. 3, pp. 143–155, 1966

    1966

  54. [62]

    Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control,

    M. S. Miller, "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control," Ph.D. dissertation, Johns Hopkins University, 2006

    2006

  55. [63]

    The Confused Deputy (or Why Capabilities Might Have Been Invented),

    N. Hardy, "The Confused Deputy (or Why Capabilities Might Have Been Invented)," ACM SIGOPS Operating Systems Review, vol. 22, no. 4, pp. 36– 38, 1988

    1988

  56. [64]

    Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud,

    A. Birgisson et al., "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud," Network and Distributed System Security Symposium (NDSS), 2014

    2014

  57. [65]

    FIPA Agent Management Specification,

    Foundation for Intelligent Physical Agents, "FIPA Agent Management Specification," SC00023K, 2004

    2004

  58. [66]

    UDDI Version 3.0.2,

    OASIS, "UDDI Version 3.0.2," OASIS Standard, 2004. AOS-0001 | AOS Specification Series | Lead Editor: Ankur Sharma | Page 72

    2004

Pith tools

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