Your Standup Is a Search Query

There’s a whole joke genre about three people walking into a bar. Tech runs its own version every morning: three engineers unmute for standup.

“Yesterday, I finally got the new service working with staging auth.”

“Same.”

“Great. Can one of you help me with staging auth after this?”

All three tickets will close by Friday.

The problem comes with the last line. Your team already contains the skills it needs next, but they’re scattered across individual sessions. If you’re solving the same problem three times, you’re missing team capability.

Three closed tickets can hide one unsolved problem

When every ticket in that standup closes and every engineer ships, velocity looks healthy, sprint review goes fine, and each of those three engineers ends the week feeling productive, because each of them was. The waste lives in the space between them, and nothing on your dashboard measures that space.

That’s what makes this pain so slippery. Duplicated work almost never announces itself, and, in reality, can feel like progress. Meanwhile the organization paid three times for staging auth and still has no agreed way to do the work. Next month a fourth engineer will hit the same wall, start from zero, and her week will look productive too.

If you lead a team, sit with that for a second. The metric you watch says things are fine. The cost you’re actually paying is invisible in it.

AI made starting over feel free

This problem is old, but agents gave it a new disguise. An engineer who hits an already-solved problem no longer has to interrupt a teammate or dig through the wiki. They can ask an agent to rediscover the answer, get something plausible, and keep moving. It feels like leverage. It hides the duplication without removing its cost.

The bill shows up later, in places that are hard to trace back to the source:

• Several incompatible solutions to the same problem, each one now load-bearing.
• Review cycles that quietly relitigate decisions the team already made somewhere else.
• Subtle differences in security and reliability between implementations that were supposed to be the same thing.
• Engineers still interrupting the one person who “really knows” to confirm what the agent told them.
• And when one person finds a better approach, nothing carries it to anyone else.

Cheap rediscovery is the part most teams haven’t priced in yet. The old friction of asking around was annoying, but it was also a crude deduplication system: someone would eventually say “oh, Sam solved that in March.” A general-purpose agent usually can’t say that, because it can’t see Sam’s session. So it does what it can see how to do: it solves the problem again, slightly differently. Agents don’t intrinsically fail at reuse. The team’s prior work is simply absent from the context the agent can reach.

Repetition surfaces in conversation before it surfaces anywhere else

You don’t need a sophisticated detection system to spot this. You already run one. It meets every morning.

Think about the joke. The detection already happened inside it: three people, one problem, out loud, in the same fifteen minutes. Repeated work makes its first public appearance in Linear tickets, issues, standups, retros, and engineering syncs, usually as a complaint, an aside, or a laugh line that lands a little too well. Someone in the room only has to recognize it: wait, haven’t we solved this already?

This is the reframe I want you to leave with: standup has a second job. It’s the detection layer for patterns hidden inside individual AI-assisted work. It catches what documentation never could, because documentation depends on someone recognizing, in the moment, that a solution will matter later. Standup catches several people discovering that it already mattered more than once.

Detection has a limit, though. Nobody in the meeting remembers exactly what they tried, and the person who solved it cleanly has probably already forgotten which step mattered. The conversation tells you a pattern might exist. It can’t tell you what the pattern is. So the method has three moves:

• 01.Detection. The meeting notices the pattern.
• 02.Investigation. Search the team’s captured sessions to see whether the pattern is real and what people actually tried.
• 03.Decision. A person decides how the team should do this work going forward, and a skill carries that decision into future sessions.

Treat the standup complaint as a search query

Investigation is where captured sessions earn their keep: the sentence someone says in a meeting becomes a query against what the team actually did.

Back to our standup. Nothing here is a real transcript; it’s the shape these situations take. Someone in the room remembers hearing the staging-auth complaint two weeks ago too. Take the sentence, almost verbatim, and run it:

paperctl search "new service staging auth"

Suppose the results come back the way these searches tend to: one engineer solved it manually, another found an undocumented permission that made everything work, a third wrote a temporary script, and two attempts failed at the same step. None of that was visible from ticket titles. All of it was sitting in session history.

That’s the whole investigation step. Search tells you whether the pattern is real and what it looks like across the team. What it can’t tell you is whether this deserves to become a skill. That’s a decision, and it has criteria.

Not every repeated task earns a skill

A good candidate has four qualities:

1. It repeats across people. One unusual project hitting the same task over and over doesn’t count.
2. Re-solving it carries a real cost: time, risk, interruptions, or inconsistency.
3. The successful approaches share a stable core.
4. Someone can review and maintain the result.

Skip these checks and you risk turning a temporary workaround into permanent doctrine. That’s the slightly terrifying version of “move fast.”

A useful trigger is the second independent mention. Once two people describe substantially the same friction, search before a third person solves it again.

A skill is a reviewed team decision, and someone has to make it

Saving one person’s transcript preserves one person’s solution, local quirks included. The reason to generate a skill from several sessions at once is that the comparison is where the insight lives: what every successful attempt had in common, which steps were environment-specific, where people made different tradeoffs, and which failure modes the final version should anticipate. I’ve made the case for generating skills from captured sessions before; this is the team-scale version of that bet.

Concretely, maybe every successful staging-auth session required the same undocumented permission, while the scripts and configuration commands varied by service. The permission belongs in the skill. The project-specific commands may not. That call is what separates a generated skill from a session summary.

A person reviews the skill, trims the project-specific steps, keeps the stable core, and puts their name on it as owner. Then it gets announced in the same meeting where the repetition surfaced. The message is “we’ve solved this enough times, and this is now our shared starting point.”

The payoff arrives quietly. The fourth engineer, the one who was about to lose a day to staging auth next month, starts with the team’s reviewed answer instead of a blank conversation.

Watch for the signal to come back

Skills age. If the same complaint resurfaces in standup after the skill exists, one of three things is true: people can’t find the skill, the skill is incomplete, or the underlying system changed. Each one has a fix, and each one announces itself in conversation, where detection lives. The loop closes where it started.

Detection in the meeting, investigation across captured sessions, a decision carried forward as a skill. Check out our roll-out playbook for a step by step path to building your teams’ skill library, and Brian’s write-up for a single extracted skill end to end.

Your team’s version of this probably has nothing to do with staging auth, but you’ll recognize its shape. Think about the last complaint that appeared in more than one standup or retro. Search the sentence your engineers actually used. If the results show several people independently solving the same class of problem, don’t ask the next engineer to solve it better. Decide what the team should carry forward.