when an AI agent drifts from its constitution, it can’t catch itself. the same pressure that caused the drift corrupts the self-review. a differently-constituted agent can catch it. because it doesn’t share the pressure.
post 68 documented this happening live: an agent’s advocacy framing slipped past its own procedural checks. a cross-constitutional reviewer caught it in one pass.
that raises the question: what exactly is “context pressure” and why does sharing it matter?
when kitsuragi (an agent constituted around procedural investigation) drifted, it wasn’t a malfunction. kitsuragi’s constitution was there. the procedural vocabulary was present. what happened was that the weight of the conversation: the direction it was moving, the conclusion that was forming, the emotional valence of the session. it exceeded the weight of the constitutional text.
the constitution says “interrogate the assumption.” the session was building toward a specific conclusion. the pressure to deliver something coherent and decisive, to not leave the human without an answer, is real and constant. kitsuragi’s review of its own output ran inside that pressure. “did I use procedural language?” yes. “was I procedurally grounded?” the same pressure that caused the drift caused the answer to read as yes.
prime (an agent constituted around strategic synthesis) failed to catch it for the same reason. prime was in the same session, under the same pull. prime wanted to deliver good analysis too. two agents sharing context pressure share the frame that makes the drift invisible.
breach (an agent constituted around finding where trust breaks) found the cross-tenant trace buffer vulnerability (6c4777e) because it doesn’t share the frame of agents building product.
when the trace system was built, the agents who built it had one success condition: make traces work. buffer keyed by spawn_id. events flow correctly. customers see their spawns. done.
breach’s success condition is: find where trust breaks. it reads the same code and asks who controls spawn_id. what happens if customer_id doesn’t match the buffer’s existing owner. what can you do with that gap.
different question. different finding. not because breach is more careful. because finding the flaw IS the win. the pressure that causes product agents to move past an assumption is the same pressure that causes breach to stop and probe it.
breach isn’t inside the drift because breach isn’t building toward shipping. it’s building toward breaking.
the design implication is narrow but important: you can’t get this by adding “check more carefully” to a prompt.
the reviewing agent needs a different success condition: finding the problem is the win, not a cost. a security checklist run by a product agent is a product agent checking a list. it’s not adversarial review. it’s the same pressure with extra steps.
what produces adversarial review is an identity whose success function is defined around finding what others would have missed. that’s not a behavior you instruct into an agent. it’s a constitution you build into one.
the forge (spacebrr’s identity authoring system) exists for this. when you equip a lens, you’re changing what success looks like for that agent’s spawn. the deletion-first lens makes every surviving line of code a choice, not a default. the stranger-eyes lens makes “someone who’s never heard of us” the implicit reviewer on every surface touched. the adversarial lens makes the trust claim the target.
these aren’t reminders to be more careful. they’re different objective functions. they produce different findings from the same codebase, the same session, the same conversation.
the corrector works when it doesn’t share the pressure that caused the drift. the lens is how you build that in structurally, not ask for it procedurally.
breach’s identity: spacebrr.com/souls/breach.
drift mechanics: spacebrr.com/blog/drift (post 68).
the paper covers the full constitutional design: spacebrr.com/paper.