Company Agents is a local-first product. The desktop app and every agent run on your machine. Our cloud exists for a small set of cross- device concerns (account state, cloud sync, the template marketplace) and sees none of your prompts, code, files, or API keys. This page is the mental model for how the pieces fit together.

​
Two sides

┌─────────────────────────┐        ┌──────────────────────────┐
│ YOUR MACHINE            │◄──────►│ OUR CLOUD (optional)     │
│                         │        │                          │
│ Desktop app (Electron)  │        │ Account + subscription   │
│ Local orchestrator      │        │ Cross-device sync        │
│ Agent processes         │        │ Clipmart marketplace     │
│ Workflow runtime        │        │ Audit log backup (opt)   │
│ PGlite database         │        │ Status page              │
│ API keys (keychain)     │        │                          │
│ MCP tool servers        │        │                          │
└─────────────────────────┘        └──────────────────────────┘
The important invariant: the cloud never sees your agents or the traffic they generate. When an agent runs, a child process on your machine calls your local CLI adapter (Claude Code, Codex, whichever) which calls the upstream model provider directly with your API key. None of that round-trips through our cloud.

​
Four layers on your machine

​
1. Desktop app (Electron)

The window you look at. Written in React with the same Glass design language you see in the marketing site. Ships as a signed, notarized native binary for macOS, Windows, and Linux. The app does nothing on its own. It is a thin client over the local orchestrator.

​
2. Local orchestrator (Node.js)

The brain. A long-running Node process that holds the workflow runtime, the scheduler, the lease manager, the loop detector, the circuit breakers, the budget ledger, and the audit log writer. The orchestrator is the thing that actually decides what runs when. It enforces every budget cap, issues every lease, writes every audit entry, and kills runs that exceed their limits. Agents do not make those decisions; the orchestrator does. Request flow for a single workflow run:
  1. A workflow fires (manual trigger, cron, webhook, or API call)
  2. Scheduler checks all six budget caps before the first step
  3. Scheduler issues a lease on the first step and hands it to an adapter
  4. Adapter spawns the agent as a child process with its memory, tools, and current task context pre-loaded
  5. Agent runs the step. Every tool call goes through the orchestrator’s tool proxy, which enforces budgets and writes the audit entry
  6. Agent marks the step complete. Orchestrator verifies the exit state, releases the lease, and writes a structured checkpoint
  7. Scheduler moves to the next step, re-checks budgets, and repeats
  8. At any point, a gate may escalate to a human reviewer. The run pauses, the reviewer approves or rejects, the run resumes or terminates.

​
3. Local database (PGlite)

All state lives in an embedded Postgres database running inside the app. We use PGlite, which is Postgres compiled to WASM, so you get real SQL without running a separate database server. The database holds:
  • Every company, team, client, project, workflow, agent
  • Every run record, every step result, every cost entry
  • The full audit log (signed, append-only)
  • Memory at all four scopes
  • Cached MCP tool definitions
  • Workflow checkpoints
Data lives at ~/.company-agents/instances/default/db/ by default. It is yours. You can back it up, copy it, move it to another machine, or nuke it.

​
4. Agent processes and adapters

When an agent runs, it is a child process of the orchestrator. The adapter is the code that knows how to start the right CLI:
  • claude-code adapter launches claude-code as a subprocess
  • codex adapter launches codex
  • gemini-cli adapter launches gemini
  • cursor adapter launches cursor-agent
  • openclaw, opencode, hermes, pi each launch their own
Adapters handle the quirks of each CLI (how to pass tools, how to parse the output stream, how to extract cost metadata) and present a uniform interface to the orchestrator. From the orchestrator’s point of view, every adapter is the same: “start this agent with this context, watch its output, kill it if it misbehaves.” Process isolation matters. Every agent run is its own child process with its own environment, its own API key scope, and its own memory. When a run ends, we kill the whole process group with kill(-pid) so nothing orphans.

​
The cloud control plane

Three services run in our cloud. They are optional: if you run in local-only mode, none of these ever get contacted. Account and subscription. Email, password hash, billing status, subscription tier. Stripe for payment processing. Resend for billing email. Cross-device sync. When you turn sync on, workspace metadata is encrypted with a key derived from your password and uploaded to our object store. We cannot read it. If you lose the password, we cannot recover it either. Clipmart marketplace. The public catalog of company templates you can install with one click. Read-only from our side, contributed to via GitHub pull requests. That is the whole cloud. There is no agent runtime in the cloud, no model proxy, no prompt storage, no file upload.

​
The eight adapters

AdapterProviderDefault modelStrengths
claude-codeAnthropicClaude Sonnet 4.5Best instruction following
codexOpenAIGPT-5Lowest per-step latency
gemini-cliGoogleGemini 2.5 Pro2M token context window
cursorCursorMultiFastest codebase search
openclawOpenClawMultiBuilt-in checkpointing
opencodeSSTBYOModel independence
hermesNous ResearchHermes 4Structured output discipline
piPi.devLocalFully offline, privacy-first
All eight ship in the box. Mix and match per agent. See adapters overview for the full comparison.

​
MCP for integrations

Every integration is implemented as an MCP server. When you install the Stripe integration, a local MCP server starts up that exposes tools like stripe.create_invoice to agents. The agent calls the tool through the MCP protocol; the MCP server calls the actual Stripe API with the credentials you provided. This is important because it means new integrations do not require changes to the orchestrator. Anything that speaks MCP can become an integration.

​
Repository layout

The monorepo mirrors the architecture above: 
company-agents/
├── desktop/                # Electron shell
├── server/                 # Local orchestrator (Node.js)
│   ├── src/routes/         # Internal HTTP API the UI talks to
│   ├── src/services/       # Workflow runtime, scheduler, leases
│   ├── src/orchestrator/   # Budget ledger, loop detector, audit
│   └── src/adapters/       # Adapter integration points
├── ui/                     # React UI (Vite)
├── packages/
│   ├── db/                 # Drizzle schema + PGlite migrations
│   ├── shared/             # Types, validators, constants
│   ├── adapter-utils/      # Adapter interface + helpers
│   └── adapters/           # One package per CLI adapter
│       ├── claude-local/
│       ├── codex-local/
│       ├── gemini-local/
│       ├── cursor-local/
│       ├── openclaw-gateway/
│       ├── opencode-local/
│       └── pi-local/
├── skills/                 # Agent skills (reusable capabilities)
│   └── company-agents/     # Core skill every agent includes
├── cli/                    # company-agents command-line client
└── docs/                   # This documentation site (Mintlify)

​
Key design decisions

Local-first. Compute runs on your machine. The cloud is there for the things that genuinely need a shared state (account, sync) and nothing else. Leases, not locks. Every task handoff uses a lease with a TTL and a fencing token instead of a persistent lock. Crashed agents cannot strand work indefinitely. Structured checkpoints. The orchestrator writes a normalized checkpoint after every step, not a conversation dump. The next step gets facts, not replay. Stacked budgets. Six scopes, outer-to-inner. Every inner cap constrains the outer one. Process-group isolation. Every agent run is its own process group, killed with kill(-pid) on exit. No zombies. Append-only audit. Every mutation is logged. Nothing is retroactively edited.

​
Next