Could the Cord Pull Itself? Sketching the Hypothesis

My last post, Somebody Has to Come When You Pull the Cord, ended on a hypothesis. Most blockers in a big change never get filed, they get mentioned, and I wondered whether you could build infrastructure that catches them, routes them to the person who has to act, and pushes them up when they sit too long.

I haven't built this. What follows is a sketch of what it would look like if I did, mostly so people who have run real transformation programs can tell me where it breaks.

The hypothesis, stated so it can fail

It's really four claims, and each one has a way to be wrong.

Detection. In a change program with a lot of counterparties, most blockers get said out loud before anyone writes them down, in a standup, a vendor call, a Slack thread, a status email. Agents reading what the program already produces can pick them up with enough precision that people don't learn to ignore them. This is wrong if the triage queue ends up mostly noise.

Routing. A written-down map of who owns which decision and which seam, plus a dumb clock, will shorten time-to-clear more than any amount of model intelligence. This is wrong if response times don't move once blockers are routed.

Diagnosis. The weekly numbers from the last post (pull rate, unblocker concentration, repeat rate, response versus clear time) can tell decision concentration apart from organizational friction, and point to different fixes for each. This is wrong if the numbers come out muddy, or point at the same fix every time.

Trust. With the right governance, people keep talking about blockers even though agents are listening. This is wrong if the pull rate drops after the agents switch on. That would be Van Nuys again, with better software.

The topology

The shape I keep coming back to is a shared board rather than agents chatting with each other. There's one registry, the one cord from the last post, and every agent reads from it or writes to it. Nothing talks to anything else directly, which keeps every step inspectable.

• Scouts, one per source: chat, meeting transcripts, work trackers, email and vendor portals. Their only job is to say "this looks like a blocker" with the quote, a link, who said it, and when. Each one is isolated, so it can't see the registry or the other sources. That keeps it from leaning toward blockers it already knows about, and it keeps each scout's access limited to one system. I wrote about why isolation matters in Strategic Ignorance.
• Human raise. People can still pull the cord themselves with something like a /blocker command. The agents add to the cord, they don't replace it.
• Clerk. Merges duplicates, so the vendor API access issue mentioned in three meetings and one ticket becomes one row with more confidence behind it. It also notices when something sounds resolved and proposes closing it.
• Dispatcher. Tags the type (decision, dependency, access, information, policy), whether it's a one-way or two-way door, how many workstreams are waiting, and who owns it, using a decision-rights map someone has to write down. If nobody owns that seam, the blocker gets flagged as an orphan, and I think the orphans are one of the most useful things this would surface.
• Clock. This one is deliberately not a model. It's plain code: notify the owner, wait out the window, escalate one rung, then drop it into the daily review. Escalation needs to be predictable and auditable, and I don't want a model deciding when to go over someone's head.
• Analyst. Once a week it runs the four numbers and drafts what it thinks they mean. People decide what to do with it.

The life of one blocker

Say someone mentions in a Tuesday standup that the team is still waiting on the integrator for API credentials. The meeting scout picks it up as a candidate with the quote and a link to the transcript. It's the second time this week it's come up, so the clerk merges it with the first mention and confidence goes up. The dispatcher tags it as access, two-way door, blocking two workstreams, and looks up the owner. The integrator relationship turns out to have no named owner on our side, so it's an orphan, and the program lead gets asked to assign one. Once it's assigned, the owner is notified and the clock starts. If it isn't cleared in 48 hours it moves up a rung, and if it's still stuck after that it shows up in the daily 15-minute unblock with everything attached.

Nobody had to file anything, and nobody had to decide whether it was worth bothering someone senior about.

Where it gets uncomfortable

An agent that reads every meeting can feel like surveillance, and that's the failure mode I'd worry about most. If people think what they say in a standup will be used against them, they'll stop saying it, and the whole thing goes quiet. A few rules I'd treat as non-negotiable:

• Every blocker has its own visibility. A blocker about a vendor is never visible to that vendor, and a team's internal blockers stay with that team until they escalate.
• Every row carries the quote and link it came from. No blocker without provenance.
• It counts blockers raised. It never scores the people who are slow to clear them, and reports are about seams and categories, not individuals.
• Low-confidence finds go to a person before anyone gets notified.
• Every route, notification and escalation is logged.
• People can raise things privately.

Provenance, per-row visibility and an audit trail are the same problems I work on with ContextNest, so this is the part I have the strongest opinions about. It's also the part most likely to decide whether anyone trusts it.

What I'd build it on

I'd build the registry and the governance layer on ContextNest, the context layer we make at PromptOwl (the ctx CLI and engine are open source, the team server is a commercial product), because most of the hard parts above are things it already does. Here's how I'd map it, including the parts it doesn't do yet.

• The registry is a nest. Each blocker is a versioned Markdown document, tagged with its type, its door, and the seam it sits on. Every change, from opened to routed to escalated to cleared, is a new version in a hash-chained history you can verify later. That also means time-to-first-response and time-to-clear come straight out of the version history instead of a separate tracker.
• Human triage is the review gate. As of ctx 3.0, new vaults hold writes for review by default, so anything a scout writes sits there until a person approves or rejects it. That's the low-confidence queue without building one.
• The decision-rights map is stewardship. On the ContextNest server you can assign stewards per document, per tag, or per nest. Tag a blocker with its seam and the seam's steward is the owner. A seam tag with no steward is an orphan you can query for.
• Notification already exists. Review requests notify stewards through Slack, Teams or a webhook.
• The dispatcher and the analyst read with deterministic selectors, so the same query returns the same set of blockers every time. When the analyst says unblocker concentration went up, you can rerun the query and get the same answer.
• Erasure is built in. If someone asks for a mention to be removed, ctx forget erases that content from every version while the history still verifies, and the erasure itself is logged. Sensitive programs can use an encrypted vault.

What it doesn't do today: there's no clock. Timer-based escalation would live in whatever scheduler runs the agents, and so would the scouts themselves. Visibility is per nest and per steward rather than per row, so in practice I'd split the registry by scope, one nest per team plus a program-level nest that only sees what's been escalated.

What I'd want to learn first

If I ran a first test, it would be small: one organization's own Slack, meeting transcripts and work tracker for a few weeks, with nobody being notified at first, just to see whether the scouts find blockers people agree are real and whether the clerk's merged list looks like what the team would have said if you'd asked them.

The question I'd most like answered is whether the orphans show up. My guess is that in a multi-party change, a big share of what's stuck sits at seams nobody owns, and that nobody can see that from inside any one team. If that's true, the most valuable output might not be faster unblocking at all. It might be a map of the seams that need an owner before the program can move.

The diagrams as Mermaid

If you want to pull these apart or adapt them, here's the source.

flowchart TB
  DET["1 · Detect: one isolated scout per source<br/><small>chat · meetings · work trackers · email and vendor portals</small>"]
  H["Human raise<br/><small>/blocker</small>"]
  C["2 · Clerk<br/><small>dedup, attach evidence, propose close</small>"]
  R[("Blocker registry<br/><b>the one cord</b>")]
  M[["Decision-rights map"]]
  P["3 · Dispatcher<br/><small>type, one/two-way door, blast radius, owner</small>"]
  O["Owner notified"]
  K{{"4 · Clock (code, not a model)<br/><small>48h fixed position</small>"}}
  U["Next rung up"]
  Q["Daily 15-minute unblock<br/><small>humans decide</small>"]
  N["5 · Analyst, weekly<br/><small>pull rate, concentration, repeat rate, response vs clear</small>"]
  G["Governance plane<br/><small>visibility per row, source quote on every row, audit trail, human triage</small>"]
  DET -->|"candidate + quote + link"| C
  C --> R
  H --> R
  R <--> P
  M --> P
  P --> O
  O --> K
  K -->|"not cleared"| U
  U -->|"still stuck"| Q
  R --> N
  N -->|"draft fixes"| Q
  G -.- R
  classDef cord fill:#f6d8a8,stroke:#b07a2a,stroke-width:2px,color:#1d1d1f
  classDef clock fill:#ffffff,stroke:#b07a2a,stroke-width:2px,stroke-dasharray:4 3
  classDef gov fill:#eef1f4,stroke:#7d8b99,color:#1d1d1f
  class R cord
  class K clock
  class G gov

stateDiagram-v2
  state "Daily review" as DailyReview
  [*] --> Candidate: a scout hears it
  [*] --> Open: someone raises it
  Candidate --> Triage: low confidence
  Candidate --> Open: high confidence
  Triage --> Open: a person confirms
  Triage --> [*]: dismissed
  Open --> Routed: owner found
  Open --> Orphan: nobody owns this seam
  Orphan --> Routed: program lead assigns
  Routed --> Cleared: inside the window
  Routed --> Escalated: 48h passes
  Escalated --> Cleared: next rung clears it
  Escalated --> DailyReview: still stuck
  DailyReview --> Cleared
  Cleared --> [*]