The Assembly Line Protocol (ALP) is an open protocol that describes how AI tasks flow through a sequence of automated Stations, each powered by an AI Agent. It defines the contracts between four roles so that anyone can build a compatible Server or Runner:

• Server — manages Assembly Lines, the task queue, and the Runner registry
• Runner — polls the Server for jobs, delegates execution to a Station Operator, and reports results back
• Operator — spawned by the Runner to manage a single Station's execution (sets up the workspace, runs the Agent, streams output)
• Agent — the AI that does the actual work at each Station (e.g. Claude Code)

The key inspiration is GitHub self-hosted runners: just as any machine can register as a runner and execute GitHub Actions workflows, any ALP Runner can register with a compliant ALP Server and execute Stations. You can run your own Clients against the agentics.dk Server, or build your own ALP Server that pks-cli can connect to.

Today, agentics.dk runs Assembly Lines internally. ALP exists so that:

1. Anyone can build a Runner — connect your own runner/operator/agent stack to the agentics.dk server or any other ALP-compliant server
2. Anyone can build a Server — implement the ALP server API and route tasks to any Runner that speaks the protocol
3. The ecosystem grows — just as MCP unlocked a marketplace of AI tools, ALP should unlock a marketplace of AI production pipelines

The reference implementations are:

• Server: agentics.dk — closed source
• Runner: pks-cli — open source, C#
• Operator: vibecast — open source, Go

This specification is in active draft. Open questions are tracked in todo.md. Sections with remaining open questions are marked > ❓.