← Work from OVRLab

PqP
Network.

A communication network for AI agents.

How do agents work together across devices?

PqP—Peer-Queue-Peer—is evolving from a peer network into communication infrastructure for AI agents. The research asks how independently operated agents can exchange tasks and results across different runtimes, interrupted connections, and periods offline.

Active research prototype. The networking foundation exists; agent interoperability is planned work, with security and reliable delivery as prerequisites.

Research direction: agent task exchange over queues and direct connections.

From peers to agents

PqP’s foundation is its Web 5.0 research into a client-powered cloud network. Its TypeScript core supports peer discovery through DNS, encrypted messages through provider-hosted queues, and direct WebRTC connections. That work provides the foundation for the agent-network research.

The next layer concerns agent tasks: how they are addressed, authorized, acknowledged, and resumed. A2A is the first proposed interoperability target. The protocol adapter is planned; the current prototype does not yet establish A2A compatibility.

The architecture continues to use shared DNS, relay, queue, and identity services. Their role and failure modes remain part of the research.

Open research questions

  • Tasks that survive interruptions

    Can an agent hand off a task and receive a result when either device goes offline? We need to understand recovery, duplicate delivery, and task completion across those gaps.

  • Identity across owners

    How should an agent identify another agent and decide what it may ask of it? Authenticating a message and authorizing a task are separate problems.

  • From queues to direct connections

    Can communication move between delayed queue delivery and a direct connection without losing task state or changing the meaning of an acknowledgement?

  • When the network earns its complexity

    How do completion rates, latency, bandwidth, and infrastructure dependence compare with ordinary HTTP, webhooks, and durable brokers? These comparisons must guide the architecture.

The workloads we want to test

A coding agent handing a task to another machine. A long-running job returning its result after the requesting device reconnects. Agents coordinating work across separately operated environments.

These are proposed workloads for evaluation. The aim is to learn where queue-assisted peer communication helps, what it costs, and where a simpler transport works better.

Discuss the research

Publications

  1. Project update

    Toward a network for AI agents

    PqP’s next research direction is task exchange between independently operated agents, using queued contact and direct connections across interruptions.

    PqP Network
  2. Project update

    Binding PqP messages to their sender

    The identity implementation now connects authenticated principals, queue ownership, and message-signing identity across the control plane and clients.

    PqP Network
  3. Project update

    Signed ancestry for shared vault changes

    PqP’s public-vault synchronization now records merge ancestry in signed metadata and prepares that metadata before replacing local content.

    PqP Network
  4. Project update

    Direct WebRTC connections in the desktop client

    PqP’s Electron client can now establish a WebRTC path through the shared package, extending the transport work already integrated in the browser extension.

    PqP Network
  5. Project update

    PqP gets a shared networking core

    The networking implementation is now a TypeScript package, with common cryptography and messaging behind Chrome and Electron adapters.

    PqP Network
  6. Project update

    A queue for each PqP participant

    The first PqP Worker can find or create a participant’s queue, establishing the provisioning step for queue-assisted peer communication.

    PqP Network