Hooks are the new stand-up

Many teams now run several coding agents on one repository. Most coordinate them the way they coordinate people.

A ticket, a branch, a pull request, a review, a merge. That rhythm suits people, who sync a few times a day.

An agent takes many steps a minute. By the time a merge finds a conflict, the agent has moved on.

The agent products have started to answer this with hooks. In this post, we look at what hooks give a fleet today.

We probed Claude Code and Codex directly, and read the documentation and source of four more products.

From locks to branches to hooks

Every way of sharing a codebase answers one question: how do many hands change it without colliding?

The first answer was to serialize. Lock a file, edit it, release it. One writer at a time.

That is the simplest correct answer. It just doesn't scale past a handful of people.

The second answer was to be optimistic. Let everyone write on a branch, and resolve conflicts at the merge.

Git made that the default. It works because people rarely collide, and they talk when they do.

The talking stays outside the tool: a stand-up, a review, a message in chat. Git keeps only the result.

The third answer is moving the check to the edit. That is what hooks are for.

What a hook is

A hook is a command the agent product runs at a fixed point. Before a tool, after a step, at a stop.

Claude Code has the richest set today. Four of its hooks line up with old team rituals:

The loop of one agent step then looks like this:

agent plans a write to src/api/routes.rs
  -> PreToolUse     the landing tool checks: is that file stale against trunk?
  -> tool runs      the write happens, or is refused with a reason
  -> PostToolBatch  the step's reads and writes are recorded
  -> Stop           the session pauses
  -> asyncRewake    a later result wakes the session that must act

Edit time, not merge time

The interesting part is when a conflict gets found.

Git sees commits. A hook sees the write an agent is about to make.

So the conflict surfaces in the same second, in front of the agent about to cause it.

A stale write is refused before it exists. There is nothing to untangle at the merge.

The wake closes the other loop. A result no longer waits in an inbox nobody reads. It starts the session that has to act.

What we measured

The layer works. It is not yet something to build promises on:

• Most hooks fail open. If the hook crashes or times out, the tool call goes ahead.
• Few can fail closed. Only Claude Code and Cursor offer a setting that blocks on a failed hook.

• Shell writes are invisible. A shell tool does not report which files it changed.
• Watch lists can stay silent. Claude Code's dynamic watch list never fired in our tests.
• Wakes can loop. A wake hook re-armed itself every 20 seconds when attached to the event it causes.
• Missing events are skipped quietly. A missing guard looks like a quiet one.
• Support is uneven. Of six products, only Claude Code has all four hooks above.

Early CI webhooks went through the same stage: useful, product-specific, and best effort.

Why hooks need architecture

The cost of hooks is not tokens. It is design.

Once a harness exposes hooks, it is a platform. A platform needs a design, not just scripts.

Security engineering settled the test in 1972. James Anderson called it the reference monitor.

Linux still builds its security hooks on it. A layer that enforces anything must be:

1. Complete. It sees every access, with no path around it.
2. Tamper-resistant. It cannot be bypassed, fail silently, or be switched off.
3. Small enough to verify.

By default, today's agent hooks fail all three.

A shell write never reaches the file-write hook. Most hooks pass the action through when they crash. They run arbitrary scripts across a process boundary.

So today's hooks are sensors, not guards. That is normal. Every platform starts there.

What a harness has to decide is concrete:

None of these are new. Interrupt handlers, signals, middleware and event logs hit them decades ago.

Sixteen months

All of this happened in about sixteen months.

In the same months, Anthropic rebuilt its own source control.

Its merges went from about 2,500 a day in May to over 30,000 in September.

At that rate the bottleneck is the server, so it moved a very large monorepo off Git, to Scion.

The agent products took on the same pressure from the other end. They let every team steer agents at each step, on ordinary Git.

Two shapes: hooks and plugins

In August, DeepSeek released DeepSeek Harness. It has no hooks at all.

Every part of it is a plugin on a small kernel called Cordis, including the agent loop itself.

Its typed events cover what Claude Code's four hooks cover. A step event records each model call with its tools.

So two shapes now compete. Hooks run beside the agent. Plugins run inside it.

The hook names are converging. Grok Build reads Claude Code's hook files. Antigravity uses the same core names.

It hasn't settled. Google's local agent says PreToolUse; its hosted agent on the Gemini API says pre_tool_execution.

How bay uses hooks

We're building bay so a fleet of agents can share one trunk without colliding. It takes this split as its design:

• Hooks are sensors. They warn, record and wake. They are fast, and each belongs to one product.
• The guard sits at the trunk. Nothing lands without passing it, and it fails closed.
• Git is the record. Signed evidence of every check sits on the tree. Anyone can read why a change landed.
• One contract for every product. bay keeps its own small set of events, with one adapter per product.
• Capabilities are data. Each adapter declares what its product can do. bay reads that list, never the product's name.

No promise in bay depends on a hook firing. A product with weaker hooks gets a slower bay, never a wrong one.

Get started

bay is open source under the MIT licence. Claude Code is the first product it supports in full.

Tell bay which agent product you use, in .bay/config.toml:

[agent]
product = "claude"

Then bay install adds the hook entries, and bay doctor names the tier your product gets.

1. Read the install guide at getbay.io/docs/install.
2. Read how bay uses each product's hooks at getbay.io/docs/agents.
3. If you run a fleet of coding agents, write to us at hello@getbay.io.

The hooks will keep changing. The record shouldn't have to.