Paperclip Alternatives: What Actually Competes With It

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 topology	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. What that self-hosted deployment actually requires, and what it settles about data custody, exposure, and backups, is covered in Paperclip Hosting.

Self-hosted platforms have moved into this layer. What is still not available off the shelf is the pair of controls that make an organisation an organisation rather than a working session: a budget scoped and enforced before spend, and an approval that holds a unit of work open until a named reviewer clears it.

The nearest self-hosted neighbour is AgentTeams, an open-source multi-agent platform from the AgentScope team at Alibaba. It self-hosts through Docker or a Kubernetes Helm chart, runs a Manager-Workers architecture, and coordinates in Matrix rooms a human can read and interrupt — its own framing is close to the orchestrator idea: agents "collaborate in a controlled and auditable room, with full human visibility and intervention." At release v1.2.3 it carried a real part of the company layer. Its declarative resource API defined a three-tier structure the documentation itself heads "Organization Structure" — admin, manager, team leader, workers — where every team names exactly one team leader, and each human holds a permission level governing which teams and workers they may address. Each worker carries its own identity, values, behaviour rules and skill set.

Two controls were outside that model at that tag, and they are the two an organisation actually runs on. The first is spend. The resource type definitions at v1.2.3 gave a worker a CPU field and a memory field, and nothing else that meters what it consumes: compute is allocated, money is not. The second is a hold on the work itself. At that tag the approval control operated on tool calls — a per-worker setting deciding which calls ran unattended and which paused for a human — rather than on a unit of work waiting for a named reviewer to clear it. The platform's own use-case guidance is where the distinction shows: it tells the operator to write approval gates into the task instructions and to forbid irreversible operations without confirmation. That is an instruction the agent is asked to honour, not a state the platform holds the work in.

Read, not run. The two AgentTeams limbs above — no field for spend, and an approval scoped to tool calls — were read on 2026-09-17 from the project's repository at release tag v1.2.3 (published 2026-08-22): the resource type definitions in agentteams-controller/api/v1beta1/types.go, the declarative resource API in docs/usage/resource-management.md, and the operator guidance in docs/usage/use-cases.md. They describe that tag and nothing after it. A controller-level approval API that is role-scoped, and available in only one of the two deployment modes, was absent at v1.2.3 and present on the project's unreleased default branch when this was read — so a reader running a later release should check the tag they are on rather than this one. Nothing here was installed or executed.

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 the control plane is AWS's alone — no self-hosted path, none of the local-data guarantee. The estate it governs is a different matter. As the developer guide reads on 2026-09-16, the Registry is a catalogue for discoverable resources "regardless of the underlying technology," syncs entries from an external MCP server by URL, accepts any MCP-compatible client "without needing to use the AWS SDK," and authorises through Okta, Microsoft Azure AD, or any OAuth 2.0-compatible provider. The service runs on AWS; what it reaches does not have to. Between them, the two falsify the absolute claim that nothing occupies this position. Neither falsifies the narrower one: on infrastructure you own, a budget enforced before spend and an approval that holds a unit of work for a named reviewer are 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, though bounded rather than queryable: a token-capped set of memory files, maintained through atomic batch write operations and injected into the system prompt as a frozen snapshot at session start. What is searchable is the session history, which is a separate subsystem — CLI and messaging sessions are stored in SQLite with full-text search. Alongside those it carries a native toolset, 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: at v0.18.0, each named MoA preset appears as a selectable model under the moa provider. It is not one inference — the preset runs its configured reference models without tool schemas, appends their output as private context, then calls an aggregator model whose reply is the real response and which drives the tool loop from there, repeating the process on every iteration; the vendor's own note is that almost all of a preset's cost lands on the aggregator's provider. 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 an already-running remote Hermes API server over HTTP/SSE. 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 AI assistant you run on your own hardware. 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, iMessage, Matrix, Microsoft Teams, and Zalo 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 it reaches further than "personal" suggests, and that is worth reading carefully before assuming a company layer is missing. OpenClaw's documentation index states that the same gateway "runs as a personal assistant on one laptop or as a shared team deployment; configuration is the only difference." It does manage teams of other agents: openclaw agents team create builds, in the vendor's words, "a chief of staff (coordinator) plus researcher, writer, and reviewer from the role templates." And the lines between those agents are configuration rather than convention — subagents.allowAgents names which specialists a coordinator may address, while the specialists are given an empty allowAgents list and instructions to "return results without further delegation."

What it does not carry is the money. OpenClaw's token-use reference documents cost estimation and monitoring and no spend cap, and an open tracker issue (openclaw#112086) asks for exactly that enforcement. That is the honest line, and it is narrower than a category claim: read against OpenClaw's own documentation on 2026-09-16, OpenClaw will run a team of agents on hardware you own. It will not hold a budget over one.

Build-your-own frameworks

Developer frameworks provide building blocks for agent logic in code. The developer writes the topology; the framework provides the state management primitives, tool routing, graph execution model, or role assignment structure that the topology runs on.

None of the four below ships a working company layer, on a definition worth stating rather than implying: an org chart, per-agent mandates, a budget scoped at the organisation, and an approval that holds a unit of work until a named reviewer clears it — all four, in one product. Individual pieces do arrive pre-built. LangChain ships middleware that intercepts an agent before and after it runs; CrewAI ships roles and manager-style delegation; Microsoft Agent Framework ships a human approval gate that fires before a tool executes. What none of them ships is the set, or the organisation the set would govern. A team building on LangGraph is engineering its own topology, and the orchestration runtime underneath it is the vendor's — which is how LangGraph's own overview describes itself: "a low-level orchestration framework and runtime." A team running Paperclip is operating a company that already exists.

Versions read for this section: LangChain 1.4.1, LangGraph 1.2.11, CrewAI 1.15.21, and Microsoft Agent Framework 1.0; the approval-gate detail below comes from a Microsoft documentation page last revised 2026-08-25.

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. At 1.4.1 it also reaches past single-agent work, in two ways that are easy to miss if you last looked at LangChain a year ago. It documents multi-agent composition directly, and Deep Agents adds subagents, skills and planning, so agents can be composed rather than only chained. And its middleware layer enforces: before_agent() and after_agent() hooks, PII-detection middleware and human-in-the-loop middleware all intercept an agent in flight. The scope of both is the agent. There is no org chart over those subagents, no budget across them, and no approval that holds work open for a named reviewer — those remain engineering problems the developer assumes.

LangGraph is a lower-level project from the LangChain team for stateful multi-agent systems. It is separately installable, but "separate" understates the relationship: LangChain's documentation describes its own agent abstractions as built on top of LangGraph, so a team running LangChain 1.x is already running LangGraph underneath it. It models execution as a directed graph: nodes are functions or agents — Python and JavaScript/TypeScript both have first-class implementations of the same graph API — 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. Offered as our judgement rather than as a sourced fact: it is the framework to reach for when the requirement is fine-grained, programmable control over a multi-agent execution flow and the team is willing to own the topology.

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, security patches, and stability updates 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 also ships a human approval gate as a first-class construct: approval_mode="always_require" means, in Microsoft's words, that "you can require human approval before a tool is executed," with queued requests, standing rules, and pending approvals persisted into checkpoints. That is a real gate, and the distinction from a company-layer one is where it sits — it holds a tool call, not a unit of work waiting on a named reviewer. 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 and data is processed there. For four of the five, the product itself has no customer-infrastructure deployment path. The fifth, IBM watsonx Orchestrate, is a genuine exception and is treated as one below — SaaS is the default, and a client-managed on-premises deployment exists alongside it as a separate path. For organisations where the trade-off is acceptable and the operational overhead of self-hosting is the priority, the managed clouds remove infrastructure management entirely.

Every claim about these five products was read against the vendors' own current documentation on 2026-09-16. None of them publishes a version number on the pages concerned, so the read date is the strongest stamp available.

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 — its Agent Runtime page positions it as managed-only, and Google Distributed Cloud's air-gapped service list does not enumerate it. The wider question has a different answer, and an operator should know both. Google announced general availability of Gemini on GDC air-gapped — "directly into your data center," in its own words — on 2025-08-28, with Agentspace search, which Google calls a pre-built agent, in preview there. Google's models can run inside a facility you control. This platform is not the route by which they do.

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. Its developer guide now lists eleven services, among them Policy (fine-grained access controls and audit logging via CloudWatch), the AWS Agent Registry (a governed catalogue for discovery and approval), Harness, Evaluations, Optimization, and Payments — making it one of the managed-cloud offerings that has moved closest to providing governance tooling at the agent infrastructure level. Note the Registry's namespace if you are building against it: it has launched under agent-registry, and AWS has said support for the public-preview bedrock-agentcore namespace is discontinued from 2026-09-17. All of this runs on AWS infrastructure; there is no self-hosted deployment path.

Salesforce Agentforce 360 runs on Salesforce's own infrastructure and on Hyperforce, which Salesforce deploys on AWS, Microsoft Azure, and Google Cloud depending on region. 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 is altitude. These tools build and run agent workflows, and some of them can now name an agent, give it standing instructions, and let it hand work to another agent. What they do not carry — checked at n8n 2.39.6, Dify 1.17.1, Flowise 3.1.4 and Langflow 1.12.2, against vendor documentation read on 2026-09-16 — is the layer above that: a reporting structure the agents sit inside, and a budget scoped and enforced before spend rather than reported after it. 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 fair-code distributed under the Sustainable Use License v1.0 together with a separate n8n Enterprise Licence covering source files with .ee. in the filename or .ee in the directory name; n8n does not describe this as open source. Self-hosting is free, and n8n's documentation rules out white-labelling it or hosting it as a service where clients build their own workflows; charging clients for workflow creation, setup, maintenance and consultancy is expressly permitted, and the determining factor n8n names is client access rather than client count or revenue (community-license FAQ, read 2026-09-23). A cloud-hosted offering is available separately. Alongside the agent nodes, n8n has shipped an Agent Builder in which agents are named artifacts in a project, each with its own instructions, skills, schedules, and sub-agents it can hand work to. At 2.39.6 that product is in Preview, has been self-hosted Beta since 2.32.3, and is not available on self-hosted Enterprise. For operators considering n8n as a core infrastructure layer, the licence terms 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. Naming an agent and giving it a role is squarely inside the product: Dify's own documentation says agents are "managed centrally," that one arrives "like a full-time employee," and that "in the prompt, set the agent's role." What Dify does not have is a company-layer abstraction above those agents — no reporting lines between them, no budget scoped at the workspace and enforced before spend, and no approval that holds a piece of work open until a named reviewer clears it.

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 began as a drag-and-drop canvas over LangChain's primitives — chains, agents, vector stores, tools, and memory types — producing 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. Agentflow V2 moved the project off that footing: Flowise's own documentation describes V2 as a shift away from "V1's primary reliance on external frameworks" toward standalone nodes "developed natively as core Flowise components." Execution is still stateless by default — Flow State, in Flowise's words, "is destroyed when that specific execution ends" — with memory and persistence added through explicit component configuration. It is a practical choice for teams that want a canvas over a broad integration 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. Multi-agent flows are reachable: an agent component set to Tool Mode can be handed to another agent, which composes agents into a single flow. What is not there is the company around them — no org structure, no roles carrying mandates, no budget at the workspace level, and no approval gate held open for a named reviewer. Like the other builders in this category, it targets pipeline construction rather than 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 assemble the orchestration yourself — 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. Paid tiers of n8n and Flowise do require a vendor licence key, which is a licensing dependency rather than a hosting one: the instance still runs on your hardware and the data-custody position is unchanged. 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 models the company — agents with roles, reporting lines, budgets, and governance rules — while the builders model the work. Both can self-host. Only one has an organisation to govern.

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.