Architecture

Stable contracts around stateful execution

An overview of Protocore’s protocol-first agent runtime architecture.

Design premise

An agent runtime coordinates decisions across time: it receives model deltas, invokes tools, persists state, emits events, validates artifacts, and decides whether work should continue. Protocore keeps that coordination in a pure core and pushes deployment-specific behavior behind protocols.

This is a description of the current software architecture, not a performance claim. Quantitative results live in dated publications with their methods.

Runtime dependency flow Product interfaces communicate with services over HTTP and streaming events. Services implement adapters for the pure Protocore runtime. The runtime reaches models, tools, state stores, and execution backends only through protocol ports. Dependencies point downward; the core does not import the product or service layers above it. Product interfaces Chat Dashboard Automation clients HTTP · streaming events Services and adapters Enterprise API Autonomous tasks Sandbox control adapters implement contracts Pure runtime core Protocore runtime Protocols Hooks Runtime policy ports Protocol-backed capabilities Models Tools State stores Execution backends
Runtime dependency flow — dependencies point downward through protocol ports; the pure core never imports the layers above it.

Pure core, explicit adapters

The core defines execution semantics and contracts without importing service, frontend, or infrastructure packages. Model providers, persistence, distributed coordination, sandbox execution, and product APIs are adapter concerns. An import boundary test protects this dependency direction.

This separation has a practical research benefit: a runtime mechanism can be tested without silently binding the result to one provider or deployment shape.

A run is a state machine

The query runtime advances through observable decisions rather than wrapping one opaque model call:

request
  → load durable session state
  → construct the current tool and memory view
  → stream model output
  → validate and execute requested tools
  → persist events, messages, and artifacts
  → continue, finalize, or stop under explicit policy

Hooks expose selected lifecycle points. Protocols describe capabilities; hooks observe or influence a particular execution. Keeping the two roles distinct avoids coupling storage, model, and product behavior to the orchestration loop.

Tools are a layered surface

A tool must exist in more than one place before an agent can use it reliably:

  1. Definition — schema, description, and validation contract.
  2. Availability — the tools permitted for the current user, project, and run.
  3. Execution — the local, remote, or sandboxed implementation that performs the operation and returns a structured result.

Dynamic tool federation extends this surface at runtime while preserving the same validation and authorization boundaries.

State, memory, and artifacts

Sessions hold durable conversation and execution state. Workspace artifacts are addressable outputs rather than incidental text embedded in a transcript. Memory can construct a bounded view for the next model turn while the durable record remains available for inspection and recovery.

These layers have different correctness questions: whether a fact was stored, whether it was selected into context, whether an artifact is valid, and whether a resumed run preserves intent. Publications report those outcomes separately.

Streaming is a runtime contract

The runtime emits deltas and execution events as they occur. Service adapters forward them to subscribers instead of buffering a completed answer. This keeps interactive products responsive and makes long-running execution observable without changing core orchestration.

Repository boundaries

The installation is split by responsibility:

  • protocore owns the pure runtime and contracts.
  • protocore-enterprise implements service and infrastructure adapters.
  • protocore-autonomous owns background task execution.
  • protocore-sandbox controls isolated execution.
  • protocore-chat and protocore-dashboard are product interfaces over APIs and streaming events.
  • the tools, tool SDK, and tool federation packages own the extensibility surface.

The source code is proprietary. Research artifacts published on this site are released only under the terms stated with each artifact.

Reuse

All rights reserved