What lands two weeks later

Some lessons land in the room. The ones that change how a person works land about two weeks later, alone, usually by accident.

I know this because I went back through every debrief and every transcript from March to last week and read them in order. Not for a survey. For the pattern. What were people asking in spring that they stopped asking by August? What did nobody ask in the room and everybody asked fourteen days later?

Here is what I found.

The lesson worth stealing

A brand consultant with thirty years in his industry did his homework wrong, and it turned into the best teaching moment of the summer.

He wrote a job description in a plain chat window, outside the system we had built together. The draft came back generic, and the model went looking online and found two unrelated companies with a name like his client's. Then he ran the same request inside his configured project. This time it came back with escalation paths and where the role sits in the org.

Same model. Same question. Two different employees. The only difference was everything he had told the project about himself, his client and his standards.

He saw it before I said a word.

You can run the same test in ten minutes. Take one real task. Ask it in a bare chat. Then ask it inside the project you set up for your work. If the two answers look the same, your project does not know enough about you yet, and that is the whole problem in one screen.

How the room has changed since spring

If you sat in a session in March or April, the room looks different now. Three things moved. These are my session notes, not a study.

The first question moved from "which tool" to "where does it live." Nearly half the people I trained in the spring asked which tool to pick. Since August, almost nobody has. The question now is chat, project, desktop app or command line, and it is the most common one in my notes. One director ran a full week with her system asking her things it should have known. Her assistant had been created in the wrong surface, so none of her conversations could see the instructions. Nobody had told her, and it looked like her mistake. That is the failure mode of this season: the tool works, the plumbing is wrong, and it looks like your fault.

Privacy turned inward. Every group since March has asked "will it train on my data." Only the August and September groups asked "can our admin see what I put in." About a third of them, all on company accounts. The question stopped being about the vendor and started being about the org chart.

The proactive ask became a brief that runs at six in the morning. Earlier this year a handful of people asked whether the system could tell them things without being asked. Three out of four people since August left their second session with a scheduled build that does exactly that. The second-week questions on those builds are new ground for everyone, me included: did it fire, did it fire twice, do the notes I typed into it carry over to tomorrow.

The questions people ask after

Not in the session. Two weeks later, by email, or at the top of the next call.

How often do I go back in and update it, and how do I make that part of our process so it actually happens? Next time, can you just be in the room while I build it? I don't trust that I'm doing it right, and this is our pipeline. I spent an afternoon trying to build a skill and could not get it to work.

Every one of those is a maintenance question, and every one lands after use, never during.

People in every group since March hit the same wall once they were on their own. They told the system things in conversation, the project did not change, and they assumed they had broken something. They had not. They had discovered that a chat is a conversation and a project is a system, and that the two do not update each other. Nearly everyone since August asked for more time in some shape. Half left without the skill they wanted built.

The blur nobody is planning for

Ethan Mollick put words to something I keep hearing from senior managers. The jobs inside organizations are blurring. Coding, design, product management, marketing, all collapsing and overlapping as everyone uses AI. His line: very little planning is happening around what to do about this, and we need new models for organizing work, fast.

His team measured it. In a field experiment with 776 professionals at Procter and Gamble, published this summer in Organization Science, individuals working with AI matched the performance of two-person teams working without it. And the AI broke down the functional silos. R&D people produced more commercially minded ideas. Commercial people produced more technical ones. The line between the two jobs moved in a single afternoon.

I see the same blur from the other end, one person at a time. The director whose assistant lived in the wrong surface was doing plumbing work nobody had assigned her. The consultant who ran the test was doing product management on his own job description. The people who left with a six a.m. brief are now running a small operation, with schedules and failure modes, on top of the role they were hired for.

And the questions the teams brought me in August and September were organizing questions wearing training clothes. Who owns the shared instructions. What happens when one person goes off-brand. What stops five copies drifting apart. Nobody in those rooms had a job title that covered any of it.

What this has to do with the 70% Problem

McKinsey's State of AI 2026 came out last month.

That gap between "I am more productive" and "the business can see it" is the 70% Problem, measured by someone with a bigger survey budget than me.

My notes say the gap opens in week two. The room produces a working system. Week two produces the first drift, the first "it stopped working," the first afternoon lost to a skill that would not build, and the first organizing question nobody has a title for. Whoever owns that fortnight owns whether the system survives. Right now, in most organizations, nobody does. That is Mollick's missing plan, seen from inside the room.

What I do differently now

I teach the write-back on purpose. Telling the system something in a chat updates its memory of you, not the project. The loop is: ask for an updated instruction set, copy it, open the project, replace the instructions, save a version. One person lost half a session to this confusion before I made it a named step.

I make the folder decision before the first project exists. One root folder that every project points at, private and shared separated before anyone else is invited. Two people this summer raised orchestration unprompted and both had to be told to wait for exactly this reason.

I name the guardrails at the moment someone connects real data, because that is when the discomfort shows up. Reading is free. Writing and deleting need a yes. Training on your data is off. Said out loud, at the moment of connection, it turns vertigo into a checklist.

And I now think the habit needs a touchpoint after week two, not a line of homework. The room can build the system. Only the second week can teach anyone to keep it.

One thing to do this week

Run the ten-minute test. Bare chat, then your project, same task. If the answers match, your system has fallen behind you. That is a thirty-minute fix, and it is where the work actually is.