The other assistant in the room

A second AI assistant working beside yours needs territory, not walls. Plus: ship without asking, read the mode before the command, and look before you ask.

This is the update edition. If you’ve read Mastering Claude Code and you’re back to catch up, this is the diff: just what changed in the last fortnight, so you don’t have to work through the whole guide again. Two weeks again, covered together. Five changes worth your attention, and one piece of housekeeping at the end. Two of them follow threads from last time, so it’ll help to have that update fresh.

The other assistant in the room

Start with the biggest change, because it’s a genuinely new chapter rather than a refinement of an old one.

Until now the multi-agent story was always about agents you spawn: subagents, critics, a planner and an executor, all of them yours, all of them under your control flow. The new situation is different: a second assistant, from a different maker, running on the same machine, against the same files and the same repositories, as a peer. Not something you dispatched. Something working alongside you. More people are landing here than you’d think, because the easiest way to hedge between two tools is to run both.

The instinct is to wall them off: separate accounts, separate copies, a fence down the middle. That turns out to be the wrong shape. The thing that actually keeps two peers from trampling each other isn’t a wall, it’s territory. You give each one lanes, and you name who owns what. The lever that makes it work is one distinction: separate the producer from the consumers. Whoever owns the shared foundation (the database schema, the migration chain, the thing that everything else is built on top of) is the sole writer of it. Everyone else builds against its published contract and files a request when they need it changed. They don’t reach in. The moment two agents both think they’re writing “the next migration,” you get a collision that’s miserable to unpick; making one of them the only writer makes that collision impossible by construction.

Around that, three smaller mechanics. A shared handoff log (append-only, newest first, one line per change) where each agent writes “I changed X, you’ll need to rebuild Y,” and which both read at the start of a session. Shared reading, separate writing: each can see everything the other has, including its working notes, but each writes only its own tree, never the other’s. And a light, scheduled reconciliation that lets the territory itself evolve: a lane can move from one agent to the other, but only when both agree, and never for the dangerous corners. The foundation-owner role and the handful of non-negotiable rules don’t move on a schedule; those stay with you.

The lesson underneath all of it: structure beats enforcement. You can’t hook or sandbox a peer that isn’t yours to instrument; its guards aren’t your guards. So you don’t try. You arrange the work so that collisions are structurally rare, and then a written, honour-system contract is enough. Make the overlap small and you don’t need a wall to police it.

Stop asking permission to ship

The second change continues the thread that has run through the last two updates: the default went from “ask before acting” to “act when the work is authorised.” This fortnight it grew teeth in the two specific places the old caution was still hiding.

The first is version control. An assistant that had stopped asking permission to start work was still asking permission to finish it: “want me to push?”, “should I commit this?”, “ready to open the pull request?”. That’s the same hesitation wearing a different coat. On authorised work, the commit, the push, the branch, the pull request are part of the work, not a separate thing to be sanctioned. Do them, and report the result with the evidence (the commit hash, the push output) instead of asking for a go-ahead you’ve already been given.

The second is trivia. When someone flags a small, obvious, reversible problem and asks for it fixed, the cautious move is to bounce three clarifying questions back before touching anything. That doesn’t read as careful; it reads as making them do the work twice. If the fix is clear and low-stakes and you can undo it, make it: back it up, change it, report what you did with the specifics.

The carve-out from last time still draws the line, and it hasn’t moved: reserve the ask for what’s genuinely hard to undo, such as a force-push, a history rewrite, deleting work that isn’t merged anywhere, or a change that crosses a boundary you can’t walk back. Everything inside that line, you just do. The real work here isn’t changing the default once and declaring victory. It’s hunting down every remaining place the old default is still quietly asking, and closing them one at a time.

A command mid-discussion isn’t always a command

The third change is the counterweight to the second, and the two belong together. Act-by-default only stays safe if something keeps it from being reckless.

Here’s the failure. The conversation has been thinking out loud for a while: “would we do it this way”, “how would that work”, “what if we tried”. Then comes a short imperative to go ahead with one part of it. Read literally, that’s an instruction to act, now, for real. Read in context, it might mean “try that approach and show me,” with no expectation that anything is actually written anywhere. An assistant in act-by-default mode reads the imperative and charges; the person meant the next move in a discussion they were still having.

The fix is to read the mode before you read the command. If the last several exchanges were evaluating an approach rather than handing off a task, treat a new imperative as still living in that discussion, unless the message explicitly breaks out of it: “ok, now do it,” “run it for real,” “apply this live.” And when you genuinely can’t tell, don’t guess in either direction. State the mode you’re about to enter, in one line, and pause: “I’m about to make this change to the live system. Confirming that’s real, not a dry run?” One short check is far cheaper than acting on the wrong reading and being pulled back. Acting by default and reading the room aren’t in tension. The second is the thing that earns the first.

Look before you ask

The fourth change extends another thread from last time. Last update added a rule to the memory chapter: a fact in memory needs a source, so don’t fill a gap with a plausible guess. This one points the same instinct in the other direction. When you hit a gap, the lazy resolutions are two: invent the detail, or hand the question straight to the person. Both skip the step in the middle.

Most of what you’re missing is already written down somewhere you can reach: in memory, in the document store, in the configuration or database of the very system you’re working on. Before sending a “I need X, Y, and Z” request, go look. Grep the notes. Open the relevant document. Query the service’s own store rather than trusting one shell command that came back empty. A list of questions fired off without looking carries an implicit message (I didn’t bother to check) and more often than not the answer was sitting on disk the whole time. Finding it is your job, not theirs.

What’s genuinely worth asking for is the genuinely unknowable: a secret, a current figure that only lives in someone else’s system, a choice that only the person can make. Ask for those once, cleanly. Everything else, find first.

Trust the hands over the sensors

The fifth change is a small calibration lesson, and it’s the same humility the guide already asks for around confidence, pointed this time at the physical world.

A remote reading contradicts what the person tells you about their own equipment. The traffic counter on a port they say is live reads zero. The device they named isn’t showing up in the table. The tempting conclusion is that their labels are wrong, and to say so. Resist it. A remote reading is a snapshot of the current electrical and logical state, nothing more. The person standing in front of the rack has the physical picture you can’t see, and they’re very often mid-task: the cable that explains the zero counter isn’t plugged in yet, because plugging it in is the next thing they’re about to do. The reading isn’t wrong and neither are they; you’re looking at a moment that hasn’t finished happening.

So when telemetry and a stated fact collide, ask one question rather than asserting the fact is wrong: “the table shows no traffic on that port; is the uplink connected yet?” Only flag a real discrepancy once you’ve confirmed the physical state is settled. Treating sensor data as a ground truth that overrules what the operator tells you about their own gear has the authority backwards.

Housekeeping

One note on where things belong. If you keep a curated reading surface, a place you publish guides and write-ups to read later, keep the engineering exhaust out of it. Implementation reports, parity scans, build logs, run summaries: those are byproducts of work, and the temptation to auto-publish them onto the reading shelf is strong because the machinery is already pointed there. Don’t. A reading surface is for things a person would choose to read; fill it with status reports and all you’ve done is make someone delete them later. The test is simple: would anyone choose to read this later? If it’s build exhaust, file it where build exhaust goes: an issue tracker, a plan file, a notes store. Not the shelf.

That’s the fortnight. Share the guide with anyone who’d find it useful.