Company as code
Your company is about to bea git repository.
We mean that literally. A Machine project is a git repo, and the repo is the company: its agents, the skills they have built up, everything they have learned, and the machines they run on. Versioned, diffable, and yours outright.
machine init · machine ship · one repo · any model
- Configuration
- Files in a repo you own
- Runtime
- OpenCode, declared in the repo
- Every change
- A commit you can diff and revert
- Work lands via
- A change request to main
01The definition
Two files define the company.
The project config is the Machine layer: the machine every session boots on, your connectors, triggers and secret names, and what each agent may touch. The OpenCode config is the runtime your agents think in. Everything else is files in the repo.
# Schema version 2. The runtime is OpenCode.runtime: opencode project: name: Northwind # Secret NAMES only. The values are encrypted in the# platform and injected when the machine boots.env: required: [STRIPE_API_KEY] optional: [LINEAR_API_KEY] # The machine a session boots on.sandbox: default: python templates: - slug: python image: python:3.12-slim cpu: 2 memory: 4 # Reach into the outside world. The definition is in# git. The credentials never are.connectors: - slug: gmail-read provider: pipedream app: gmail authorization_strategy: user # Governance: what each agent may touch, never what# it says. A grant you leave out resolves to none.agents: invoice-clerk: sandbox: python connectors: [gmail-read] secrets: [STRIPE_API_KEY] skills: [reconcile-invoices]The Machine layer. One file, at the root of the repo.
{ // Docs: https://opencode.ai/docs/ "$schema": "https://opencode.ai/config.json", "theme": "system", // The session is already an isolated machine on a // throwaway branch, so the agent starts wide open. // Tighten per tool here when you want a stricter // policy. "permission": "allow"}The runtime: models, tools, permissions. It sits in the runtime folder.
---description: Reconciles invoices against payments.mode: primarypermission: bash: ask--- You are the invoice clerk for Northwind. Match every payment to an invoice by number, neverby amount. When you cannot, open a change requestand say exactly what you could not reconcile.The agent. A stock OpenCode agent file, and the place its instructions live.
The project config grants
Which machine, which connectors, which secrets, which skills, which CLI commands. Governance and nothing else. Leave a grant out and it resolves to none, so an agent gets exactly what you gave it.
The OpenCode config decides
Prompts, models, tools, plugins and permissions. Each agent is a stock OpenCode agent: markdown at the core, with its tools, plugins and model config sitting next to it in the same repo. Read the folder and you know what the agent will do.
Neither file holds a secret
The config names each secret and grants it per agent. The values stay encrypted in the platform, get injected into the machine at runtime, and never land in the repo or the logs.
02Open the repo
The company is right there, in plain text.
Agents, skills and memory are not rows in a database you cannot see. They are markdown files next to your code, cloned into every session. A person can read them. An agent can edit them.
- northwind/#the repo, and the company
- project config#the Machine layer
- runtime folder/#everything your agents run on
- memory/
- MEMORY.md#what the company has learned
- opencode/
- opencode.jsonc#the runtime your agents think in
- agents/#one OpenCode agent per file
- invoice-clerk.md
- skills/#how this company does a job
- reconcile-invoices/
- SKILL.md#read once, used every session
- tools/#the tools you wrote yourself
- plugins/#and the ones you installed
- src/#and the rest of your repo
What stays out of it, on purpose
01
Secret values
The repo holds names and grants. The values are encrypted in the platform and injected when a machine boots.
02
Channel routing
Which Slack or Teams channel reaches which agent is live project state you set in the dashboard. Connecting one adds a connector your agents can call.
03
Live session state
Every session runs on its own machine, on its own branch. Nothing it does touches the repo until it commits and opens a change request.
03Auditable
grep your whole company.
There is no hidden layer to ask about. Every belief, permission and instruction is a line in a file, and the tools you already use can answer the question.
# what does the company believe about pricing?$ grep -rhi "annual" --include=MEMORY.md .never quote annual before the security review # who is allowed to touch the Stripe key?$ grep -rhn "STRIPE_API_KEY" --include="*.yaml" .10: required: [STRIPE_API_KEY]36: secrets: [STRIPE_API_KEY] # who changed the invoice clerk, and when?$ git log --oneline -- '*agents/invoice-clerk.md'8f2a1c4 invoice-clerk: stop guessing at refunds1d90b73 invoice-clerk: first draft of the personaOne search covers everything
Every agent prompt, skill, remembered fact and grant is text in one repo. No console to click through. No export to request.
History you can prove
Every change to an agent, a skill or a memory file is a commit with an author, a timestamp and a diff. Nothing disappears, and nothing happens in the dark.
Undo is git revert
A bad instruction went in on Tuesday? Read the diff, revert the commit, open a change request. The company is back to how it was.
04Every change is reviewed
Your company learns one approved commit at a time.
When an agent finds a better way to do the job, it does not quietly remember it. It edits the skill, commits on its own branch and opens a change request. A person reads the diff and decides.
Change request9f4c2b7e → main·opened by invoice-clerk
skill: reconcile-invoices · handle partial refunds
skills/reconcile-invoices/SKILL.md+5 −1
## Matching a payment to an invoice 1. Pull the invoice by number, never by amount.2. If the amounts differ, flag it for a human.2. If the difference matches a refund already on file, close it as a partial refund and note the refund id on the invoice.3. If they differ for any other reason, flag it for a human and say what you checked. Never issue a refund yourself.A person reviewed it, then it merged to main
A prompt change looks like a code change
When an agent rewrites its own instructions, it arrives the way a database migration does: a branch, a commit, a diff, a reviewer. One review process for the whole company, not two.
Nothing merges itself
The machine proposes. A person decides. Work reaches main only through a change request someone approved, so the company cannot drift while you look away.
05It improves itself
The company files patches against itself.
An agent can read its own configuration, edit it and propose the change. Put that on a schedule and the repo gets better at being your company while everyone sleeps.
triggers: - slug: memory-reflector name: Memory reflector type: cron agent: memory-reflector enabled: false cron: "0 0 3 * * *" timezone: UTC prompt: | Reflect on the last 24 hours of project activity. Review git history, merged change requests and session digests. Update the memory folder and open one change request titled `memory: ...`. Exit without one when there is no durable knowledge.A trigger sits in the same file as everything else. Starter projects ship theirs switched off.
Step 00
You switch it on
Set enabled to true and it fires at 03:00 UTC, with nobody watching. Triggers are cron schedules and signed webhooks, declared in the same file as everything else.
Step 01
A session starts
It gets its own cloud computer and its own branch, holding exactly one grant from the config: permission to open a change request.
Step 02
It edits the company
It reads the git history and the last day of sessions, then writes what it learned into the memory folder as plain markdown.
Step 03
You get a diff
One change request is waiting in the morning. Merge it and the company knows something new. Close it and nothing happened.
06Yours to take
It is a git repo. It does what git repos do.
No export flow, no support ticket, no proprietary format to pick apart. The company is already text on a branch, so it clones, forks, reverts and leaves with you.
# turn any directory into a Machine$ machine init # check it compiles, ask for the missing secrets,# push it up, and bring the whole thing live$ machine ship # from here it is just a repo$ git clone git@github.com:northwind/northwind.git$ git revert 8f2a1c4$ machine cr01
A company you can clone
Fork it for a second business unit. Branch it to try a different set of agents. Hand it to a new team and the skills, the memory and the grants go with it.
02
Same on a laptop as in the cloud
machine init scaffolds it and machine ship brings it live. Same repo, same behaviour, so local development and the live system stop being two different things.
03
Any model, your own keys
Bring any provider, or the ChatGPT, Claude or Cursor subscription you already pay for. The model is configuration in your repo, not a call a vendor makes for you.
04
Runs where you choose
Run it on Machine Cloud, in your own VPC, or fully on-prem. Read the code, fork it, audit it. Nobody rents your company back to you.
One repo
Turn a directoryinto a company.
machine init makes any directory a Machine. machine ship brings it live. From then on it is one repo you own: versioned, diffable, and getting better one reviewed change at a time.
- One repo
- Every change reviewed
- Open source
- Any model