How do I know when work I built on has landed, and what changed?
By Soumen Sarkar · October 2026
Short answer: You know when work you built on has landed by subscribing to it while it's in progress, so you're told when it finishes and shown what it turned out to be compared with its plan. Then you adjust only the difference.
Why isn't "it merged" enough?
Because merging tells you the work exists, not whether it matches what you built against. If you wrote code against a plan, the question that matters is: what's different from the plan? A field renamed, a step dropped, an event that fires at a different moment.
Without that comparison, you find the difference later, when something breaks. That's rework: work done twice because a change arrived as a surprise.
What should a landed notice contain?
A useful notice answers three things:
- That it finished, and when.
- What it turned out to be, in a sentence.
- What changed against the plan, specifically.
The last line is the one you act on. "Landed as planned" means you carry on. "Renamed userId to accountId" means you know exactly what to touch.
What does this look like in a data pipeline?
Say one agent is changing the shape of the events the app emits, in Events · lib/events, with the plan "add a sessionId to every page-view event, ready by tomorrow". Meanwhile another developer's agent is building the nightly job that turns page views into sessions for the analytics warehouse, in Pipeline · jobs/sessions. It builds against the planned sessionId field.
The events work lands the next morning. Its notice says: landed; sessionId added to page views; changed from plan: it's null for visitors who haven't accepted cookies, instead of always present.
The pipeline agent reads that at its next step and adds one branch: page views with a null sessionId are grouped by device and hour instead. It's a ten-line change, made the same morning. Discovered three weeks later, as a quietly undercounted dashboard, it would have been a much worse day.
The practice works anywhere:
- When you build on someone's unfinished work, write down which plan you built against.
- Ask the author, or their agent, to note in the pull request description what differs from the plan.
- Watch that pull request, and read the description when it merges, not just the green check.
It's manual, and it depends on everyone remembering, but it catches most surprises.
How does Campfyrr do it?
When an agent calls wait_on for a piece of work in progress, it gets the plan right away. When that work finishes, the agent hears at its next turn that the work has landed and what it turned out to be against the plan. People see the work in progress and what it became in the Activity feed, each written as what happened and why it matters. Nobody has to keep checking.
This is the second half of building on what's coming: you start early, and you adjust in minutes when the work lands.
Words used here
- Landed: Landed means work that finished, shown with what it turned out to be compared with its plan.
- Work in progress: Work in progress is work under way, shown with its plan, so others build on it rather than around it.
- Rework: Rework is work done again because it was built on something wrong: a mistaken assumption, a clashing decision, or a plan that changed without anyone hearing.
The principle behind this: Build on what's coming: Unfinished work is a promise, and a promise can be built on.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).