The lesson is the same. What you leave out of the frame matters more than what you put in.

I learned it on the Fraser one evening, shooting a long exposure shortly after sunset. The plan was clean: water, a single piling, the horizon line, nothing else. What I got back was the plan plus a coffee cup someone had wedged into the rocks behind me, plus a piece of driftwood I hadn’t even noticed, plus an exposed root in the foreground that drew the eye straight off the frame. The photograph wasn’t bad. It was just busy. I’d put everything in and excluded nothing. Two hours of waiting, ruined by what I forgot to look away from.

Then I cropped. Hard. The piling, the horizon, the texture of the water at thirty seconds of exposure. Suddenly the photograph was about something.

That’s the discipline. Frame what matters. Crop the rest.

These days I run an orchestrated agent pipeline on my engineering work. The shape is simple: a planner ingests the spec and produces the failure scenarios. A tester agent writes one failing test against the first scenario. An implementer writes the smallest diff that turns the test green. A code-reviewer and a security-auditor look at the diff in parallel. Documentation gets written. A PR-reviewer makes the final call.

Every arrow in that pipeline is a frame.

The planner doesn’t see the tester’s old work. The tester sees the plan, not the spec. The implementer sees one failing test, not all of them. The reviewers see a diff, not the conversation that produced it. None of them gets handed everything. Each gets what they need to do their narrow piece of the craft well.

I didn’t design it that way because I read a context-engineering paper. I designed it that way because I’ve been cropping photographs for years, and I knew what happens when you give a competent operator too much information. They include all of it. Pilings, driftwood, coffee cups, roots. The frame becomes about nothing because it’s about everything.

The mechanic in both crafts is the same: decide what the frame is, then cut what doesn’t serve it. In photography you do this twice: in the viewfinder before the shutter, and again in post when you finally see what the sensor caught that you didn’t see standing there. In context engineering you do it three times, maybe four. When you write the system prompt. When you choose what to pass to the next agent. When you decide what the model gets to see in its tool results. When you review the output and notice what the model fixated on that it shouldn’t have.

That last review is the one most people skip. In the pipeline I run, there’s a step borrowed from how I treat my own photographs: every time an agent produces a bad output, I have two deliverables. Fix the immediate problem. Update the upstream agent so it can’t make the same mistake again. The same pattern lives in photography. You don’t just delete the busy frame. You note what got into it, and you stand differently next time.

This isn’t a rule for every situation. There are mornings I shoot wide and loose because I don’t yet know what the shot is, and the only way to find it is to capture the noise and look at it later. There are engineering spikes where I deliberately blow the context wide open and let a model wander through everything, because the goal isn’t the answer. The goal is to see what the model notices. Discipline isn’t dogma. Sometimes the work is the noise.

But for the everyday work (the daily shipping, the daily features, the photographs I actually publish), exclusion is the craft. The shutter and the prompt are the easy parts. What you decide not to include is what makes the result land.

The camera and the model are different tools. They cost different money. They answer to different physics. But standing in front of either one, the question is the same. What stays in the frame? What gets cropped?

After all these years of asking it of light, I keep asking it of language. The discipline doesn’t change.