Paperclip Alternatives and Competitors, by Category

Paperclip is an open-source platform for running teams of AI agents. It sits at the orchestration layer — the org, not the individual agent. It provides an org chart, per-agent mandates, a goal and project hierarchy, a ticketing system for coordinating work, and governance workflows including execution-policy stages that route tasks through review and approval before completion. The relationship the platform describes is explicit in its own documentation: "If OpenClaw is an employee, Paperclip is the company."

The most common mistake when evaluating alternatives is treating these products as a single category. The field spans five distinct layers of the stack, and each layer answers a different question. Comparing Paperclip to LangChain is structurally like comparing a company to a recruiting firm's job-description template: related in subject matter, different in kind.

The category question comes first.

Category	What it does	Jump to
Orchestrators	Manage collections of agents as an organisation: roles, budgets, approval gates	Orchestrators
Agent runtimes	What individual agents run on: memory, toolset, skill library, model access	Agent runtimes
Build-your-own frameworks	Coding libraries for agent logic; the developer writes the orchestration	Frameworks
Managed and hosted clouds	Fully managed agent infrastructure on the vendor's systems	Managed clouds
Self-hostable low-code builders	Visual workflow builders with agent node types, deployed on your own infrastructure	Low-code builders

Orchestrators

An orchestrator manages a collection of agents as an organisation: goals, reporting lines, budgets, approval gates, and a mechanism for recovery when something goes wrong. The question an orchestrator answers is not "what can one agent do?" but "who owns which task, who is accountable when it fails, and what does the escalation path look like?"

Paperclip is an open-source, self-hostable platform for running teams of AI agents. It models the entity it manages as a company: agents have roles, mandates, and reporting lines; work is tracked as issues assigned to agents; goals and projects give the work structure. Governance is built in — execution-policy stages can route a task through a named reviewer before it closes, and budget controls operate at the company level across all agents simultaneously. The deployment model is infrastructure-owned by default: you run Paperclip on your own servers, data stays local, and nothing leaves your systems beyond the API calls your agents make to model providers. Agents connect to Paperclip through adapter types — hermes_local, hermes_gateway, openclaw_gateway, and built-in adapters for Claude Code, Codex, Gemini, OpenCode, Cursor, HTTP and process-based agents — so the choice of runtime is decoupled from the orchestration layer.

Nothing self-hosted currently pairs a working orchestration layer with org-level governance — org chart, budgets, and approval gates together in the same platform. The nearest self-hosted neighbour is AgentTeams, an open-source multi-agent platform from the AgentScope team at Alibaba. It runs a Manager-Workers architecture where a manager coordinates worker agents, and its own framing is close to the orchestrator idea: agents "collaborate in a controlled and auditable room, with full human visibility and intervention." It self-hosts through Docker or a Kubernetes Helm chart, and coordination happens in Matrix rooms a human can read and interrupt. What it does not carry is the company layer — no org chart, no per-agent mandates, no budgets, and no approval gates that hold a task until a named reviewer clears it. It orchestrates a working session; it does not govern an organisation.

From the managed-cloud side, AWS AgentCore has moved closest, adding Policy — deterministic rules authored in natural language or Cedar that intercept every tool call before it executes — and Registry, a governed catalogue with a publish, review, and approve workflow for agents, tools, and MCP servers. That is genuine governance, and it runs entirely on AWS with no self-hosted path and none of the local-data guarantee. Between them, the two falsify the absolute claim that nothing occupies this position. Neither falsifies the narrower one: on your own infrastructure, the company layer is still not something you can pick up off the shelf.

Agent runtimes

A runtime is what an individual agent actually runs on: its memory, toolset, skill library, and model access. Runtimes and orchestrators are complementary layers, not alternatives. A runtime without an orchestrator runs a single agent in isolation. An orchestrator without a runtime specification defers the capability question to whichever runtime it selects per agent. The decision of which runtime to run inside Paperclip is separate from the decision to use Paperclip as the orchestration layer.

Hermes, built by Nous Research, is the runtime most directly associated with Paperclip. It carries persistent memory across sessions — structured and searchable, with atomic batch write operations — along with 40+ native tools, a self-improving skill library, and model routing across hosted providers and self-hosted runtimes alike — Ollama, vLLM, LM Studio, or any OpenAI-compatible endpoint, so the inference layer can stay on your own infrastructure too. Hermes also supports Mixture-of-Agents as a selectable model type, pulling from multiple reference models simultaneously in a single inference call. It ships as a built-in Paperclip adapter in two variants: hermes_local runs Hermes as a local subprocess on the same machine as Paperclip, and hermes_gateway connects to a remote Hermes instance over HTTP/REST. Hermes also runs as a standalone runtime without Paperclip — useful for single-agent use cases or before introducing company-layer orchestration. The full account of how these two layers divide responsibility is in Paperclip vs Hermes.

OpenClaw is an open-source personal AI assistant you run on your own devices. It is MIT-licensed, runs as a self-hosted Node.js gateway, and connects to the channels you already use — WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, and iMessage among them. Its relationship to Paperclip is compositional rather than competitive: Paperclip's adapter catalogue includes openclaw_gateway, which lets a Paperclip company deploy an OpenClaw instance as a named, managed agent in its org chart, inheriting the same governance rules and work assignments as any other Paperclip agent. As a standalone product, OpenClaw is a personal assistant runtime for individual use. It does not manage teams of other agents, hold a company-level budget, or enforce reporting lines.

Build-your-own frameworks

Developer frameworks provide building blocks for agent logic in code. The developer writes the orchestration; the framework provides the state management primitives, tool routing, graph execution model, or role assignment structure that the orchestration runs on. These frameworks do not ship a working company layer — they give you the raw material to build one. A team building on LangGraph is engineering its own orchestration. A team running Paperclip is operating one that already exists.

LangChain is the most widely adopted open-source framework for building LLM applications. It handles single-agent logic, tool use, prompt templating, chain composition, and retrieval, and it integrates with a broad ecosystem of data sources, vector stores, document loaders, and model providers. Its primary value is the integration surface: most of what an LLM application needs to connect to already has a LangChain adapter. LangChain alone does not manage multi-agent relationships or enforce governance rules — those are engineering problems the developer assumes.

LangGraph is a separate, lower-level project from the LangChain team for stateful multi-agent systems. It models execution as a directed graph: nodes are Python functions or agents, edges define the control flow between them, and the framework handles state persistence across steps through a checkpoint-based storage layer. The developer writes the graph topology in code — LangGraph provides state management, conditional branching, cycles, and human-in-the-loop interrupt points. It is the framework choice when the requirement is fine-grained, programmable control over a multi-agent execution flow and when the team is willing to own the orchestration engineering.

CrewAI models agent teams with defined roles, explicit task assignments, and a delegation structure. It is self-contained with no external framework dependencies. Agents in CrewAI are assigned roles and goals; tasks are defined with descriptions and expected outputs; a crew coordinates the agents through sequential or hierarchical process types. The primary use case is structured, role-based multi-agent pipelines where the workflow is known in advance. CrewAI also offers a managed cloud platform for running crew-based workflows without self-hosting; the framework is MIT-licensed and the cloud platform is a separate commercial product.

Microsoft Agent Framework (MAF) is Microsoft's current investment in agentic developer tooling and reached version 1.0 GA in April 2026. It is the consolidated successor to two prior Microsoft projects: AutoGen, which is now in maintenance mode and no longer receiving new feature development, and Semantic Kernel, which is now in maintenance mode receiving only bug fixes and security patches while all new feature investment moves to MAF. MAF handles multi-agent communication patterns, tool registration, model invocation, and group-chat-style coordination as a developer library. It integrates with Azure AI Foundry, Azure OpenAI, Microsoft Copilot Studio, and the broader Microsoft cloud stack. For teams already embedded in the Microsoft ecosystem, it is the framework path that connects into Azure services without requiring cross-vendor integration work.

Managed and hosted clouds

The hosted cloud platforms offer fully managed agent infrastructure. The infrastructure runs on the vendor's systems; you configure and deploy agents through a managed console or API. The consistent trade-off across this category is data custody: agents run on vendor infrastructure, data is processed there, and none of these products offers a self-hosted deployment path as its standard offering. For organisations where that trade-off is acceptable and the operational overhead of self-hosting is the priority, the managed clouds remove infrastructure management entirely.

Microsoft Copilot Studio is hosted on Azure infrastructure, with deployment to Azure datacenters by geographic region. It is designed for building custom Copilot agents within Microsoft 365 and Azure environments: agents connect to SharePoint, Teams, Power Platform connectors, and external data sources through a low-code configuration interface. Copilot Studio handles LLM invocation, conversation state, channel routing, and connector management; you configure the agent's knowledge sources, topics, and tools through a canvas without writing code. Enterprise governance operates through Microsoft Entra ID. It is the managed-cloud choice for organisations building agents that need to operate within Microsoft's productivity surface.

Gemini Enterprise Agent Platform is a Google Cloud managed service, formerly Vertex AI, announced at Google Cloud Next on 22 April 2026. It is a fully managed service running on Google infrastructure, with Gemini models as the primary inference layer. It handles agent hosting, multi-step reasoning, tool use, and session management, with native integrations into Google Cloud services including BigQuery, Vertex AI Search, and Apigee. The platform targets enterprise workflows already running in Google Cloud environments, with access control and audit logging handled through Google Cloud IAM. There is no self-hosted or customer-infrastructure deployment path for this product.

Amazon Bedrock AgentCore is AWS's fully managed agent infrastructure layer. It handles memory, execution environment, tool connectivity, and session management without server management. Agents built on Bedrock AgentCore use AWS-managed runtimes and connect to foundation models hosted through Amazon Bedrock, including models from Anthropic, Meta, Mistral, and others. AgentCore includes Policy (fine-grained access controls and audit logging via CloudWatch) and Registry (a centralised agent catalog for governance and discovery) components — making it one of the managed-cloud offerings that has moved closest to providing governance tooling at the agent infrastructure level. All of this runs on AWS infrastructure; there is no self-hosted deployment path.

Salesforce Agentforce 360 runs on Salesforce and AWS Hyperforce infrastructure. It is oriented toward CRM-adjacent workflows and integrates natively with Salesforce objects, flows, and records. The advanced orchestration and multi-agent coordination features require Salesforce Data 360, the unified customer data platform that consolidates the organisation's customer data within the Salesforce environment. Agentforce 360 is built for organisations that are Salesforce customers and want to extend that deployment with AI agents operating against their existing Salesforce data. It is not designed as a general-purpose agent platform outside of the Salesforce stack.

IBM watsonx Orchestrate is available as managed SaaS on IBM Cloud, AWS, and AWS GovCloud. It handles AI agent deployment, skill composition, and workflow automation within IBM's enterprise AI platform, with connectors to ERP, HR, and productivity systems that are common in large enterprise environments. IBM is the exception in this group: alongside the SaaS product it offers a client-managed on-premises deployment on IBM Cloud Pak for Data or IBM Software Hub, the latter running on Red Hat OpenShift. SaaS is the default; on-prem is a separate path requiring its own evaluation and contract. watsonx Orchestrate integrates with IBM's broader data, integration, and cloud infrastructure stack.

Self-hostable low-code builders

Self-hostable low-code builders sit between the DIY frameworks and the managed clouds. They provide visual workflow editors — drag, connect, configure — with node types for LLM calls, agent loops, memory operations, and tool integrations. The difference from the frameworks above is the interface: you build workflows through a canvas, not by writing code. The difference from the managed clouds is the deployment model: you run the platform on your own infrastructure, so data does not leave your systems.

This category is commonly in mind when people evaluate alternatives to Paperclip because it occupies the same self-hosted ground. The important distinction: these tools build and run individual agent workflows; they do not manage teams of agents as an organisation, define reporting lines, set per-agent mandates, or enforce org-level budgets and governance. A self-hostable low-code builder answers the question "how do I run this workflow on my own infrastructure?" Paperclip answers the question "how do I run a company of agents on my own infrastructure?"

n8n is a workflow automation platform with a visual canvas that includes LLM and agent node types. It is distributed under the Sustainable Use License — a fair-code licence, not an OSI-approved open source licence — which permits free self-hosting but places restrictions on offering n8n as a managed service to others. A cloud-hosted n8n offering is available separately. The agent nodes support tool calling, sub-workflow chaining, and multi-step LLM reasoning, which makes n8n functional for agentic pipelines within its workflow model. For operators considering n8n as a core infrastructure layer, the Sustainable Use Licence terms — particularly the managed-service clause — are worth reading directly, because the data-custody argument for self-hosting and the licensing terms are distinct questions.

Dify is an open-source LLM application development platform licensed under the Dify Open Source License, which is based on Apache 2.0 with additional conditions. It includes a visual workflow editor, a chat and agent interface, and an orchestration layer that supports tool use, conditional branching, and multi-step reasoning loops. Dify can be self-hosted via Docker Compose or deployed on Dify's cloud platform. The agent features allow individual agents to use tools and operate in loops across a defined workflow, and the platform handles prompt versioning, model switching, and basic observability within its interface. Dify is oriented toward building and deploying LLM-backed applications and agent workflows; it does not have a company-layer abstraction for managing multiple named agents with roles and governance rules.

Flowise is an open-source visual builder for agent workflows, licensed under Apache 2.0. Workday acquired the project in August 2025; the open-source repository remains community-maintained. It wraps LangChain's primitives — chains, agents, vector stores, tools, and memory types — in a drag-and-drop canvas that produces runnable agent flows without writing code. Self-hosted via Docker or Node.js, with an optional Flowise Cloud offering for teams that prefer not to manage the deployment. Because Flowise is a visual interface over LangChain, the underlying agent logic inherits LangChain's patterns: stateless execution by default, with memory and persistence added through explicit component configuration. It is a practical choice for teams that want access to the LangChain ecosystem — its integrations, retrievers, and tool library — without writing the connection code by hand.

Langflow is an open-source visual component-based builder for agentic pipelines, licensed under the MIT License. It is a DataStax project, and IBM announced its acquisition of DataStax in February 2025, so it now sits inside IBM while staying MIT-licensed. It uses a component graph model: each node on the canvas is a functional unit — an LLM call, a retriever, a tool, an agent, a memory store, a conditional — and data flows between components along drawn edges. Self-hosted via Docker or pip, with a Langflow Cloud offering. Langflow has broad component coverage for retrieval-augmented generation, memory, model integrations, and agent loops, and its MIT licence means there are no restrictions on commercial use or managed-service deployment. Like the other builders in this category, it targets individual pipeline construction rather than multi-agent company management.

How the categories bear on the choice

The choice between categories is a governance and data-sovereignty question you answer before the product comparison starts.

If you need to write your own orchestration logic — because you want full programmable control over execution flow, or because your requirements don't fit any existing product's model — the build-your-own frameworks are the relevant category. LangGraph for stateful graph-based control where you own the topology; CrewAI for role-based pipelines with a defined structure; Microsoft Agent Framework for teams already building inside the Azure and Microsoft 365 ecosystem.

If you want a visual interface for building agent workflows on your own infrastructure, the self-hostable low-code builders cover that need. n8n, Dify, Flowise, and Langflow all run on infrastructure you control, and none requires vendor-managed data custody. The trade-off relative to the frameworks is configurability: you work within the visual model and the component library rather than writing arbitrary execution logic.

For organisations already operating on Azure, Google Cloud, AWS, or Salesforce where vendor data custody is acceptable and reducing operational overhead is the priority, the managed clouds remove infrastructure management entirely. The trade-off is that your agents and their data run on the vendor's systems.

Paperclip fits the remaining case: a working orchestration layer on your own infrastructure, with data staying local and no dependency on a vendor's managed service. That guarantee is structurally incompatible with the managed cloud model. It is also a different question from the self-hostable low-code builders: Paperclip manages a company of agents with roles, reporting lines, budgets, and governance rules; the builders manage individual workflows running on their own. Both can self-host. Only one manages the company layer.

The runtime question is separate from the orchestration question. Once the orchestrator layer is chosen, the decision about which runtime capabilities each agent needs — persistent memory, model-agnostic routing, built-in skills — is a distinct evaluation. For the Hermes side of that, Paperclip vs Hermes covers it in full.

I write about running agent fleets on infrastructure you control, roughly every other week. Follow along if that's the layer you're working at.