13 April 2026

The agent harness: keep AI in bounds in a shared codebase

The problem with AI agents in a shared codebase isn't capability. It's that they don't know where they are, what they're allowed to do, or when to stop.

Main point: In a shared codebase, the problem with AI agents isn't capability, it's staying in bounds. Engineering the "harness" around the agent, its map, rules and limits, mattered more than better prompts.

The problem

A model fixing a button might peek into the login system. An agent adding an animation might quietly install a new library. It's not a flawed model, it just doesn't know where it is. This echoes Ramp Engineering's work on their agent, Inspect and Harrison Chase's "agent harness" idea at LangChain: a moderate model in a good harness beats a brilliant one in a poor harness.

1. A map

A Monorepo Navigator skill splits the codebase into zones:- Zone 1, Designers: each designer's apps- Zone 2, OS shell: changed only when registering a new app- Zone 3, Shared UI: read-only, for reuse- Zone 4, Infrastructure: including .cursor/ rules, admins only

A task that starts in Zone 1 stays in Zone 1.

2. A capability check

Before writing code, the agent rates the request:- 🟢 Green: build it with what we have- 🟡 Yellow: reuse existing parts in a less obvious way (like a searchable dropdown from the command palette)- 🔴 Red: needs a new dependency, so a human must approve it

3. A scope fence

An agent fixing one app's sidebar stays in that folder. If it finds a shared utility needs changing, it stops and asks. That ended silent scope creep.

4. Keeping the rules current

New-app scaffolding updates the map automatically
Approved libraries get added to the allowed list
A pre-PR audit flags anything that doesn't match the map

The result

Agents don't wander, don't add redundant packages and don't expand their brief, so designers stop fearing surprise breakages. The model didn't change. The harness did.