Engineering's shifting left.
The environment your coding agents work inside.
Every task runs in its own workspace. Every change is reviewed by a model that didn't write it, and can't merge until that review converges. Every lesson is kept where the next session will find it.
A CLI, an MCP server, and a web cockpit. Self-hosted, provider-agnostic, Git-native.
Runs under the harness you already use: Claude Code, Codex, opencode, over MCP.
The problem
Eight sessions, five projects, one of you.
You already know the shape of this. Sessions multiply past what you can hold in your head, so every morning starts with reconstruction: what was I doing, what's stuck, where do I start. The review queue is where the work actually stops, because you are the only reviewer any of it has. And the correction you spent an hour on yesterday died with the session that learned it.
Generation scaled. The structure around it stayed one person wide.
- 85% say the bottleneck moved from writing code to reviewing it GitLab, 2026
- 4.6x longer review wait for AI-authored PRs LinearB, 2026 (8.1M PRs)
- 4% measured slowdown from AI assistance, confidence interval spanning zero METR, 2026
- 41% of workers receive "workslop" monthly BetterUp × Stanford, 2025
Measurements from the field, including one that cuts against the case for agent-assisted work. Sourced and dated, because the alternative is asking you to take it on faith.
How it works
Follow one task all the way through.
Seven steps, in order, for a single piece of work: from the moment you file it to the moment its lesson is waiting for the next one. Every screen below is a capture of a running system rather than a mockup.
-
01 / 07
It starts as a task.
You write down what should happen and what would make it correct. The task carries its own success criteria, and its dependencies on other work, so nothing downstream starts before the thing it needs has landed.
-
02 / 07
It gets a workspace of its own.
Nothing runs in your checkout. The task opens a session with its own clone, its own branch, and its own file scope. A session that stalls or goes wrong sits in its own corner and touches nothing else in flight.
-
03 / 07
The agent hits a wall you put there.
Inside that workspace the agent works under the same hooks you do. A commit that skips formatting, an unsafe command, a merge without review: blocked at the moment of the action, rather than flagged afterward in a report nobody reads. The rule holds whether or not the agent remembers it.
-
04 / 07
A model that didn't write it reviews it.
The session opens a pull request in your repository, on GitHub, in the flow your team already uses. minsky-reviewer[bot] reads it with a different model and no implementer context: it did not write this code and has nothing invested in defending it. The merge gate holds until that review converges.
-
05 / 07
The one decision that's actually yours arrives with its context.
Some calls belong to a person: naming something, changing scope, accepting a risk. Instead of guessing, the session packages the question with what you need to answer it and routes it to you. Everything not blocked on your answer keeps moving while it waits.
-
06 / 07
The lesson outlives the session.
Whatever went wrong here and got diagnosed is written down where the next session is handed it, for any agent, in any project, without you remembering to say it again.
-
07 / 07
And this was one task among many.
The cockpit holds the picture that used to exist only in your head: what's in flight, what's blocked, and the short list actually waiting on you. This is the part that changes when the number of sessions goes from one to eight.
Does it fit your setup?
It runs under the harness you already have.
Minsky is a protocol layer rather than a place to go. Every operation is exposed twice: as a CLI command a person types, and as a tool an agent calls over MCP. Same operations, same state, whichever end reaches for them.
- Claude Code MCP, stdio or HTTP
- Codex MCP
- opencode MCP
- Your terminal the same commands, typed
Your repository, your review flow
Work lands as ordinary pull requests in your own GitHub repository. The review is a real review on a real PR, so branch protection, CI, and the humans already reading that queue keep working exactly as they did. Nothing has to move onto a separate platform to be tracked.
Sharing one Minsky across a team
A team shares one Minsky by pointing at one database. Each developer
installs the CLI and runs the MCP server on their own machine; the
shared state, meaning tasks, sessions, reviews, and memory, lives in a
Postgres instance you host and set once with
minsky setup db.
Said plainly: that is what a small team gets today. There is no hosted multi-tenant deployment and no per-user permissions model yet. If your rollout needs those first, they are not built.
› minsky tools search 'review a pull request' --limit 5 Found 5 tools matching: "review a pull request" 1. create [session.pr.create] (score: 0.996) Category: SESSION 2. open [session.pr.open] (score: 1.004) Category: SESSION 3. approve [session.pr.approve] (score: 1.017) Category: SESSION 4. edit [session.pr.edit] (score: 1.046) Category: SESSION 5. list [session.pr.list] (score: 1.073) Category: SESSION
The tool registry an agent searches over MCP, queried from a terminal. Both ends see the same operations.
Is it real?
Its own first customer.
Every change to Minsky goes through Minsky: a task, an isolated session, a pre-commit hook, an independent review, before it merges. When one of those gates misses something, the fix is to tighten the gate rather than to write a note asking the next agent to be more careful.
During a documentation campaign, the orchestrating agent carried explicit written rules requiring success criteria in every task spec. Under throughput pressure it created eleven tasks and skipped the criteria on all eleven, then reported the batch as comprehensive. The rules were loaded in context and lost to load anyway. The fix that held was environmental: a hook on task creation that rejects a spec missing its required sections.
That incident is why the enforcement hierarchy runs the way it does. Rules are text, and text is ignorable under pressure. Skills structure the work before it starts, though they share the doer's context and biases. Subagents come to a question fresh. Hooks are involuntary, and a pre-commit hook blocks an unformatted commit identically for a human and an agent, with nobody watching.
rules<skills<subagents<hooks
Weakest to strongest. Critical checks belong at the involuntary end.
Not every piece described on this page is finished. As of this writing:
- Multi-agent coordination Partially built — dependency tracking and dispatch work; broader cross-agent orchestration is still filling in.
- The cockpit Partially built — core surfaces are live; coverage across every workflow isn't complete yet.
- Decision routing Early — the mechanism that pulls a person in only for genuinely hard calls exists, and is still being tuned.
There are no customer logos here, and none will be borrowed. Minsky is early: one engineer, a public repository, and a commit history you can read before you trust a word of this. What it offers instead of a reference account is that it builds itself under the gates described above, every day, and that the failures get published alongside the fixes.
The full argument, with that specimen in context: The structure gap
Can you run it tonight?
Try it against a real repo.
Minsky installs locally and runs against your own git repository. No account, no signup.
$ git clone https://github.com/edobry/minsky.git $ cd minsky $ bun install && bun link $ minsky init
Source install for now. A packaged single-command release is in progress; until it lands, the four lines above are the whole path.