What is PCP?

Abstract

Portal Control Protocol (PCP) is a wire protocol and service-oriented architecture for embedding System Intelligence into an operating system. It defines how a capability daemon holds the authoritative registry of desktop state, how clients connect to invoke semantic operations on that state, and how events flow between the intelligence layer and the applications it controls.

PCP redefines how machine intelligence interacts with a graphical desktop. The intelligence layer does not peer in through accessibility APIs or screen-scraping, nor does it live inside the compositor process. Instead, a dedicated capability daemon owns the registry, event bus, and audit log. The compositor contributes surface state. Clients, including System Intelligence, connect over Unix-domain sockets and speak the PCP wire protocol.

This separation has concrete benefits. The daemon holds exactly one copy of the truth: one registry, one event bus, one audit chain. The compositor loads no PCP code, so a PCP bug never takes down the desktop. The intelligence layer connects as a client, equal in standing to CLI tools and scripts, and invokes capabilities through the same framing protocol everything else uses.

PCP is an open standard. Its message format, data model, and wire protocol are documented and implementable by any compositor or daemon host that wishes to embed System Intelligence. This specification defines the protocol, its design principles, and the architecture that makes it work.

The Service-Oriented Model

Traditional approaches to desktop automation treat the intelligence layer as a separate entity. Accessibility frameworks expose widget trees over IPC. Screen readers query text content through serialized objects. Agent frameworks simulate keyboard and mouse input, then observe pixel changes to infer what happened. Each crossing of a process boundary adds latency, drops context, and forces serialization of data the compositor already holds in memory.

PCP inverts this relationship. Rather than reaching into the OS from outside, System Intelligence connects to a daemon that already holds the desktop model. The daemon runs as a sibling service to the compositor, not inside it. The compositor contributes surface state through domain capabilities. The daemon enriches that state with accessibility data and serves it to any client that connects.

When an application exposes a button, the compositor already knows that button’s label, bounds, semantic role, and activation method. PCP re-exports that data, enriched with accessibility metadata, to the intelligence layer over a Unix-domain socket using a framed wire protocol. The serialization cost is measured in microseconds, well within the latency budget for interactive voice commands and real-time element tracking.

The protocol also defines an in-process embedding mode. Any host that owns its capability servers can register them in an in-process dispatcher and invoke them without IPC, bypassing the wire protocol entirely. This mode exists for deployments where the daemon is embedded inside a larger process rather than running as a standalone service.

Architecture Overview

The PCP architecture consists of four roles arranged around a central daemon:

graph TD
    subgraph "PCP Daemon"
        Registry["Capability Registry"]
        Events["Event Bus"]
        Audit["Audit Log"]
        Runtimes["Runtime Services"]
    end

    subgraph "Compositor"
        Surfaces["Surface State"]
    end

    subgraph "Clients"
        SI["System Intelligence"]
        CLI["CLI Tools"]
        Scripts["Scripts"]
    end

    subgraph "Tier 1 Apps"
        T1A["App A (PcpServer)"]
        T1B["App B (PcpServer)"]
    end

    Surfaces -->|"domain capabilities"| Registry
    Registry -->|"enriched state"| SI
    Registry -->|"enriched state"| CLI
    Events -->|"stream"| SI
    SI -->|"invoke capabilities"| Registry
    CLI -->|"invoke capabilities"| Registry
    T1A -->|"serve PcpServer"| Daemon
    T1B -->|"serve PcpServer"| Daemon

The PCP daemon is the capability authority. It maintains the registry of every capability, surface, and application on the system. It runs the event bus, the audit chain, detection pipeline, and runtime services. All clients connect to it, and all capability invocations flow through it.

The compositor is the surface authority. It tracks every window, surface, input event, and output configuration. It loads no PCP code. Surface state enters PCP through domain capabilities that the compositor exposes.

Clients connect to the daemon over Unix-domain sockets. System Intelligence, CLI tools, and scripts all speak the same framing protocol. SI is a client, not a privileged back door.

Tier 1 applications serve the PcpServer contract on their own sockets. The daemon connects to them as a client, the same way it accepts connections from its own clients.

Design Principles

Principle	Description
Agent-native	Capabilities are semantic operations, not pixel coordinates. The intelligence layer invokes named capabilities (“activate the compose button in Mail”) rather than simulating clicks at screen positions. The protocol is built around what things mean, not where pixels land.
Compositor-authoritative	The compositor sees every surface, application, and input event on the desktop. PCP re-exports that state, enriched with accessibility data, to the intelligence layer. Nothing is guessed or inferred. The system declares what exists.
Progressive fidelity	Integration depth determines capability depth. Tier 1 applications expose full semantic access, letting SI read, write, and interact with structured content. Tier 2 applications expose structural accessibility data. Tier 3 applications fall back to input simulation. Better integration yields richer interaction, but basic control is always available.
One daemon, one truth	A single registry, event bus, and audit chain inside the PCP daemon. All clients are equal before it, System Intelligence included. No private back doors, no parallel registries, no out-of-band capability channels.
Local-only, peer-credentialed	Unix-domain sockets only, with filesystem permission restrictions and peer-credential UID checks. No network surface, no remote access, no multi-user operation. Single-user, single-host.
Open protocol, closed identity	The framing, message taxonomy, and data model are documented here and implementable by any compositor or daemon host. On any given system there is one system identity. The protocol does not dictate which identity that is.
Audit-everything	Every capability invocation is logged with a timestamp, target, parameters, and result. System-privileged operations carry the same audit trail as user-initiated actions. Full auditability is a protocol-level invariant, not an optional extension.

What PCP Is Not

Not a compositor module. The compositor process loads no PCP code. PCP runs as a sibling service to the compositor, connected through domain capabilities and socket IPC. A bug in PCP cannot crash the compositor.

Not networked. PCP operates over Unix-domain sockets with peer-credential checks. It is single-user, single-host, with no network surface. The framing protocol could theoretically run over TCP, but the specification restricts transport to local sockets.

Not MCP. The Model Context Protocol connects language models to external tools through a request-response abstraction. PCP handles streaming events, persistent subscriptions, confirmation gates, an audit hash chain, and a multi-tier capability model. MCP is a tool-calling protocol. PCP is a desktop capability fabric.

Not silent about tiers. The Tier 3 simulator requires external tools and reports degraded health without them. Every adapter’s health state is observable. PCP does not pretend that input simulation is as good as native semantic access.