cankun.me

Deposition: Shared Understanding for More Autonomous Work

Sep 19, 2026
A shipwright checks a curved timber against a thin template, with a visible gap between them
A shipwright checks a curved timber against a thin template, with a visible gap between them · View full resolution

With GPT-6 Astra, I want to delegate more work to the model. It can investigate code, try approaches, implement changes, and check its results. I want to spend my attention on purpose, consequential tradeoffs, and the quality of the deliverable, while leaving room for methods I would not have thought of.

Delegation first requires some understanding of whether we mean the same thing. A model can diligently complete a request, produce a substantial artifact, and pass its checks. Only when I read the result do I discover that it organized the work around a different purpose. Sometimes I have failed to express my intention. Sometimes I am still finding a clear way to understand it myself.

deposition is a skill I am developing for this collaboration. It asks the model to build a shared mental model with me: investigate the context, explain its understanding in its own words, contribute judgment I can examine and correct, and test that understanding against the intended use before the work depends on it. The starting point can be an incomplete idea, an existing plan, or an unsatisfactory result. A finished specification is not a prerequisite.

Where human attention becomes useful

OpenAI's skills guidance for GPT-6 Astra recommends reviewing accumulated instructions, reconsidering elaborate recipes, and clarifying decision boundaries and completion. It prompted me to think again about where my instructions should direct the model's attention, and how much of that direction a capable model actually needs.

In the second part of her pstack guide, Lauren calls this “The art of supervising someone smarter than you.” She describes two recurring difficulties: insufficiently expressed intent, and insufficient context for doing the work correctly. She wants to communicate the desired outcome while leaving the model freedom to discover how to achieve it.

Her most useful practice for me is asking the agent to restate the problem in its own words. The restatement compresses a noisy conversation into a structured account of the problem. It lets her catch a misunderstanding before any code is written. And because the agent has not simply adopted her assumptions and hypotheses, it can still reach a view she had not considered. Asking someone more capable to explain their understanding in terms you can follow is how you supervise them.

The two difficulties call for different work. A fact available in the repository calls for inspection. An uncertain behavior may need a small experiment. Purpose, priorities, and acceptable costs require human involvement. Turning every contextual gap into a question makes the user do unnecessary investigation. Treating every unclear intention as an implementation detail lets the model settle the direction too early.

What persistent questioning offers

The version of grill-me I first encountered was short. It asked the model to examine a plan relentlessly, work through dependencies between decisions, ask one question at a time, and supply a recommended answer for each question. Questions answerable by inspecting the code called for inspection. That early version takes very little time to read.

Its appeal was practical. I could start with an incomplete idea and discover omissions through the questions. Focusing on one question at a time also made complex work easier to discuss.

But I sometimes found myself accepting a recommendation, then accepting the next one. Each local choice received confirmation, without necessarily making the overall purpose any clearer to me.

Repeated agreement is not itself a failure. When a model has read the code and can explain a technical recommendation, I want to delegate that judgment. The concern is that the model may also have decided how to frame the question and which alternatives deserve consideration. If those choices depend on an unspoken goal, a sequence of reasonable answers can keep carrying that goal forward.

A recommendation answers a question. It does not show me how the model understands the problem the question belongs to. Deposition moves that understanding to the front, so I can respond to it before I start approving the choices that follow from it.

In the model's own words

A restatement can still be shallow. Suppose I ask for a first presentation on a collaborator's spatial transcriptomics data: basic quality control and a slide deck, no deep biological analysis. The model can reply, “You want basic QC and a slide deck, without deep biological analysis.” That is accurate, and it gives me nothing to examine.

A more useful reply takes a position: “I understand this meeting mainly needs to show the collaborators that we have received and understood their data. The QC metrics are evidence for that, not the organizing center of the talk.” It might be wrong. But it exposes a judgment I can react to. Is the deck organized around metrics, or around the collaborators' understanding of where their data stands? I do not need to know the right slide structure in advance to tell whether this is close to what I meant.

This is what I mean by a shared mental model. The model connects the intended use to the constraints, choices, consequences, and evidence that would establish success, and shows how those relationships shape its judgment. Goals, acceptance, verification, and boundaries all belong in that picture:

  • Goals describe what the result is for: choosing the next experiment, or deciding whether the data justify further investment.
  • Acceptance describes a result fit for that use, which is more than having the expected sections and figures.
  • Verification supplies evidence for particular claims and should say what it leaves open.
  • Boundaries establish where the model can decide and which choices come back for discussion.

In an earlier version of the skill, I listed these four as the things the model should explain. Listing them turned them into a form: the model filled in each field and stopped thinking about what else the task needed. A real task may turn on something none of them names. The better instruction is to build the connected picture and let the particular problem decide what needs to be seen.

Contributing, not only following

GPT-6 Astra follows instructions well. That is useful for execution and limiting for discovery. If the model only makes my stated requirements precise, it cannot help with what I have not yet said.

So I want the model to take intellectual initiative: surface assumptions and tacit judgments that affect the task, bring relevant knowledge, and propose a better framing when it changes what is worth doing. It should explain what the insight would change, ground it in evidence, and keep it distinct from my decisions. Initiative without that discipline turns into novelty for its own sake.

Tacit knowledge needs particular help. Two situations recur for me. Sometimes I have a judgment I have not managed to articulate: I know the slides are wrong but cannot yet say why. Here a candidate expression helps, something I can recognize or reject: “Yes, that is what I meant,” or “close, but the difference is here.” Other times the relevant knowledge is already mine but has not come to mind: I have read an argument that applies, but have not connected it to the current task. Here the model can propose the connection. In both cases, a contrasting example or a short sketch is often easier to respond to than an abstract question.

Neither case lets the model claim to know what I really want. It offers a grounded interpretation; my response decides whether it caught the thing. When a blind spot needs sustained exploration, I use a companion skill, known-unknowns, and bring what it surfaces back into the same shared understanding.

Testing fitness for purpose

A shared mental model can be internally consistent and still miss. The check I trust most is to walk through a plausible use of the proposed result, especially the part we understand least. Could the work satisfy every stated requirement and still fail the person using it?

In the presentation example, agreeing on a workflow of QC, then figures, then slides does not settle what the slides will say. Agreement on the division of work, or on broad categories, does not mean the actual content is aligned. Walking through what the collaborators would see on each slide, and what they should conclude, exposes whether we agree about the deliverable itself.

Writing gives another example. A conversation may already contain design choices, trial results, and references. A model can organize them in the order they arose and produce an accurate development record. A reader encountering the topic for the first time needs a different starting point: what difficulty they recognize, why it matters, what they could do afterward. A short synopsis and outline, with the audience and argument marked as provisional, let me see what would actually be written before the full draft depends on it.

The discussion can close when the shared understanding supports a useful next action and the remaining uncertainty is resolved, delegated, or explicitly bounded. Exploratory work does not require knowing the answer in advance; agreeing on the question and a point to review the findings is enough.

How understanding enables execution

Intellectual initiative is not execution authority. The model can offer a new framing without asking; turning that framing into changed files, a larger scope, or a new deliverable needs applicable authorization.

When I explicitly invoke deposition, I am asking for discussion before the dependent implementation. Once work is authorized, the model should carry it through without seeking permission for every implementation detail. Suppose a button's wording is settled while the page title remains open. The model can change the button and hold the title question. An unresolved issue pauses only the actions that depend on it.

Between those two points lies a small but persistent source of friction: what does “yes” mean? If the model asks whether its interpretation is right and I say yes, I have confirmed an understanding. If it proposes a concrete change within a task I already authorized and I say yes, it should proceed. In practice, models tended either to treat any agreement as permission to start, or to ask again for permission I had already given.

Two things help. The model should make clear whether it is checking an interpretation or proposing an action, and read my reply against that and against the authorization already in force. I can also use two optional signals: agree confirms the understanding without starting new work, and proceed authorizes the settled next action. They are shortcuts, not stages. Ordinary language such as “yes, make those changes” works too, and proceed does not resolve a scope that is still unclear.

During execution, the shared mental model keeps guiding choices. When new evidence changes a consequential premise, the relevant choices are revisited. When I clarify the goal partway through, earlier choices made under the old goal deserve another look, rather than just a new constraint appended to the old plan.

Apply the method to the skill itself

Deposition needs the same scrutiny. A failure should prompt an investigation into whether guidance was missing or ambiguous, whether the model ignored an existing instruction, or whether necessary context never reached the work. Adding a rule after every disappointing result gradually creates a burdensome process.

Investigating real sessions gave answers I would not have guessed. In one tool, the skill's text had been passed to the model truncated at 8,000 characters, so the rules about reusing authorization never arrived; a correctly installed skill is not necessarily a fully read one. In another session the model had the complete text and still asked twice, reading “pause to resolve a disagreement” as “start the approval over.” And in the presentation work, the model kept earlier figure choices after the purpose became clearer, polishing titles instead of reconsidering them. None of these called for more rules. The last one in particular was not about how much I had said; it was about whether the model kept using the understanding we had built.

Following the Astra guidance, I cut the skill to about a third of its former length. The cuts removed generic method tutorials, repeated completeness checklists, and a fixed two-round approval script. An independent review by another model agreed with most of the cuts but pointed out where they had removed real constraints rather than procedure, such as naming each deliverable without saying what it must contain. Those constraints went back in.

Whether the shorter version reduces friction in practice is not something a text review can establish. The evidence I rely on now comes from real use, and I continue to revise the method as I see where it drifts.

Deposition is a standalone skill in my skill collection. The skill instructions and source notes are public. This is the kind of request I want to be able to start with:

Use deposition to help me think this through. I am not yet sure what good would look like. Look into the context, tell me in your own words what you think this is for and what would make it useful, and point out what I might be assuming without saying. Then we will decide the next step.

What I want from the exchange is understanding sufficient for delegation. I keep a grasp of purpose and consequential tradeoffs; the model contributes its judgment to that understanding, then investigates, chooses methods, and completes the execution.

← Back to Writing