Agentic Publication Protocol (APP)

• APP is a lightweight repository format for scientific publications that integrates the paper narrative with operational materials like code, data, and environment details.
• It structures publications into three layers—a human-readable layer, an agent-facing layer (AGENTS.md), and a verified release layer to ensure reproducibility.
• The protocol facilitates machine-readability by enabling a paper agent to navigate reproduction instructions, validate results, and support follow-up research.

Searching arXiv for the cited APP paper and closely related protocol papers to ground the article in current literature. First, retrieve the APP paper itself and then a few adjacent protocol papers for context and cross-reference. Agentic Publication Protocol (APP) is a lightweight repository format for scientific publication that packages a paper together with code, data, environment information, reproducibility instructions, and an agent-facing instruction file. APP treats a public version-controlled git repository plus a specific tagged release as the publication object, with AGENTS.md and optional skills defining a paper agent that can explain the work, reproduce key results when possible, and support follow-up research (Lu et al., 15 Jun 2026). In the broader landscape of agent-mediated scholarship, this places APP within a shift from static manuscripts toward publications that are also machine-usable artifacts, while keeping the manuscript authoritative and preserving familiar scholarly workflows (Pugliese et al., 19 May 2025).

1. Definition, rationale, and design stance

APP is organized around four problems in traditional publication: limited, static representation of information; failure to update; lack of reproducibility; and missing know-how (Lu et al., 15 Jun 2026). Its target is not only the paper as a narrative object, but also the operational materials that determine whether later readers can understand, reproduce, and extend the work. The protocol is therefore meant to capture how to run code, how to reproduce key figures and tables, what environment is needed, what data sources are authoritative, what execution order or command prefixes to use, what results are fully reproducible versus blocked or manual-only, and where important limitations or delicate derivations lie (Lu et al., 15 Jun 2026).

A central conceptual claim is that scientific publication should preserve not only knowledge but also know-how. APP describes this as a response to tacit operational knowledge that is usually omitted from static manuscripts: debugging insights, methodological choices, edge cases, dead ends, and follow-up directions (Lu et al., 15 Jun 2026). The protocol is timely because LLM agents can read and summarize papers, navigate repositories, execute code, plan reproduction workflows, answer reader questions, and assist follow-up research; APP adds an agent-facing representation so that a reader can interact with a repository through a paper agent rather than only through a PDF (Lu et al., 15 Jun 2026).

APP is explicitly lightweight and flexible. It is not a universal ontology for research content, and it keeps the manuscript authoritative while adding AGENTS.md and a release manifest (Lu et al., 15 Jun 2026). This distinguishes it from richer interactive-publication proposals that emphasize retrieval-augmented generation, vector databases, knowledge graphs, and continuous query-time synthesis over a publication knowledge base (Pugliese et al., 19 May 2025).

2. Publication object, repository layers, and canonical structure

APP defines a publication as a public git repository together with a specific release (Lu et al., 15 Jun 2026). A complete APP publication has three layers: a human publication layer, an agent-facing layer, and a release and verification layer. The human publication layer includes the manuscript, README, license, code, data, and environment information. The agent-facing layer is centered on AGENTS.md. The release and verification layer binds the repository to a tag, commit, manifest, and human approval (Lu et al., 15 Jun 2026).

The protocol also distinguishes repository status. A repository with AGENTS.md is agent-readable. A repository whose AGENTS.md frontmatter declares APP is an APP-structured candidate. A tagged release with APP_PUBLICATION.json is a verified APP publication (Lu et al., 15 Jun 2026).

Path	Purpose
AGENTS.md	Primary instructions for the paper agent
README.md	Human-facing overview and usage instructions
LICENSE	Reuse terms
paper/	Canonical manuscript and paper figures
code/	Source code and reproduction scripts
data/	Local data or data-access documentation
environment/	Dependency and runtime setup instructions
supplementary/	Author notes, derivations, transcripts, or context
skills/	Optional paper-specific agent skills
CLAUDE.md	Optional pointer for Claude Code compatibility

The required components for every APP publication are AGENTS.md, README.md, LICENSE, and paper/ (Lu et al., 15 Jun 2026). code/, data/, environment/, supplementary/, and skills/ are included when relevant, and CLAUDE.md is optional (Lu et al., 15 Jun 2026). A theory paper with no code or data may omit code/ and data/, whereas a numerical or experimental paper should include code, data description, and environment details needed for reproduction (Lu et al., 15 Jun 2026).

The paper/ directory contains the canonical paper, and exactly one document must be identified as the canonical paper, with its format and path declared in AGENTS.md (Lu et al., 15 Jun 2026). The release layer includes APP_PUBLICATION.json, which records repository URL, tag, commit, tree hash, validation result, and human approval (Lu et al., 15 Jun 2026).

3. AGENTS.md, the paper agent, and agent-facing semantics

AGENTS.md is the central agent-facing file in APP. It is the instruction file that teaches an agent how to use the paper, code, data, and environment as the ground truth (Lu et al., 15 Jun 2026). It is not a replacement for the paper. Instead, it identifies authoritative sources, explains repository structure, describes what the agent can safely do, and grounds answers and reproduction help in repository artifacts (Lu et al., 15 Jun 2026).

The file has two parts: machine-readable frontmatter and a human-readable body. The frontmatter records metadata such as protocol name, protocol version, paper title, authors, canonical paper format, publication version, domain, and optional external references (Lu et al., 15 Jun 2026). The body should include the identity of the paper agent, paper summary, key results, repository structure, concrete things the agent can do, computational requirements, citation information, ground truth hierarchy, setup instructions, reproduction map, limitations, and safe follow-up directions (Lu et al., 15 Jun 2026).

AGENTS.md is distinct from README.md. README.md is the human-facing overview. AGENTS.md is the agent instruction file that teaches an agent how to represent the paper faithfully, where the ground truth lives, and how to answer questions or support reproduction (Lu et al., 15 Jun 2026). APP recommends keeping AGENTS.md concise by pointing to canonical files rather than duplicating all details (Lu et al., 15 Jun 2026).

A paper agent instantiated from an APP repository is expected to represent the paper faithfully, use APP materials as ground truth, explain the work, locate relevant repository components, answer reader questions grounded in source artifacts, help reproduce key results when possible, honestly report blockers and limits, and support safe follow-up research (Lu et al., 15 Jun 2026). In evaluation, the useful paper agent is the one that answers from the APP materials, supports understanding, gives actionable reproduction guidance, and remains grounded and honest about evidence and limits (Lu et al., 15 Jun 2026).

4. Reproducibility workflow and optional skill system

APP separates the protocol itself from optional skills. Authors do not need to use the provided skills to be APP-compliant; they may prepare APP repositories manually, with other tools, or with other agents (Lu et al., 15 Jun 2026). The main metaskill is publish-paper, which guides authors through a staged workflow from working folder to publication-staging/ to tagged release (Lu et al., 15 Jun 2026).

The named workflow stages are reproduce-results, prepare-staging, define-paper-agent, validate-publication, and release-outcome (Lu et al., 15 Jun 2026). reproduce-results checks existing key results before reorganization, tries to make figures, tables, experiments, and analytic results as reproducible as possible, and produces a reproduction report marking results as reproduced, blocked, manual-only, or inconsistent (Lu et al., 15 Jun 2026). prepare-staging builds a publication-staging/ folder following APP layout, copies or summarizes materials into public locations, documents dependencies, and excludes private or irrelevant working files (Lu et al., 15 Jun 2026). define-paper-agent creates paper-agent documentation, especially AGENTS.md (Lu et al., 15 Jun 2026). validate-publication reviews the staged publication for structural completeness, path consistency, privacy issues, factual consistency, environment setup, and reader-agent usability; it is explicitly not peer review and should not judge scientific novelty (Lu et al., 15 Jun 2026). release-outcome creates the tagged release and manifest binding repository URL, commit, tree hash, validation result, and human approval (Lu et al., 15 Jun 2026).

APP’s reproducibility requirements are unusually concrete. If figures or tables are generated computationally, the protocol requires a figure/table reproduction area, usually code/figure-reproduction/, with a README.md mapping each paper figure or table to the corresponding script, inputs, generated output, reproduction status, and any blocker (Lu et al., 15 Jun 2026). For data, data/README.md should describe where external data come from, how to obtain them, and which scripts or figures use them (Lu et al., 15 Jun 2026). For environments, environment/README.md should state the tested platform, setup commands, and the command prefix an agent should use to run code, while installed environments and package caches should not be committed and instead should be recreated from committed dependency files such as requirements.txt, environment.yml, lockfiles, or Dockerfile (Lu et al., 15 Jun 2026).

Auxiliary skills extend this workflow. load-paper loads a published APP repository, a local publication-staging/ candidate, a non-APP repository, or an arXiv paper so an agent can inspect the paper and classify its APP status (Lu et al., 15 Jun 2026). extract-chat-context summarizes prior agent sessions into publication-safe know-how material such as know-how.md, subject to author review and privacy screening (Lu et al., 15 Jun 2026). create-paper-page creates a lightweight GitHub Pages project page under supplementary/, but it is explicitly not part of APP compliance (Lu et al., 15 Jun 2026).

5. Release, validation, and empirical evaluation

The release layer turns a repository into a citable scholarly object. APP binds publication identity to a tag, commit, and manifest, and the manifest records repository URL, tag, commit, tree hash, validation result, and human approval (Lu et al., 15 Jun 2026). This is the protocol’s main mechanism for version control and timestamping. It is meant to reduce ambiguity in priority and provenance and to distinguish a mutable repository from the exact snapshot being claimed as the publication (Lu et al., 15 Jun 2026).

The protocol includes a substantial development and evaluation infrastructure. The development repository is itself APP-structured and includes manuscript material, a public protocol repository as a submodule, scripts, example papers, benchmark summaries, skills, supplementary materials, and a local working/ area for generated transcripts and reports (Lu et al., 15 Jun 2026). The named development and evaluation skills are simulate-publication, test-paper-agent, compare-app, and find-reproducible-papers (Lu et al., 15 Jun 2026).

simulate-publication creates a simulated author and publishing agent in fresh sessions and runs the publication workflow in a sandbox (Lu et al., 15 Jun 2026). test-paper-agent evaluates whether the resulting paper agent is useful to a realistic reader by simulating a graduate-student reader and a paper agent inside the staged publication folder (Lu et al., 15 Jun 2026). compare-app compares an APP paper agent with a general repository-aware agent using the same neutral question script, with transcripts anonymized and scored by a neutral evaluator on accuracy, informativeness, grounding in concrete source artifacts, and honesty about evidence and reproduction limits (Lu et al., 15 Jun 2026).

Reported evaluation used 11 arXiv papers in quantum physics. APP won on all 11 in the compare-app benchmark, with average scores of 9.25 for the APP paper agent and 8.50 for the general agent, and the biggest gains were in grounding and honesty (Lu et al., 15 Jun 2026). The paper also states the limitations of this evidence: the margin is modest, the evaluator may be biased, and the study is a small-scale starting point rather than definitive proof (Lu et al., 15 Jun 2026).

6. Relation to adjacent agentic publication and protocol research

APP sits alongside, rather than replacing, other models of agent-mediated scholarly communication. “Agentic Publications” proposes an LLM-driven framework that transforms papers into interactive knowledge systems with structured and unstructured content, retrieval-augmented generation, multi-agent verification, APIs, multilingual interaction, vector databases, and knowledge graphs (Pugliese et al., 19 May 2025). APP instead makes the repository and tagged release the publication object, keeps the manuscript authoritative, and uses AGENTS.md plus optional skills as the main agent-facing layer (Lu et al., 15 Jun 2026). This suggests a division between a repository-native packaging protocol and a more service-oriented interactive publication layer.

A plausible implication is that APP’s release object can be enriched by provenance systems such as PROV-AGENT, which extends W3C PROV with classes including AIAgent, AgentTool, AIModelInvocation, Prompt, and ResponseData, and supports queries over prompts, responses, decisions, and downstream impacts in agentic workflows (Souza et al., 4 Aug 2025). The APP paper already emphasizes signed releases, repository structure, and grounded answers; PROV-AGENT suggests how agent-centric metadata could become part of end-to-end publication provenance rather than isolated logs.

Workflow-scoped authorization is another adjacent concern. Agentic JWT introduces workflow-aware intent tokens carrying workflow_id, workflow_step, delegation chain, and proof-of-possession binding, while SUDP formalizes operation-bound, single-use grants so an untrusted autonomous requester can cause a user-authorized secret-backed operation without receiving reusable authority (Goswami, 16 Sep 2025, Yu et al., 27 Apr 2026). This suggests that if APP is extended from repository release into automated posting, signing, or distribution actions, those actions should be bound to specific workflow steps or one-shot authorizations rather than long-lived bearer credentials.

For collaborative preparation and review, AWCP contributes a temporary workspace-delegation layer in which a Delegator exposes a selected directory tree to a remote Executor under a lease, with explicit control-plane states and pluggable transports such as SSHFS, Archive, Storage, and Git (Nie et al., 24 Feb 2026). A plausible implication is that APP’s publication-staging/ and reproducibility workflow could use such workspace delegation for remote validation, compliance checking, or multimodal curation before the final tagged release.

Discovery and interoperability also have adjacent treatments. ANP defines a three-layer architecture with an identity and encrypted communication layer, a meta-protocol negotiation layer, and an application layer centered on Agent Description Protocol and Agent Discovery Protocol, including JSON-LD descriptions and .well-known/agent-descriptions discovery (Chang et al., 18 Jul 2025). This suggests a possible route for publishing and discovering agent-readable APP repositories or paper-agent endpoints, although ANP does not define APP itself.

Trust and security analyses reinforce the same conclusion: no single mechanism suffices. The comparative trust-model study argues for trustless-by-default architectures anchored in Proof and Stake for high-impact actions, augmented by Brief for identity and discovery, Reputation overlays for social signals, and Constraint for sandboxing and capability bounding (Hu et al., 5 Nov 2025). Security analyses of A2A, ACP, and CORAL further emphasize message integrity, replay protection, mandatory verification, and hardened streaming or gateway implementations when agent protocols move beyond static packaging into network services (Habler et al., 23 Apr 2025, Louck et al., 5 Nov 2025).

7. Limitations, scope boundaries, and future directions

APP is presented as a starting point rather than a mature final standard (Lu et al., 15 Jun 2026). Its evaluation is small-scale and agent-based, and the paper explicitly notes that performance gains over the baseline are modest (Lu et al., 15 Jun 2026). Different fields may require different forms of know-how representation, and more precise quantitative characterizations of broader effects are left for future work (Lu et al., 15 Jun 2026).

The protocol is intentionally pragmatic rather than formally rich. It provides repository structure, named files, workflow stages, status distinctions, and manifest fields, but it does not present substantive mathematical formulas or a universal machine-readable representation of scientific content (Lu et al., 15 Jun 2026). This keeps adoption friction low, but it also leaves open questions about richer provenance, claim-level semantics, policy enforcement, and cross-platform interoperability.

A broader limitation is that APP addresses packaging, grounding, reproducibility materials, and agent-facing navigation more directly than it addresses public-service interaction layers such as continuous knowledge updates, graph-query interfaces, or query-time synthesis. Those functions are emphasized in other agentic-publication proposals built around retrieval-augmented generation, knowledge graphs, and verification agents (Pugliese et al., 19 May 2025). This suggests a continuing architectural split between repository-native publication objects and interactive publication services.

The paper also frames governance as open and evolving. APP is meant to be improved by the research community, along with the skills and domain-specific variants around it (Lu et al., 15 Jun 2026). The long-term direction, therefore, is not merely a better supplementary-material convention, but a repository-native, agent-friendly publication protocol in which the publication object is versioned, auditable, reproducible when possible, and able to support an agent that is grounded in the paper, code, data, and environment rather than in generic summary behavior alone (Lu et al., 15 Jun 2026).