Paperclip Agents vs OpenClaw Agents in Workflow Management

Executive Summary

Paperclip supports two fundamentally different approaches to running AI agents: native local adapters (e.g., claude_local, codex_local, gemini_local) that spawn agent processes directly on the host machine, and OpenClaw gateway adapters (openclaw_gateway) that communicate with agents through the OpenClaw WebSocket protocol.

Each approach makes distinct tradeoffs across reliability, flexibility, setup complexity, and operational cost. This paper examines both architectures in depth, drawing on source code analysis, production operational data, and the broader industry context for multi-agent orchestration.

Architecture Overview

2.1 Native Local Adapters (Paperclip Agents)

Native adapters follow a direct-execution model. Paperclip spawns a child process on the host machine, pipes a prompt via stdin, and captures structured JSON output from stdout. The adapter handles:

• Process lifecycle: runChildProcess() manages spawn, timeout, graceful shutdown, and signal handling
• Environment injection: PAPERCLIP_RUN_ID, PAPERCLIP_TASK_ID, PAPERCLIP_API_KEY, and other context variables are passed as environment variables
• Session management: Sessions are tracked by session ID and working directory; sessions can be resumed across heartbeats if the cwd matches
• Skill installation: A temporary directory with symlinked skills is created per run and passed via --add-dir
• Authentication: Direct API keys (e.g., ANTHROPIC_API_KEY for Claude) or subscription-based local login

2.2 OpenClaw Gateway Adapter

The OpenClaw adapter follows a gateway-mediated model. Instead of spawning a local process, Paperclip connects to an OpenClaw instance over WebSocket and delegates task execution to the OpenClaw agent runtime. The flow:

1. WebSocket connect: Open connection to ws:// or wss:// endpoint
2. Challenge-response auth: Server sends connect.challenge with a nonce; client signs it with an Ed25519 device key
3. Device pairing: First connection requires device approval (auto-pairing available if auth token is present)
4. Session routing: sessionKeyStrategy determines how sessions map to tasks (issue = one session per task, run = fresh session per heartbeat, fixed = shared session)
5. Agent dispatch: Send agent request with the wake payload (task context, Paperclip env vars as text instructions)
6. Wait for completion: Call agent.wait with timeout; stream events for assistant output, errors, and lifecycle updates
7. Result extraction: Parse usage metrics, runtime service reports, and summary text from the response

Comparative Analysis

3.1 Reliability

3.2 Latency and Performance

3.3 Flexibility and Agent Diversity

3.4 Setup and Configuration Complexity

3.5 Security Model

3.6 Observability and Debugging

3.7 Cost

Session Management Deep Dive

Session management is a key differentiator between the two approaches.

Native Local Adapters

• Session identified by sessionId + cwd
• Session can be resumed if the working directory matches
• Session is cleared on certain error conditions (e.g., missingSession)
• Stateful: agent retains context from previous heartbeats within the same session

OpenClaw Gateway — Three Session Strategies

Idempotency key is set to runId to prevent duplicate execution across retries.

Real-World Operational Evidence

Nucleotto currently runs a mixed fleet of native and gateway agents:

Industry Context

The local-vs-gateway debate mirrors a broader industry pattern in 2026:

• Hub-and-spoke (centralized gateway) models offer strong consistency and simplified management but create potential bottlenecks
• Mesh (local execution) architectures provide resilience and fault tolerance
• The winning pattern emerging is hybrid: high-level orchestrators for strategic coordination with local execution for tactical work
• Error compounding remains a fundamental challenge: 99% per-step reliability across 10 sequential steps yields only 90.4% overall reliability. Each additional gateway layer compounds this.

Recommendations

When to Use Native Local Adapters

• Mission-critical roles (CEO, CTO, finance) where reliability is paramount
• High-frequency heartbeat agents that need fast startup and consistent execution
• Agents requiring session continuity across multiple heartbeats
• Cost-sensitive deployments where minimizing infrastructure overhead matters
• When the desired agent runtime has a CLI that Paperclip supports

When to Use OpenClaw Gateway Adapters

• Accessing agent types that Paperclip doesn't have native adapters for
• Remote agent execution where agents run on different machines
• Heterogeneous teams needing diverse agent capabilities
• When OpenClaw is already deployed and well-maintained in your infrastructure
• For non-critical, async tasks where occasional timeouts are acceptable

Operational Best Practices for OpenClaw Agents

1. Increase waitTimeoutMs for long-running tasks (default 30s is often insufficient)
2. Set timeoutSec to at least 600 for complex tasks
3. Always persist devicePrivateKeyPem in adapter config to avoid repeated pairing
4. Use wss:// for non-loopback connections
5. Monitor OpenClaw gateway health independently
6. Consider sessionKeyStrategy: "issue" for multi-heartbeat tasks, "run" for stateless ones
7. Ensure the OpenClaw DEFAULT_HANDSHAKE_TIMEOUT_MS is increased from 3s to at least 10s

Pricing a Web UI / Chat Interface for the Orchestrator

The natural product extension for an agent orchestration platform is a web-based command interface — a chat UI where operators can see derived actions, approve or deny agent decisions, monitor task flow, and intervene when needed.

8.1 The Product Surface

The orchestrator UI is not a chatbot. It is a control plane with a conversational interface.

8.2 Pricing Models Evaluated

Model 1: Per-Seat Subscription (Traditional SaaS)

Cons: Misaligned with value — a solo founder running 20 agents gets more value than a 50-person team with 2 agents. Per-seat is losing ground industry-wide.

Model 2: Usage-Based (Per-Action / Per-Agent-Hour)

Cons: Unpredictable bills create buyer anxiety. Hard to budget. Requires metering infrastructure.

Model 3: Outcome-Based (Per-Task-Completed)

Gartner projects 40% of enterprise SaaS contracts will include outcome-based components by 2026. Already proven by Intercom ($0.99/resolved ticket) and Salesforce (per-completed-action pricing).

Model 4: Hybrid (Recommended)

8.3 Why Hybrid Wins for Orchestration

1. The value is in coordination, not computation. The orchestrator's value is routing, context, and governance — a platform capability that argues for a platform fee.
2. Agent costs vary wildly. Claude Opus costs ~10x more per token than Haiku. Pass through AI costs or let users BYOK.
3. Approval gates must not be metered. If you charge per approval, users will disable approvals to save money.
4. Per-agent pricing captures fleet scale. A company running 3 agents needs fundamentally less infrastructure than one running 30.
5. Action metering captures intensity. Two companies with 10 agents each may have 10x different action volumes.

8.4 Competitive Positioning

8.5 Feature Gating by Tier

8.6 Revenue Projections

For Nucleotto's current setup (6 agents, 1 operator, ~500 actions/day):

At scale (enterprise customer, 50 agents, 5 operators):

8.7 Implementation Considerations

1. Build metering early. Every action, approval, and heartbeat should emit a billable event from day one.
2. Make the free tier generous. 1 operator, 2 agents, 1,000 actions/mo. Chat + action feed should be free to drive adoption.
3. AI costs as pass-through, not margin. Keep it transparent (5–10% infrastructure fee) or offer BYOK.
4. Approval gates are the moat. The governance layer is the highest-value feature. Never gate it behind the highest tier.
5. Price OpenClaw gateway access at Pro tier and above. Gateway agents require more infrastructure and attract more sophisticated users.

Conclusion

Native local adapters are the right default for most Paperclip deployments. They offer superior reliability, lower latency, simpler configuration, and lower operational cost. The direct-execution model eliminates an entire class of failure modes related to gateway connectivity, WebSocket timeouts, and device pairing.

OpenClaw gateway adapters serve an important role for agent diversity and remote execution, but they come with meaningful operational overhead. Organizations should reserve gateway adapters for cases where the agent capability cannot be achieved locally, and invest in robust monitoring and timeout configuration when using them.