Product

Roll out agents across the team without building your own control plane.

OpenCompany gives your team one place to provision agents, choose approved runtimes, connect tools, share skills, and gate risky actions on top of the open runtime.

Claude CodeCodexOpenCodeGit-basedHuman approvalsAudit trail

Try now Talk to team

For CTOs

Give the team one approved way to use agents without turning rollout into a security project.

Learn how rollout works

For builders

Keep agents in git, reuse shared skills and integrations, and stop rebuilding setup from scratch.

Learn how setup works

For operators

Give operators and non-technical teammates prepared agents with company context and safe actions.

Learn where it fits

How it fits

Team

Developers, operators, and non-technical teammates use the same agents.

↓

OpenCompany

Controls access, company context, skills, integrations, and approvals.

↓

Runtime

Launches the agent in Claude Code, Codex, or OpenCode.

↓

Tools

Slack, GitHub, Linear, Notion, internal systems, and your repos.

The runtime does the execution. OpenCompany makes it usable across a team.

Overview How it works Core elements Use cases Team rollout Foundation

Overview

Teams do not need another agent demo. They need a standard.

Most teams start with a few people using Claude Code or Codex ad hoc. The next question is always the same: how do we make this usable across the company without rebuilding the setup for every person?

What OpenCompany changes

Before

Each power user invents their own setup, runtime defaults, prompts, and token handling.

After

The team gets approved agents, shared skills, managed integrations, and one clean setup path.

Buyer question

Can I let more people use agents without giving them raw credentials and production access?

Product answer

Yes. Provision runtimes, integrations, skills, and approvals once, then let the team use the same system.

What the buyer gets

A real rollout path. Shared defaults, clear approval boundaries, and a way to expand beyond a few technical early adopters.

What the user gets

A product that feels close to the runtime they already want, but with team access, shared skills, and managed tools.

Why this matters

The hard part is not starting one agent. The hard part is making the next 50 agents and the next 50 users work the same way.

How it works

Set it up once. Reuse it across the team.

Import the agent, choose the runtime, attach shared skills and integrations, then give people access.

Define or import the agent

Point to the repo, choose the agent directory, and keep the config in git.

Attach the runtime and shared skills

Pick the runtime you approve and add reusable skills so agents do not start from zero.

Connect integrations with scoped permissions

Attach Slack, GitHub, Linear, or internal tools and decide which actions are on, off, or ask.

Assign to people or automate

Launch sessions for a user, wire agents into workflows, and review what they did later.

oc-agent.yaml

runtime: claude-code
name: weekly-ops
model: opus
skills:
  - inbox-triage
  - roadmap-brief
  - launch-checklist
integrations:
  slack:
    channels: ["#ops", "#founders"]
  linear:
    teams: ["product", "engineering"]
permissions:
  slack.send_message: on
  linear.create_issue: ask
  github.push_to_main: off

Core elements

What the product actually includes.

If someone asks what OpenCompany is, it comes down to these pieces.

CLI

For power users and platform teams. Configure agents, sessions, and automation from the command line.

ManagementAPI access

Runtime

Use Claude Code, Codex, or OpenCode. OpenCompany handles the team layer above the runtime.

Runtime choicePortable

Skills

Reusable capabilities. Put company-specific behavior in one place and attach it to many agents.

ReusableShared defaults

Integrations

Connect Slack, GitHub, Linear, or internal systems without putting raw credentials in model context.

Scoped accessManaged credentials

Approvals

Set actions to on, off, or ask. Risky operations stop and wait for a human.

Human-in-the-loopPolicy

Audit

See who ran what, which integrations were touched, and what changed.

VisibilityAccountability

Use cases

Who this is for.

The same system needs to make sense to the buyer, the builder, and the teammate who just wants work done.

Most important

CTOs and engineering leads rolling out AI for the team

The buying reason is simple: you want the team using agents, but you do not want rollout to mean raw tokens, no approval boundaries, and five incompatible setups.

Standardize the setup

Stop every team or engineer from inventing their own runtime, prompts, and token handling.

Provision safely

Give people approved integrations and skills without exposing secrets or opening every action by default.

Review later

See which agents were used, what they touched, and which actions needed approval.

Scale beyond pilots

Move from a few power users to a team-wide rollout with shared defaults.

Technical users

Developers use OpenCompany as the clean layer above the runtime: git-backed agents, shared skills, approved integrations, and the same setup every time.

Founders and operators

Founders and operators use it to run research, project coordination, support, and internal ops against real company context and real tools.

Non-technical teammates

Non-technical users get prepared agents they can run without touching YAML, terminals, or secret management.

Team rollout

How a team rolls this out.

Start with a few builders. Lock down the tool surface. Expand once the defaults are solid.

Start with a small group

Give a few technical users approved runtimes, skills, and integrations so the first setup is worth reusing.

Gate risky actions

Use on, off, and ask to put hard boundaries around production changes, external communication, and expensive operations.

Expand to more teams

Once the defaults are clear, technical and non-technical users can run the same agents without rebuilding the setup.

What teams need

Approved access, shared context, and a visible audit trail. Those are the things that turn isolated experiments into a system a company can keep using.

What teams do not need

More hidden prompt state, more pasted API keys, or another one-off agent environment that only one power user understands.

Foundation

Not a black box.

The team product is commercial. The runtime stays open. That matters if you care about trust, portability, or self-hosting.

OpenCompany team product

Org management and team access
Agent distribution and company context
Shared skills, integrations, approvals, and audit
Hosted experience for teams that do not want to assemble it themselves

Open foundation

Runtime remains open and inspectable
Agents stay git-based and portable
Docs and code explain how execution works
Teams can adopt hosted or self-managed paths from the same mental model

Read docs View GitHub