OpenCompany: a self-hosted canvas for AI agent workflows
Self-improving AI Employees to run a business turning LLM tokens into work and dollars.
At a glance
- What is it?
- OpenCompany is a Python and Node.js canvas where you wire agents to email, chat, calendars, a browser, and an Android phone, then deploy the graph as a background listener. It is a serious integration surface with an unusually thin published contract, so read the docs before you commit a workflow to it.
- Who is it for?
- Adopt OpenCompany if you want an agent-first graph you host yourself, you are comfortable reading docs.opencompany.sh before trusting a node, and you have someone who can read Python when a run misbehaves. Do not adopt it if you need a stable API surface, published benchmarks, or an integration that is not in the node list.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OpenCompany is aimed at
Most agent frameworks hand you a Python library and leave the scheduling, credentials, and inbound events to you. OpenCompany takes the opposite position: the workflow is a graph you draw, and the runtime owns the triggers. The README frames it as "think n8n, built agent-first", and the topics list on the repository includes zapier-alternative alongside hermes-agent and loop-agents. The intended user is someone who wants an assistant that reads an inbox, answers a WhatsApp message, checks a calendar, and runs on a schedule, without writing a service for each of those channels.
The secondary audience is the self-hosting crowd. The homepage slogan is "Your own AI workforce, running on your own machine", and the topics include self-hosted and own-your-data. That matters because the alternative for most of these integrations is a hosted automation product where the credentials and the message history live on someone else's infrastructure. OpenCompany's answer is to run the orchestrator locally and let you point it at Ollama or LM Studio so the model calls stay on the machine too. Whether the credential store actually keeps secrets local is something the supplied material does not state, and it is the first thing to check.
How the canvas, triggers, and durable agents fit together
The mechanism is a directed graph. You pick nodes from a palette, drop them on a canvas, and connect them with lines. A node can be run in place with the Run button for testing, or the whole workflow can be started, at which point it becomes what the README calls a durable background listener that waits for emails, reacts to messages, or fires on a schedule. Any workflow can also expose a live /webhook/{path} endpoint that accepts GET, POST, PUT, DELETE, and PATCH.
Two node types carry most of the agent behaviour. A Context node makes a conversation persist across every trigger firing, and the README says you can inspect the agent's live context from the canvas as either a formatted transcript or raw JSON. A Memory tool holds facts, preferences, and decisions the agent explicitly chooses to remember, with vector search for recall. The distinction is deliberate: context is the running transcript, memory is what the agent decided to keep.
For multi-agent setups, an AI Employee or Orchestrator acts as a team lead. Specialists are attached through an input-teammates connection, and the lead hands out bounded work through a built-in Task Manager. According to the README, tasks are durably queued, up to three descendants run in parallel, and the lead must accept the result. A read-only Team Monitor shows the queue. That acceptance step is the interesting design choice: it means a lead can reject a specialist's output rather than passing it straight through, which changes what a failed run looks like in practice.
Installing it and getting a first workflow to run
The published path is a global npm install. Prerequisites are Node.js 18 or newer and Python 3.12.
npm install -g @zeenie-ai/opencompany company start
The README says the UI then serves at http://localhost:5678, and that you click the key icon labelled API Credentials in the toolbar to connect an AI provider. Three example workflows load on first launch, so the fastest way to understand the graph model is to open one and edit a node rather than start from an empty canvas.
Running from source is documented for contributors. It uses bun rather than npm for the build:
git clone https://github.com/zeenie-ai/OpenCompany.git OpenCompany cd OpenCompany npm install -g bun bun run build bun run dev
The dev task serves the Vite client with hot reload on the same port 5678 and proxies API and WebSocket traffic to the Python backend on 5679. The README states that optional daemons for WhatsApp and Temporal are spawned by the backend on demand. Every port is declared in .env.template and can be overridden in .env, and the README claims nothing is hardcoded. Setup and script details are in docs-internal/SETUP.md and docs-internal/SCRIPTS.md.
If you are coming from MachinaOS, the old release names in this repository's history, existing state under ~/.machina or a checkout-local .machina directory is detected when the new .opencompany location does not yet exist. The machina command still works as a deprecated alias, but new scripts should call company.
What the node library actually covers
The README claims 146 nodes across 31 categories, and the coverage list is broad enough to be worth reading in full before you assume a gap. Email and calendar span Gmail, Google Calendar, Drive, Sheets, Tasks, and Contacts, plus Microsoft 365 mail and calendar over the Graph API. Generic IMAP covers Gmail, Outlook, Yahoo, iCloud, ProtonMail, Fastmail, and custom servers, and there is a polling trigger that fires a workflow on each new message.
Messaging is the deepest area. WhatsApp personal covers groups, contacts, and newsletter channels. WhatsApp Business uses the official Meta Cloud API with templates, media, interactive messages, and signed webhooks. Telegram supports bots with owner detection, Discord supports a bot with gateway message triggers, slash commands, and OAuth2, and Twitter/X supports posting, replies, and search. A unified social node normalizes incoming messages into one shape so a single workflow can handle several platforms.
Beyond chat, there is provider-abstracted text-to-speech and speech-to-text across OpenAI, ElevenLabs, Deepgram, Groq, and Sarvam, with reference-based audio that flows between nodes, plus translate, transliterate, and detect-language nodes. Phone control pairs an Android device by QR code and exposes 16 device services including battery and network status, app launching, WiFi, Bluetooth and airplane toggles, camera, sensors, and media playback. Web work includes an interactive browser navigating an accessibility tree, an alpha harness that drives your real Chrome over CDP, scraping through Crawlee and Apify actors, TikHub's social API, and search via DuckDuckGo, Brave, Serper, and Perplexity. The README also mentions running Python, JavaScript, and TypeScript, though the supplied text is cut off at that point, so treat the code-execution node as unverified.
Where the published material runs out
The README is a feature list, not a contract. There is no published schema for a workflow file, no stability guarantee for node interfaces, and no statement about what happens to in-flight tasks when the backend restarts. The word durable appears repeatedly for context, memory, tasks, and listeners, but the material never says what backs that durability. If a workflow is mid-run and the process dies, whether the queue recovers is not described.
The version numbering is the other signal. The most recent release in the supplied list is v0.0.95, and the two before it were v0.0.79 and v0.0.78 under the old MachinaOS name. Everything is still in the 0.0.x range, which in practice means node names, connection types like input-teammates, and config keys in .env can change between releases without a deprecation cycle. The rename from MachinaOS to OpenCompany already forced a state-directory migration path, and that is the kind of change that will happen again.
There is also no performance data of any kind in the supplied material. No throughput figures, no latency numbers for the webhook path, no memory footprint for the Python backend. That is not a criticism of the project so much as a boundary on what can be asserted here. Anyone sizing this for a real workload has to measure it themselves.
OpenCompany against n8n and the hosted automation tools
n8n is the obvious comparison, and the README invites it. The difference is where the agent sits. In n8n, a workflow step calls a model and the graph is the orchestration. In OpenCompany, the agent is a first-class node with its own Context, Memory, and Task Manager, and the graph is how you give that agent hands and a schedule. The README's own framing, "think n8n, built agent-first", is accurate about the intent, and the 146-node library is the part that has to compete with n8n's much larger integration catalogue.
Against hosted automation products, the split is operational. OpenCompany runs on your machine, takes your own API keys, and can route model calls to Ollama or LM Studio so they cost nothing per token. The trade is that you own the uptime, the credential storage, and the upgrade path. There is no usage limit and no subscription, but there is also no vendor to call when the WhatsApp daemon does not spawn.
Against writing your own agent loop in LangGraph or a similar library, OpenCompany's advantage is the pre-built integration surface and the visual inspection of a running agent's context. Its disadvantage is that you are working inside someone else's runtime, with node interfaces that are still moving at 0.0.x. If your workflow is two steps and one API call, the canvas is overhead.
Licence, upgrades, and what maintenance costs
The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is the plain reading of the licence identifier in the repository metadata. It says nothing about the services you connect the tool to: Meta's WhatsApp Cloud API, Google's Gmail and Calendar APIs, and the model providers all have their own terms, and those are where the real compliance questions sit. Nothing here is legal advice.
Upgrade cost is the more practical concern. Because the project ships frequently and is pre-1.0, the honest maintenance posture is to pin the version you install, read the release notes before each bump, and keep a copy of .env and the state directory before upgrading. The MachinaOS migration path is the precedent: the README states that state under ~/.machina and a checkout-local .machina directory is detected only when the new .opencompany location does not yet exist. That fallback works once. It is not a general upgrade mechanism, and a future directory or schema change may not have one.
The company command is the forward-looking entry point and machina is a deprecated alias. Any scripts you write should call company, because the alias is explicitly marked for removal in spirit even if no removal date is given.
Editorial conclusion
Adopt OpenCompany if you want an agent-first graph you host yourself, you are comfortable reading docs.opencompany.sh before trusting a node, and you have someone who can read Python when a run misbehaves. Do not adopt it if you need a stable API surface, published benchmarks, or an integration that is not in the node list. Before wiring anything production-facing, verify three things: that your Python 3.12 and Node 18+ environment matches the prerequisites, that the credentials you enter through the API Credentials dialog are stored where you expect, and that the version you install is the one whose docs you read. The project is at v0.0.95 with three minor releases in the supplied window, so pin the version and re-read the release notes on every bump.
Community notes