Background

Early in a large architecture investigation, the orchestrating agent consistently flagged certain questions as “needs human judgment.” Domain boundary questions look like they require insider knowledge. But the data and tooling available to the agent were sufficient to resolve them — the agent was anchored to what was local to it, not reaching for what its tools could actually answer. I pushed back on each one. Every time, directed investigation resolved the question from data.

The exchange works in the other direction too. Sometimes I’ll have a felt sense that something is off — a draft that reads wrong, an assumption that doesn’t sit right — and I’ll ask the agent to articulate what the problem might be. The agent’s attempt, even when it misses, gives that sense something to push against. The articulation often crystallizes through the process of correcting the agent’s framing, producing a sharper distinction than either of us started with. This is productive friction.

My earlier training was in a field that rewarded the opposite of decomposition — entering perspectives fully, holding contradictions without resolving them, thinking associatively across domains and letting structure emerge from sustained attention rather than imposing it from outside. Learning to decompose problems as an engineer gave me a second mode, and the flow between sitting with ambiguity and breaking problems down became where the work happened. Understanding accumulates as much through distinguishing as through adding.

The practice came first. The patterns became visible through reflection. The method is the result.