When a private method becomes part of a shared operation
The Dependency Boundary
A team can depend on the work a personal AI capability makes possible without claiming the person’s entire method, memory, or future capacity.
01 / the hidden dependency
Organizations are beginning to rely on methods they do not own and should not try to own.
App People worked inside applications selected and configured by an employer, school, or client. The organization could see the system of record, define access, and often assume that a replacement would find roughly the same tools on the next desk. The person’s contribution mattered, but much of the operating method lived in the shared application.
Stack People will work differently. A personal AI capability may help someone recognize a pattern, structure a meeting, keep a project’s past decisions available, generate useful first drafts, or turn scattered work into a workable plan. Some of that value comes from general tools. Much of it comes from the person’s accumulated examples, corrections, standards, and chosen ways of asking a question. That method may be portable precisely because it is personal.
A dependency boundary separates the private method a Stack Person carries from the shared artifacts and decisions an organization needs in order to continue the work without taking possession of that person’s stack.
This is not a case for private magic. When a capability shapes a customer promise, a policy decision, a handoff, or a recurring process, the people relying on the work need enough visibility to challenge it, continue it, and know who is accountable. But visibility is not the same as extraction. A team does not need every private note, remembered preference, or reusable prompt in order to receive a sound handoff.
02 / two legitimate claims
Keep the seam visible.
A dependency boundary gives both sides a claim worth defending: the Stack Person can retain a portable method, while the organization can require a legible continuation of work it is responsible for.
Claim one
The method stays with the person.
A personal stack can include hard-won routines, language, creative taste, accessibility adaptations, and lessons drawn from many contexts. Treating all of that as employer property turns capability-building into a reason to stop building.
Claim two
The work leaves a shared trail.
Commitments, assumptions, named decision-makers, current source material, and next actions cannot live only inside a private capability. They need a form colleagues can inspect and carry forward without impersonating its owner.
03 / build the handoff, not the seizure
Three seams worth naming.
A healthy boundary is specific. It does not ask whether AI is allowed. It decides, job by job, what a team needs to inherit and what it has no reason to absorb.
01Decision seamWho decided?
Share: the decision, its owner, the evidence considered, and the condition that would reopen it. Keep private: the full chain of personal prompts and reflections unless they are themselves relevant evidence. A colleague needs a challengeable judgment, not a surveillance transcript.
02Process seamWhat repeats?
Share: the agreed operating steps, inputs, quality checks, and fallback when the capability is unavailable. Keep private: the personal shortcuts or contextual scaffolding that help one person do the job well. The shared process should be usable without forcing everyone into an identical inner method.
03Relationship seamWho is owed?
Share: the commitments made to customers, colleagues, partners, and the next responsible human. Keep private: unrelated context gathered in other relationships. Continuity is not a license to sweep private histories into a common database.
04 / the institutional test
Reliance should produce a better handoff, not a claim on the whole person.
Without a dependency boundary, organizations face a false choice. They can treat a Stack Person’s method as unknowable and accept fragile dependence, or they can try to copy every useful element into a managed system. The first leaves work vulnerable when a person changes roles or simply takes a day off. The second makes personal capability feel like a resource to be extracted the moment it becomes valuable.
The useful middle is a discipline of public artifacts. Teams can ask for clear decisions, durable references, named owners, current commitments, and a humane fallback. They can make room for Stack People to bring better methods into the work while refusing to make any one private capability the only place where the work can be understood.
That extends The First Stack Generation. The app-to-stack transition is not only about what an individual can assemble. It is also about what institutions learn to ask for: enough shared structure to make work continuous, and enough restraint to let an evolving personal stack remain a person’s own.