Stop Briefing a Brilliant Stranger

The Missing Layer

The realization did not arrive during some dramatic breakthrough. It arrived the way operational bottlenecks usually do, quietly, in the middle of an otherwise productive week.

In late 2025, I had asked an AI tool –- Claude Opus 4.5 to be exact –- to help me structure an approach for a consulting engagement. The answer was excellent; not just superficially polished, but genuinely useful. It laid out a sequence of initial steps that clarified the work and gave me momentum. I acted on the first step immediately, the kind of start that makes the path ahead feel manageable.

The next day, when I sat down to move forward on the engagement, the weakness became clear. The plan was still buried in the prior day’s chat thread, never exported, never saved. To regain my footing, I had to first remember that a plan existed, then find the conversation, and reinsert myself into the logic of a session that was already receding. The AI remembered nothing; that much I had anticipated. What I had not fully reckoned with was the subtler burden, in that it fell entirely on me to remember that a plan worth retrieving even existed.

The model had been insightful. The interaction had been amnesic.

That was the moment the pattern broke for me. I was using a powerful AI model, yet carrying the continuity myself -- remembering decisions, prior attempts, tradeoffs, and what had changed since yesterday. The model could reason well within a session, but between sessions, the cognitive burden fell back to me. Not because the model had forgotten, but because the context lived only in my head. There was no persistent artifact to draw on, only what I reconstructed and retyped into each new prompt. The limiting factor in AI effectiveness, I realized, was no longer model intelligence. Rather, it was the absence of context architecture surrounding the model.

Most knowledge workers still use AI this way. We treat them as brilliant strangers we brief from scratch each time, perhaps aided by a few standing custom instructions (the brief profiles and preferences that some AI platforms allow you to store) and a short “About You” section. Even the more sophisticated features now appearing, such as project workspaces, persistent memory, and shared document uploads, reduce the friction of this briefing without eliminating the underlying structural gap. They make it easier to persist information, but they do not, in themselves, structure priorities, enforce continuity, or maintain the state of an evolving professional engagement. There is real value in that model. Yet after sustained use, a ceiling appears. The next stage is not simply “better prompting,” but is a different architecture of collaboration altogether, which includes changes to the human workflow.

Over the past months, I have been experimenting with that different approach. I’ve used AI not as a sequence of isolated interactions, but as a sustained operating partner, closer in function to a longitudinal chief of staff. This framing is functional rather than literal. The system remains a statistical model, but its behavior changes materially when supplied with persistent, structured context. It is not a substitute for a sentient colleague, but rather it establishes a working pattern whose lessons are model-agnostic, arising from something more durable than any vendor release. More specifically, what happens when a human invests in building the shared context that allows a capable AI system to compound rather than merely respond? To understand why this matters, it helps to examine the limits of episodic use.

The Episodic Plateau

It’s worth being clear about what “good episodic use” already delivers, because the baseline isn’t trivial. Used well, AI is already effective for drafting, summarization, research support, synthesis, coding assistance, brainstorming, critique, and scenario exploration. A single session can produce an answer that would have taken far longer to develop unaided, and for discrete problems, this is often enough. But over time, three structural limitations became increasingly hard for me to ignore.

The first challenge is a “context reconstruction tax.” To assist a complex professional life with multiple concurrent threads -- a consulting pipeline, a publishing agenda, a deliberate effort to re-engage a professional network -- the briefings themselves become the bottleneck. The cost isn’t merely the minutes spent typing background paragraphs, but also the cognitive effort of deciding what matters, what changed, what dependencies are still active, and which prior conversations should shape the current answer.

The second limitation is “insight fragmentation.” Episodic sessions produce useful outputs, but the analysis from one session does not naturally accumulate into judgment in the next. The system that helped you frame a negotiation on Tuesday does not automatically recognize the political implications of Thursday’s related email draft.

The third issue is “identity discontinuity.” In episodic mode, the system never calibrates to your strategic priorities, your recurring blind spots, or the difference between what you say is important and what your behavior reveals. It may pick up fragments of history, but fragments do not produce judgment. These aren’t failures of the technology, but instead are the predictable consequences of using a sophisticated system in a structurally shallow way.

Of course, for short-lived or low-complexity tasks, episodic use remains an efficient model. But my goal was to optimize the long-term, high-complexity tasks that occupy much of our professional and personal lives.

From Transaction to Partnership

As an API user of GPT-3 before the release of ChatGPT, I had long known that these models became dramatically more useful when given durable context rather than merely immediate instructions. Neither my frustration nor my solution arrived all at once. My recent evolution began simply enough -- I started uploading my to-do lists to a model and asking it to help plan my day. But this led to broader questions about prioritization and strategic impact, so increasingly, I found myself telling the model my priorities and ensuring that these schedules fulfilled my primary goals. The key insight was that the binding constraint on AI usefulness was not the model’s intelligence in the abstract. Rather, it was that I had not built nor maintained the shared infrastructure that made continuity possible.

This is the essence of a longitudinal AI operating partnership. It’s a working arrangement in which the human and the system share a structured, evolving body of context that persists across sessions. The goal is to make the AI contextually situated enough to function less like a search engine and more like a knowledgeable colleague who was in last week’s meeting, remembers the unresolved issues, and knows why a superficially reasonable suggestion is actually a poor fit for your circumstances.

Once that shift occurs, the optimization target changes. You still want the best answer in a session, but now you’re also optimizing for cumulative value over weeks and months. You design for continuity and preservation of rationale, and you name your active workstreams, record decisions, and expose constraints. You let the system accumulate operating context rather than repeatedly infer it from fragments, helping you over the long term.

The Infrastructure that Makes it Work

A sustained AI partnership -- a term which will make my wife shiver -- doesn’t emerge from good intentions and an off-the-shelf model. It emerges from deliberate context architecture. Human colleagues absorb context through repeated interaction, tone, and shared experience. AI systems do not. If you want depth, you have to make context explicit.

Many technical approaches exist, including vector databases, knowledge graphs, and RAG pipelines. But believing that getting more out of AI shouldn’t require an elaborate project, I chose a simpler path, comprising three lightweight artifacts that impose structure without requiring undue burden. These are the Strategic Context Document, the Master Action Tracker, and Context Transfer Documents. Individually, none of these artifacts are novel -- structured context, action tracking, and state transfer are familiar patterns in software engineering and project management alike. What changes the equation is their integration into a daily operating discipline where the AI actively interprets, updates, and operationalizes them across sessions. Software engineers building agentic AI systems have arrived at similar patterns -- context windows, persistent scaffolding, structured memory -- to maintain coherent behavior across long-running operations. The knowledge-worker version of this problem is structurally the same; the artifacts are just shaped differently. Each of these documents serves a distinct role.

The Strategic Context Document is the slow-changing layer that defines what you are trying to accomplish and how you make decisions. It captures priorities, constraints, accepted tradeoffs, and operating principles. In effect, it is the constitution of the partnership: not just what you are doing, but why. Without it, the model produces locally intelligent but globally misaligned suggestions. With it, outputs are filtered through a consistent strategic lens.

This document also encodes behavioral context that a human colleague would learn over time, including communication preferences, decision patterns, and recurring failure modes. In my case, this includes networking instructions like “peer-level framing, never supplicant,” and to-do list maxims like, “if a task slips twice, ask what the resistance is.” Writing these down had a secondary effect – it forced me to articulate principles I had been applying inconsistently. The AI benefits from that clarity, and so do I.

This document is short -- roughly four pages -- but it anchors everything that follows. Once your priorities and constraints are explicit, drift becomes easier to detect. The system can reflect your own stated priorities back to you when your behavior diverges from them.

The Master Action Tracker is the operational layer, a living record of workstreams, commitments, dependencies, and next steps. Its core rule is simple, in that nothing disappears without an explicit decision. Items can be completed, deferred, or dropped, but each state change is recorded. This constraint changes behavior. Tasks that vanish from a notebook are easy to rationalize away, but tasks that remain visible and unresolved exert pressure. Over time, this shifts accountability from motivation to structure.

The AI maintains this document based on our interactions, and I update it briefly at the end of each day. The overhead is minimal -- a few minutes -- but it replaces a far more expensive activity, that of reconstructing state across fragmented sessions. In practice, the value is not in tracking itself, but in what tracking reveals. When a small task slips repeatedly, the system can surface the pattern and force a decision. Without persistence, those moments disappear. With it, they accumulate into behavioral insight.

To offer a concrete example of this system’s value, consider an item on my tracker, from a consulting engagement. A deliverable had been transmitted to the client on schedule, but a follow-on scope proposal -- time-sensitive, given the client’s decision window -- had been queued for three days without movement. The tracker flagged it once, and I noted it. It flagged it a second time, and the system asked the question I’d built into the operating principles: this has slipped twice; what is the resistance? The honest answer was that I was uncertain how the client would receive a new proposal before they’d fully digested the first deliverable. That uncertainty was real, but it was also a decision -- one I hadn’t made explicitly. The proposal went out the following morning with a brief framing note. The client responded within hours. The slip wasn’t laziness, but was an unresolved judgment call that the system forced into the open.

This document may also include a decision log, capturing not just what was decided, but why, what tradeoffs were acknowledged, and what would cause reconsideration. Over months, this becomes an unusually sharp mirror. Patterns that are hard to see in the flow of day-to-day execution begin to stand out, including where we might overvalue optionality, where we defer uncomfortable conversations, or where we underinvest in high-leverage but cognitively expensive work.

The third artifact is the Context Transfer Document, used for complex, sustained efforts. It is a compact, AI-generated summary of the current state of a workstream, including what has been established, what remains uncertain, and what changed most recently. Its purpose is simple: to eliminate intellectual re-entry costs. Instead of beginning each session with reconstruction, a new interaction starts from “here is where we left off.”

Because these documents persist, correctness matters. I treat them as living artifacts that require periodic validation, particularly when AI-generated. Over time, each workstream develops its own accumulated context. Multi-stage efforts -- consulting engagements, negotiations, research -- maintain continuity even when interrupted. The system no longer needs to infer state from fragments, because it inherits it directly.

These three artifacts form the infrastructure of a longitudinal AI partnership. One defines strategy, one tracks execution, and one preserves state across sessions. Together, they convert isolated interactions into a continuous system. The result is not merely better answers in a given moment, but compounding effectiveness over time. Of course, in professional settings, these artifacts should be treated as sensitive operational documents, particularly when used with external AI systems. At first glance, this resembles some familiar productivity systems. The difference is that these artifacts are not passive records, but instead are actively interpreted, updated, and operationalized by the AI in each interaction.

For the full article, including artifact examples, operational impacts, and implementation challenges, continuing reading the original piece on Substack here.