Why we start by sitting next to you

01What documentation cannot hold

Every serious team has documentation. Process diagrams map the happy path. Wiki pages list the steps. Onboarding decks name the tools and the owners. None of that is wasted work. It is also not how work actually happens.

The real order of operations lives in the doing. The person who owns a recurring workflow does not follow a diagram the way a machine follows a script. They open a third system first because the second one is unreliable on Monday mornings. They skip a check when the context is already on the screen. They pause for a judgment call that never appears on the flowchart because the flowchart was drawn for the ideal case.

Exceptions are not edge cases in name only. They are the work. A partner assessment that looks clean on paper includes the quiet step where someone decides whether the relationship is worth another hour. A weekly review includes the moment when the owner reorders priorities based on a signal no template captures. A brief that seems linear is often assembled from fragments pulled in a sequence only the expert knows by feel.

Process diagrams smooth those moments into boxes and arrows. Documentation records what people wish the work were. Interviews can get closer, but they still ask people to narrate something they do without narrating. The judgment calls stay half-spoken. The real sequence stays half-remembered. You cannot learn a workflow from its documentation alone, because the documentation is already a translation.

That is why Discovery does not start in a conference room with a blank whiteboard and a stack of SOPs. It starts at the desk of the person who owns the work.

02What shadowing reveals

Shadowing is not theater. We sit with the domain expert and watch the real workflow, every step and every exception, while they do the work they already own. We are not collecting slogans about how the team works. We are watching the path their hands actually take.

What shows up is concrete. Which tools open first. Where context is copied, reformatted, or abandoned. Where an agent helps and where it is ignored. Where a human gate already exists, even if nobody named it that way. Where review happens in a chat thread, a hallway, or not at all. Where the method depends on tribal knowledge that would leave with one person.

Shadowing also reveals what the team already trusts. Some steps are solid and should stay. Some steps are improvisation that still works. Some steps are fragile workarounds the expert has normalized. You only see the difference when you are next to the work, not when you are reading about it.

This is the first half of Discovery: time with the people who hold the method. Interviews and close study of existing tools and practices matter. They sit beside the desk time, not instead of it. The goal is simple. See the real process. Make the invisible sequence legible without flattening the judgment that makes it good.

03One focused two-week loop

We pair with your expert and run one focused loop, start to ship, in two weeks. The unit of improvement is the workflow, not the task. We take one recurring line of work all the way through. This is the same two-week loop described in How it works.

Pair. We work with your domain expert, the person who owns the work. That person is not a stakeholder on the side. They are the co-author. Pairing sets the frame: we are here to learn their method, not to replace them with a template someone else invented.

Shadow. We watch the real workflow, every step and every exception. Notes stay close to the ground. What happened. In what order. Where judgment entered. Where the agent helped. Where the record disappeared into a private chat. Shadowing is how the later playbook earns its shape.

Prioritize. Together, we pick what repeats, matters, and is ready. Not every sequence deserves to become shared infrastructure on day one. Some work is still too unstable. Some work is important but rare. Some work is ready: it already recurs, it already has an owner, and improving it would change how the team operates. Prioritize is a joint decision, not a recommendation dropped from outside.

Build together. We draft the playbook with the expert, not for them. Steps, context, tools, and human gates get written in language the team already uses. Where the method needs a human decision, we put a gate. Where the method needs a durable home, we put it in Constraint as a playbook the team can run, review, and version. The expert remains the authority on whether the draft still sounds like their work.

Validate. Others on the team run it. It has to hold up without its author. If only the original expert can complete the run, the playbook is still a private method wearing a public label. Validation is where the gaps surface: missing context, an unspoken exception, a gate that is too late or too early. Those findings go back into the draft while the two-week window is still open.

Ship. The playbook, its review gates, and its record live in Constraint. A run snapshots the current playbook, moves through its steps, pauses where judgment matters, and records notes and completed steps. When the team learns something later, a new playbook version can become active without changing the version used for an earlier run. Shipping is not a slide. It is the method becoming team infrastructure.

That is the full loop. Pair, Shadow, Prioritize, Build together, Validate, Ship. One workflow. Two weeks. Start to something the team can keep running.

04Build with the expert, not for them

There is a familiar failure mode in process work. Outsiders interview, disappear, and return with a polished artifact the team does not recognize. Adoption fails quietly. People nod in the review meeting and then keep working the old way, because the old way is still the only method that matches reality.

Building with the expert reverses that failure. The playbook is co-authored while the work is still fresh. The expert sees their judgment reflected in the gates. Colleagues who validate the draft can challenge it without fighting an outside document. Trust compounds because the method never leaves the people who own the outcome.

Adoption is not a training slide at the end. It is a property of how the thing was made. When the expert stays in the room through Build together and Validate, the playbook remains theirs. Constraint holds the runs, human gates, and versions. The method stays the team's. That boundary matters. We are not here to extract a process and walk away with it. We are here to make the process runnable by more than one person without diluting what made it good.

The same stance carries into tooling and training. Connecting agents, skills, MCP, and CLIs to the work is practical setup, not a separate product pitch. Fluency grows while the loop is running, because people are driving the stack against real work, not watching a demo of someone else's stack.

05What you hold at the end

At the end of the two weeks, the team is not holding a recommendation deck. It is holding working pieces.

Playbooks with gates. The sequence is written down. Human judgment sits at the steps that need it. The happy path is not the only path encoded. Exceptions that matter are visible enough that the next person does not have to invent them again.

Records. When the playbook runs, the run records its steps, notes, and any required human attestations. The goal is not surveillance. It is inspectability. A team can see what happened, teach from it, and improve the method instead of guessing from chat history.

Versions in Constraint. The playbook can change as the team learns. Each edit creates an immutable version, and the active version can move backward or forward. Improvement becomes a deliberate edit, not a quiet drift in someone's private notes.

And fluency. Discovery blurs into tooling and training on purpose. By the time the playbook ships, the people who will run it have already practiced the stack beside the work. They know how to start a run, where to pause for review, and how to carry a finding back into the next version. The users learn to drive.

The method stays yours. Constraint is where it lives as shared infrastructure: playbooks, runs, human gates, and versions beside the AI tools the team already uses. For the product model behind that distinction, read Inside a working playbook.

The takeaway

Documentation describes work. Shadowing encounters it. Discovery starts at the desk of the person who owns the workflow because that is where the real order of operations, the exceptions, and the judgment calls still live. One focused two-week loop turns that encounter into a playbook the team can run without losing the expert's method.

We build with the expert, not for them. What remains is not a report about how work should happen. It is a playbook with human gates, run records, and versions in Constraint, plus the fluency to keep improving it.

Start with one workflow.