Merge on evidence

We build Palisade with Palisade, every day. This is what we believe about working with coding agents, and why the tool looks the way it does.

Narration is not evidence

A coding agent will tell you it is done. It will tell you the tests pass. It will summarise its changes in confident, tidy prose.

Sometimes that summary is true. Sometimes the agent ran the wrong command, or no command at all. Sometimes it fixed the test instead of the bug.

We do not think the answer is a better summary. A summary is still a model describing its own work. The person reviewing it has no way to tell a true report from a plausible one.

So we changed the question. We stopped asking the agent whether the work is done. We ask the project.

Every project in Palisade names a verify command. It might be your test suite, your typecheck, your build, or all three. A change is green only when that command exits 0 at a named commit. Green never means a model said so.

Merge runs configured checks that lack passing evidence at the current commit and stops if they fail. You can override it, because you own the repo and sometimes you know better. But the override is explicit, and Palisade says so. Nobody mistakes it for a passing run later.

This sounds strict. In practice it is freeing. You stop rereading transcripts to decide whether to trust them. You read the exit code, then you read the diff.

Parallel agents need isolation

One agent at a time is slow. The obvious fix is to run several. The obvious problem is that they share a working tree.

Two agents editing the same checkout will collide. One reformats a file the other is halfway through. One runs the tests while the other has broken the build. Neither result means anything.

Palisade enables isolated Git worktrees by default for Go tasks, each on its own branch. Keep isolation enabled to build in parallel. Spec mode writes shared planning documents in the project root; overlapping changes can still conflict at merge.

Isolation also makes evidence honest. A verify run in a thread's worktree tests that thread's changes and nothing else. The result belongs to one commit on one branch.

Isolation does not mean blindness. The fleet board shows when two running threads touch the same files. You see the overlap before it becomes a merge conflict.

Review is a lane, not a modal

Most tools treat review as a step you pass through on the way to merge. A dialog opens, you skim, you click.

When several agents run at once, review is where most of your time goes. It deserves a place of its own.

In Palisade, review is a lane. A thread's diff sits there file by file. Each file has its own viewed state, so you know what you have read. The verify evidence sits beside the diff, not in another window.

The fleet board feeds that lane. Every thread across your open projects is a row: needs attention, running, unreviewed, or idle. Each row shows the agent, the diff stat, the verify evidence and merge readiness.

A finished turn nobody has opened is marked unreviewed. It badges the dock. ⌘⇧U takes you to the next one. Nothing is blocked while you are away. The work simply waits for you in order.

One layer over the agents you already have

We did not build another agent. There are plenty, and they keep getting better. Most developers already pay for one or two.

What was missing was the layer above them. A place to run several at once, compare their output, and decide what ships.

Palisade speaks ACP, the Agent Client Protocol. It discovers Claude Code, Codex, and other agents from the ACP registry at runtime. None are compiled in. You pick a different agent for each thread.

Palisade uses your existing accounts and subscriptions. There is no Palisade billing between you and your provider. If an agent is missing, Palisade says what is missing and how to fix it.

On top of single threads sit playbooks. A playbook is a saved graph of agent nodes. Gates sit on the edges between them: a verify command, or your approval. One agent drafts, another reviews, and nothing moves forward until the gate opens.

Planning gets the same discipline. Palisade has two modes, spec and go. Spec writes an OpenSpec change with the agent's permissions locked down. Go builds it. OpenSpec stays the source of truth, and Palisade never writes a spec file itself.

Local by default

A development environment sees everything. It should be clear about where that goes.

Palisade keeps session logs, completion telemetry and settings under ~/.palisade-code on your machine. Editor completion runs on a bundled local model. Thread titles and commit subjects use it too. No code is uploaded for any of that.

The network traffic is what you would expect. Your agents talk to their own services. Git talks to your remotes. Palisade checks the ACP and MCP registries, and checks for updates. Each update is verified against the project's signing key before it installs.

We do not claim the whole workflow is offline. The agent you choose may call its own cloud. We make that boundary visible instead of hiding it.

Why this shape

The rest of an IDE is still here: editor, terminals, git, preview, run and debug, notebooks, databases, MCP. You will need it when you take the keyboard back.

But it sits behind the fleet and the review lane, on purpose. The job has changed. More of it is supervising agents and deciding what to merge.

That decision should rest on something firmer than a paragraph of prose. It should rest on a command that passed, at a commit you can name.

Merge on evidence.