Product Vision
how we think about building opencompany — and why.
Louis M. Morgner — Apr 2026 — Living document
OC Agent Identity
leo
Maximally useful co-founder agent for founders to get the right things done exceptionally well
opencompany/agents:leo
Operational Spec
oc/leo
Capabilities
skills
subagents
integrations
Snapshot
→ work/
→ context/
→ THINKING.md
→ SOUL.md
→ USER.md
→ AGENT.md
System Prompt
1 SOUL.md
2 USER.md
3 AGENT.md
Hooks
post_session → POST_SESSION.md
Thinking Template
THINKING.md
Usage Fee
of total session cost (tokens, integrations, compute)
Config hash
sha256:e3b0c44298fc1c14
Safety Specs
oc/leo
Permissions
note:this is not our product documentation. it's our internal technical reference — the high-level image of how things should work, written so the team and developers building on OC have a clear picture of the architecture and decisions before we flesh out the full docs.
our product vision is the most important part of our company. this is where the “magic” is and where product-market fit sits.
as we are building on the frontier, we need to figure out hard questions ourselves — how context flows between agents, how users build and share on top of the platform, how Leo becomes genuinely useful day one. we can get creative in doing so. but all exploration must channel back into our product vision. which must be specific and clear.
so in this write up, i want to express my updated understanding of our product vision. as an internal reference for the team to build against.
open by default
the core of our product is open. we want you to be able to run anything you want — inside OpenCompany, which solves:
- vm + sandbox provisioning
- the integration nightmare
- permissions enforcement
- audit trail
- cost control
so you can truly build your ai-native company on this. not just for one person, but for teams.
our answer to this is .oc-agent.yaml. which is how you define what you want to run and how.
this is how it looks:
name: pr-reviewer# display name shown in dashboards, logs, and CLI.description: Reviews PRs for code quality# one-liner so your team knows what this agent does.runtime: oc-native# oc-native for now. claude-code, codex, amp, opencode coming.model: opus# optional. defaults to the runtime's recommended setup.sync:# files/folders synced back to the agent's seed folder after a session.- data/- reports/*.mdsystem_prompt:# files composed into the system prompt on init. priority order.- AGENT.md- CONTEXT.md- RULES.mdthinking_template: THINKING.md# maybe, soon. injected each step to improve model discipline.post_session: POST_SESSION.md# file sent as a user message after the session ends.capabilities:# everything this agent can use.skills:# repos or aliases following the agentskills.io open standard.- github.com/acme/review-skill- oc/code-quality- oc/lineartools:# batteries-included services (e.g. exa, perplexity, apify, browserbase).- exa- perplexity- browserbasesubagents:# agents in your workspace this agent can call.- code-reviewer- test-runnerintegrations:# user-specific data sources that require auth (e.g. linear, slack, github).- linear- slack- githubtriggers:# future — starts sessions automatically from external events.# TODO: enables event-driven and scheduled agents without long-running VMs.- schedule: "0 9 * * 1-5"- webhook: true- event: github.pull_requestprompt:# the message sent to the agent when a trigger fires. use vars like {{event}}, {{source}}, {{payload}}.- "Review PR {{event.pull_request.number}} on {{event.repository.name}}"
a practical choice we made is to rely on a github repo as our primary way to store durable agent state. and we are defining an agent as a folder in which .oc-agent.yaml exists. the folder can have an arbitrary structure, files, scripts. whatever you want.
for skills, we follow the open agentskills.io standard. a skill is a git repo (or alias) containing a skill.md that describes what the skill does, how to invoke it, and what context it needs. this means skills are portable across any platform that supports the standard — not locked to OC.
every workspace = one github repo. this is used to resolve all available agents (based on the definition above).
Cloned from
leo/
Runtime
oc-native
Snapshot on exit
→ leo/
from .oc-agent.yaml to session
when you start a session for an agent, we have a lifecycle of events that happen:
ocr cli for subagents + integrationssetting up the session
with oc-native, we have full control over the session. the system_prompt files get compiled directly into the system prompt. on top of that, we inject a lightweight set of behavioral instructions — basically just how to use the ocr cli.
the important nuance: how and when to use subagents and integrations is the developer's responsibility. these instructions should be written explicitly as part of your system_prompt files. we keep our platform-level instructions lightweight on purpose — we only teach the model the mechanics of calling ocr. the strategy of when to delegate, which agent to call, what context to pass — that's yours to tune.
in the future, we will support additional runtimes — claude code, codex, amp, and opencode — each with their own delivery mechanisms for the same composed prompt. but for now, oc-native gives us the deepest control over session lifecycle, tool use, and reasoning.
vm environment, ocr cli usage, tool calling conventions, basic behavioral guidelines
lightweight listing of available integrations, skills & subagents — points the model to what's possible, expands via ocr at call time
thinking_template is injected separately at each turn, not in the system prompt
lean instructions, just-in-time context
our platform-level instructions are intentionally lean. we only teach the model the mechanics — how to call ocr, what's available, and that context expands at call time. we don't dump API docs into the prompt.
the strategic layer — when to call a subagent, which integration to use, what context to pass — lives in your system_prompt files. this is where developers need to be deliberate. a well-written AGENT.md that explicitly describes when to delegate to the code-reviewer vs handling it inline makes the difference between a useful agent and a confused one.
and with thinking_template, you can inject a structured reflection prompt at every step. this is how you improve model discipline — force it to reason about what tools and subagents to consider before acting. it's not a one-shot plan, it's a continuous loop of act, reflect, decide.
# available integrations - linear: create, update, and query issues - slack: send messages to channels - github: manage PRs and issues # available subagents - code-reviewer: reviews code for quality and security - test-runner: runs and reports on test suites # usage run ocr <integration|agent> <action> for details and to execute. after each step, consider what tools or agents to use next.
the model sees the menu, not the cookbook. here's what happens when it decides to use an integration:
$ ocr linear create-issue
# linear → create-issue # authenticated as: team@opencompany.com # workspace: OpenCompany required fields: title: string team: "engineering" | "design" | "product" optional fields: description: string (markdown) priority: 0 (none) | 1 (urgent) | 2 (high) | 3 (medium) | 4 (low) assignee: email address labels: ["bug", "feature", "infra", ...] example: ocr linear create-issue \ --title "Fix auth redirect loop" \ --team engineering \ --priority 2 \ --labels bug
$ ocr linear create-issue \ --title "Refactor session cleanup to handle snapshot conflicts" \ --team engineering \ --priority 3 \ --labels infra \ --description "Found during PR review — the current cleanup..." ✓ created ENG-847: Refactor session cleanup to handle snapshot conflicts
the model never needed to know Linear's API schema, team names, or auth setup upfront. it asked for help, got exactly the context it needed, and executed. this pattern scales to every integration without bloating the prompt.
inside the vm — ocr in action
every session runs inside an isolated vm. the agent interacts with the outside world through ocr, a cli pre-installed in every vm. two core patterns: invoking integrations and spawning subagents.
Pattern 1 — Integration
pr-reviewer
resolves auth, schema, context
executes with full context
✓ ENG-847 created
Pattern 2 — Subagent
pr-reviewer
provisions vm, passes task
works on other tasks
receives result
code-reviewer
2 issues found
the pattern is the same in both cases: the agent never needs upfront knowledge of API schemas or subagent internals. ocr invoke handles authentication, context expansion, and execution. for integrations, it returns just-in-time context so the agent can make the call. for subagents, it spawns an independent vm and notifies the parent when done — the parent keeps working in the meantime.
roadmap
these are the things we know we want to build, but haven't shipped yet. they sit naturally inside the current architecture — no paradigm shifts needed, just plumbing.
triggers — event-driven sessions
right now, sessions start when a user clicks “run.” but many useful agents need to react to external events — a new PR, a cron schedule, an incoming message. triggers let you define what starts a session directly in .oc-agent.yaml.
each trigger starts a normal session. same lifecycle: init, run, post_session, sync, vm dies. no long-running processes, no daemon mode, no state leak. the serverless model stays intact.
for protocols that require persistent connections — like WhatsApp's socket or Telegram's long-poll — we'll run a shared platform-level channel gateway that maintains the connections and routes incoming messages as session triggers. the agent developer doesn't need to think about connection management. they just receive “a message arrived” as session input.
browser — zero-config web automation
agents run in isolated VMs where they can execute arbitrary commands. browser automation is a provisioning question, not an architecture question. our plan is to pre-install Chromium and Playwright in every VM so that any skill or agent that wants browser access just has it — no flags to set, no capabilities to declare.
a skill like a QA runner can launch a headless browser, navigate your staging app, find bugs, and report back. the ocr cli doesn't need to be involved — the browser is just another tool in the VM, like git or curl.
mcp — compatibility with the broader ecosystem
MCP (Model Context Protocol) is becoming the standard for agent tool extensibility. today, our integration layer runs through ocr, which handles auth, context expansion, and execution. MCP servers solve a similar problem with a different protocol.
we want developers who already have MCP servers to be able to plug them in without rewriting anything. the most natural path: allow MCP servers as a capability type alongside skills, subagents, and integrations. the agent declares them in the yaml, the VM starts the MCP server on init, and the runtime connects to it. this way ocr handles our managed integrations and MCP handles everything else — no conflict, no migration.