ALP v80 Proposes a Protocol for AI Coding Agents

ALP v80.0.0 proposes putting an AI coding agent’s work plan into a machine-readable repository format. Tasks, dependencies, verification commands and project state live in .alp files, which an execution engine uses to organize work and decide whether a task can be marked complete.

The Autonomous Lifecycle Protocol project page presents a broad toolchain: a CLI, Model Context Protocol (MCP) server, VS Code extension, desktop IDE and five language SDKs. It describes ALP as an open standard, but that is the project’s own designation. The supplied evidence offers no independent adoption data.

The primary document is the project’s undated website, so a formal v80 release date cannot be established from it. Its most useful contribution is concrete enough to examine anyway: a proposed contract between repository state, agent execution and executable checks.

What the .alp Specification Encodes

ALP’s format describes software work through structured directives. The project’s example includes @project, @feature, @task and @agent entries, with identifiers connecting the pieces. A file-level version declaration identifies the protocol version.

A shortened task fragment from the published example shows the central mechanism:

@task
  id: task-login-ui
  status: [ ]
  depends_on:
    - task-setup-db
  verify:
    - npm run test:login

This fragment gives the login task an identifier, an initial status, a dependency and a verification command. It is an excerpt, not a complete runnable workspace: the database task and the npm script need corresponding definitions.

The consequential detail is the relationship between depends_on and verify. One expresses an ordering constraint; the other supplies an executable completion check. A prose instruction to build a login page becomes a task that can be placed in a graph and checked through a process exit code.

That is a useful distinction from an ordinary planning document. Markdown can describe the same requirements, but structured fields give a parser explicit relationships without requiring an AI model to infer them from prose.

ALP says it validates against 49 registered JSON schemas. Schema validation can check that data follows an expected structure. It cannot, by itself, determine whether the dependency list captures the real architecture or whether a test adequately checks authentication. Those remain engineering decisions.

I’d judge this format first on how clearly developers can inspect and maintain those relationships. A machine-readable plan is valuable only while it remains an accurate description of the repository.

How the DAG and Quality Gates Control Progress

The documented execution cycle runs from .alp files through parsing, dependency-graph construction, task execution, verification and persistent project state.

ALP describes the graph as a directed acyclic graph, or DAG. Directed edges express prerequisites, and the absence of cycles permits a dependency-respecting execution order. In the example, database setup precedes work on the login interface.

The project says its parser uses Kahn’s topological-sorting algorithm. In practical terms, a topological sort can identify tasks whose prerequisites have been satisfied and order dependent work after them. A circular dependency has no valid topological ordering, making cycle handling an important behavior to inspect.

The documented verification rule is explicit: a successful verification process exits with code 0; a nonzero result marks the task blocked and halts the engine. The proposed state transition is therefore driven by a command result, not merely an agent’s assertion that it finished.

This is the strongest part of the proposal in my view. It gives the workflow an observable completion condition. Its effectiveness still depends on what the commands measure. A passing UI test cannot establish that an authentication flow is secure, and a lint check cannot establish that a feature meets its requirements. Teams need verification scripts that cover the properties they actually care about.

ALP also says it assembles task-specific context bundles and preserves state across sessions. That could reduce repeated context gathering if dependencies, decisions and contracts remain current. The repository specification becomes another maintained artifact, with its own risk of drifting from the code.

The page claims sub-2-millisecond parsing or context assembly in several places, including a diagram labeled 1.8 milliseconds. It supplies no workload size, hardware or reproducible benchmark procedure alongside those figures. All capabilities and measurements discussed here come from project documentation; no installation, code review or benchmark reproduction was performed. These timing claims should not be read as end-to-end coding latency, which also includes model calls, edits and verification.

What the Toolchain Exposes

The ecosystem list connects the format to several interfaces:

The MCP server matters because it offers an integration path into clients developers may already use. The site names Claude Desktop and Cursor. Exposing a graph through a tool gives an agent a structured way to request project information; it does not automatically mean every client enforces ALP’s execution rules.

For related coverage of the client layer, Zeniteq has also covered Cindy’s open-source Claude Code and Codex client. ALP’s proposed boundary is repository-level coordination and state.

The SDK distinction deserves attention. The page’s specific one-to-one parity claim concerns TypeScript and Python. Its descriptions of Go, Rust and Java promise a narrower set of core APIs. Developers should not interpret five listed languages as proof of identical functionality across all five.

Setup begins with installing the scoped npm CLI package and running alp init, which the site says creates a .alp/ directory containing a starter project.alp. The documented workflow then uses alp validate, alp run and task-specific verification. The page does not establish exact package-version compatibility, so matching the CLI, schema and file-format versions is a sensible adoption check.

What the Version Labels Actually Tell Developers

The page prominently labels the project and toolchain v80.0.0. Its feature descriptions also attach v80.0.0 to the swarm marketplace and event mesh. Yet the ecosystem list labels the marketplace skill registry v38.0.0.

That discrepancy is visible in the same primary document. It could reflect separately versioned components or stale documentation; the page does not reconcile the labels. It is insufficient evidence to declare the software broken or assign it an unofficial beta status.

It does create a practical problem. A developer needs to know which package version implements which schema and whether a workspace written for one version remains readable by another.

I’d treat v80 as a compatibility identifier to investigate, not a maturity score. A large version number tells readers little about deployment history or interoperability on its own.

The same caution applies to the site’s claims of 49 schemas and more than 1,013 passing automated tests. Those counts describe reported implementation activity. Without examining the tests, developers cannot tell how much coverage addresses malformed specifications, execution failures, state recovery or cross-language behavior.

What to Inspect Before Adopting ALP

A small trial repository would be more informative than a broad agent migration. Useful checks follow directly from the documented design:

• Dependency handling: Introduce an unresolved task identifier and a cycle, then inspect the diagnostics.
• Verification behavior: Use a deliberately failing command and check task status, engine stoppage and recovery.
• Persistent state: Restart the workflow and inspect which decisions, results and dependencies survive.
• SDK compatibility: Compare the same workspace across the languages needed by your team.
• Execution permissions: Review verification scripts before allowing an agent-driven process to run them.

These are suggested evaluation steps, not reported test results. The final item is especially important: verification commands execute code, so the trust boundary includes whoever can change the specification and its scripts.

ALP’s useful proposal is a repository-level execution contract: declared dependencies govern ordering, commands govern completion, and stored state supports continuity. Whether that contract is dependable requires evidence about failure handling and version compatibility, beyond the project page’s feature list.