Concepts

PAREL's architecture is built around a few key ideas: serverless agent state, a small kernel that only dispatches, a first-class model provider layer, runtime plugins, and durable sessions that recover after restarts.

# Serverless Agent State

An agent is a cloud object, not a process you have to keep alive. It can run as a short job, as a resumable session, or as a durable agent whose transcript, plugin state, channel routes, costs, and execution timeline stay addressable while its compute sleeps.

Some agents finish after a single run; some agents need state to persist across messages, tool calls, approvals, webhooks, scheduled work, disconnects, restarts, and future branches. The runtime wakes when there is work and checkpoints between steps.

# Agent-friendly Development

agent.yaml is designed to be edited by both people and coding agents. It is textual, diffable, and schema-validatable, and it explicitly states model providers, runtime plugins, secret references, and limits. Validation errors should be actionable enough that an agent can fix the spec and retry.

# Kernel

The kernel is the scheduler at the center of PAREL. It only dispatches; it does not implement model APIs, tools, or memory. Model providers are selected by top-level config; runtime capabilities are loaded as plugins.

The kernel runs a turn loop: receive a user message, call the model, execute tools, and repeat until the model signals completion or a cost / step limit is hit.

# Plugins

Model providers and runtime plugins are two separate extension points:

Runtime plugins declare lifecycle hooks — for example before/after model calls, tool execution, and context building — and the kernel dispatches to them in order.

# Policy

PAREL has no separate "policy engine." Policy is expressed through guard plugins and lifecycle hooks: a hook can continue, skip, block, suspend, or stop a model call or tool call. The built-in budget-cap (cost / turn limits) and security-basic (command blocklist + secret redaction) are guard plugins, and custom policy uses the same hook mechanism. When a sandbox is declared but no security plugin is, the runtime auto-injects security-basic as a safety net.

# Sessions

A session is one conversation with an agent. It contains:

Sessions run in platform-owned isolated state. Each session has durable storage for its transcript and runtime state, and recovers automatically between checkpointed steps.

# Channels (external triggers, beta)

Beyond the API and WebSocket, a session can also be triggered by an external channel. The platform offers two entry shapes: webhook (the provider pushes events over HTTP) and managed_ws (PAREL maintains an outbound long-lived connection). The platform owns connection lifecycle, persistence, idempotency, routing, and delivery; the channel-specific protocol (Slack, Telegram, etc.) is implemented by a connector plugin. A binding connects an agent to a connection and uses a routing policy (main / per_subject / per_actor / isolated) to decide which session an event lands in.

# Turns and Steps

A turn begins when the user sends a message and ends when the agent finishes responding. Each turn contains several steps:

Turn #1
  Step 1: model call → "I'll search for that" + tool_call(bash)
  Step 2: tool execution → bash result
  Step 3: model call → "Here's what I found: ..."
  [turn complete]

Steps are checkpointed automatically between executions. If the runtime restarts mid-step, the workflow resumes from the last checkpoint.

# Configuration

Agents are declared through agent.yaml. Model providers and runtime plugins are configured separately:

version: "1"
agent:
  name: research-bot
model:
  provider: anthropic
  model: claude-sonnet-5
plugins:
  - system-static:
      prompt: "You are a research assistant."
  - sandbox-e2b