---
title: Agentic Publication Protocol (APP)
url: https://www.emergentmind.com/topics/agentic-publication-protocol-app
type: topic
---

# Agentic Publication Protocol (APP)

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 [2606.27386]. 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 [2505.13246].

## 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 [2606.27386]. 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 [2606.27386].

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 [2606.27386]. 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 [2606.27386].

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 [2606.27386]. 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 [2505.13246].

## 2. Publication object, repository layers, and canonical structure

APP defines a publication as a public git repository together with a specific release [2606.27386]. 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 [2606.27386].

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 [2606.27386].

| 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/` [2606.27386]. `code/`, `data/`, `environment/`, `supplementary/`, and `skills/` are included when relevant, and `CLAUDE.md` is optional [2606.27386]. 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 [2606.27386].

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` [2606.27386]. The release layer includes `APP_PUBLICATION.json`, which records repository URL, tag, commit, tree hash, validation result, and human approval [2606.27386].

## 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 [2606.27386]. 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 [2606.27386].

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 [2606.27386]. 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 [2606.27386].

`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 [2606.27386]. APP recommends keeping `AGENTS.md` concise by pointing to canonical files rather than duplicating all details [2606.27386].

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 [2606.27386]. 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 [2606.27386].

## 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 [2606.27386]. The main metaskill is `publish-paper`, which guides authors through a staged workflow from working folder to `publication-staging/` to tagged release [2606.27386].

The named workflow stages are `reproduce-results`, `prepare-staging`, `define-paper-agent`, `validate-publication`, and `release-outcome` [2606.27386]. `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 [2606.27386]. `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 [2606.27386]. `define-paper-agent` creates paper-agent documentation, especially `AGENTS.md` [2606.27386]. `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 [2606.27386]. `release-outcome` creates the tagged release and manifest binding repository URL, commit, tree hash, validation result, and human approval [2606.27386].

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 [2606.27386]. For data, `data/README.md` should describe where external data come from, how to obtain them, and which scripts or figures use them [2606.27386]. 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` [2606.27386].

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 [2606.27386]. `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 [2606.27386]. `create-paper-page` creates a lightweight GitHub Pages project page under `supplementary/`, but it is explicitly not part of APP compliance [2606.27386].

## 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 [2606.27386]. 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 [2606.27386].

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 [2606.27386]. The named development and evaluation skills are `simulate-publication`, `test-paper-agent`, `compare-app`, and `find-reproducible-papers` [2606.27386].

`simulate-publication` creates a simulated author and publishing agent in fresh sessions and runs the publication workflow in a sandbox [2606.27386]. `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 [2606.27386]. `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 [2606.27386].

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 [2606.27386]. 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 [2606.27386].

## 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 [2505.13246]. 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 [2606.27386]. 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 [2508.02866]. 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 [2509.13597] [2604.24920]. 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 [2602.20493]. 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 [2508.00007]. 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 [2511.03434]. 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 [2504.16902] [2511.03841].

## 7. Limitations, scope boundaries, and future directions

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

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 [2606.27386]. 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 [2505.13246]. 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 [2606.27386]. 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 [2606.27386].

Source: https://www.emergentmind.com/topics/agentic-publication-protocol-app