A while back, in a voice chat I was half-listening to, somebody made a claim I have not been able to put down: prompting matters less now that agents can do more work on their own. I did not know the person, and I doubt they meant it as a provocation. But it kept working on me, because my own practice had been moving somewhere I could not yet name. I can name it now. Prompting did not get less important in my work. It changed shape.
The problem that forced the change was not productivity. I work with AI-assisted artifacts constantly: plans, specs, drafts, reviews. Returning to one of those artifacts a week later, the hard part is not its fluency. The hard part is provenance. Which parts came from a source I had approved? Which parts were the model’s interpretation? Did that first-person sentence have any basis in something I actually said? A fluent artifact hides those seams, and I underestimated how expensive it is to reconstruct them after the fact.
Method boundary
How I am reading my own practice
First-person field note (N=1)
- What I am looking at
- One practitioner, one governed agent practice, several months
- Question I am carrying
- What did prompting actually become in this practice, and what is the honest evidence for the change?
- How I am looking
- Stored-contract prompting
- Bounded decomposition
- Delegated sub-agents
- Review gates
- Workbook-shaped revision
- Work I am drawing on
- Internal Hub records: goal-prompt library, decision records, consolidation markers
- The answered shaping workbook for this article
- An internal research brief on prompting and agent workflows
The practice, in pieces
So I rebuilt the practice around contracts instead of messages. The pieces, each in short:
Goal prompts as stored contracts. A goal prompt in my system names the outcome, the sources to read first, the paths the agent owns, the paths it must not touch, the human gates, the stop conditions, and the definition of done. Some target a single artifact; others coordinate twelve or fifteen waves of work across weeks. They have evolved into real documents: five hundred to fifteen hundred lines, broken into discrete sections an agent can navigate. In one week in August 2026, I recorded seventeen of them, most used in some form. This is my first-person account; the itemized list is not included here, so readers should treat the count and execution status as unverified rather than as an independently audited result. A contract library that never fires is just paperwork.
CapturesA stored contract for one bounded run: outcome, sources, owned paths, no-touch paths, human gates, stop conditions, definition of done.Potential request effectThe agent executes inside the contract instead of interpreting a message.Does not establishA contract that is too big drifts; a contract never exercised is paperwork.Numbered, bounded seams. I like large, arbitrary-feeling numbers of bounded seams: prompt an agent to surface twenty-five ideas, or fifty reflection questions, then use that generated corpus as raw material to elaborate, rank, and evolve. The number is not magic; the bound is. A fixed count forces breadth first and judgment second, and gives me a finite surface to react against instead of a blank page.
Agent-drafted charters. Increasingly I do not draft the big prompts myself. I hand an agent the goal conditions and the intent, and it drafts the full charter: scope, sources, phases, gates, verification, handoff. I review, amend, and only then execute. The prompt becomes an artifact with a papertrail instead of a conversation I lost, and my attention goes to the contract’s correctness rather than its construction.
Delegated sub-agents with disjoint ownership. When agents work in parallel, each owns separate paths, hands back evidence, and stops at named boundaries. An orchestrator integrates; the workers never touch the shared checkout.
Deliberate model routing. Different models for different phases, with reasoning effort set per provider. Deep reasoning for planning and review; cheaper execution for mechanical phases.
And the newest piece, also the most meta: workbooks. A workbook, in my practice, is a generated instrument of roughly fifty targeted questions about a draft: its claims, its exact prose, its structure, its alternatives. This post was shaped by one; I answered fifty-three questions about the first draft, and the revision you are reading exists because of those answers. The instrument critiqued the artifact that describes the instrument. I find that genuinely funny, and also kind of the point.
CapturesA generated instrument of roughly fifty targeted questions about a draft: claims, exact prose, structure, alternatives.Potential request effectThe author's answers, not the model's guesses, drive the next revision.Does not establishAnswers shape future work only after human disposition; the instrument never answers itself.Governed context route
What one governed run looks like
The loop every contract-driven run follows, whether it lasts an hour or a month.
person
Intent
Name the outcome and why it matters, in plain language.
agent
Contract
Draft the goal prompt: sources, owned paths, no-touch paths, gates, stop conditions, definition of done.
person
Review
Read the contract, amend it, and only then release the run.
agent
Execute
Work inside the contract; stop at any named boundary instead of guessing past it.
agent
Verify
Run the checks the contract named; record actual results, not presumed ones.
person
Receipt
Preserve what happened, what it proved, and what it did not, then decide the next gate.
The route remains an ordered record: person, bounded system work, candidate proposal, human review, then a durable accepted result.
The library that grew from the prompts
The part I did not expect: once prompts became files, the files started behaving like a library. My Hub is organized into wings, each with a local charter that guides work in that area. Its governance grammar separates the evidentiary role of a claim from the kind of record that carries it. These are the eight claim labels I use:
| Class | What it means here |
|---|---|
| Source | the current canonical record |
| Evidence | a checkable observation |
| Inference | a conclusion with its assumptions visible |
| Hypothesis | a testable explanation, never settled fact |
| Proposal | a candidate action awaiting its gate |
| Projection | a derived view that can never replace its source |
| Receipt | process history with stated limits |
| Unknown | an explicit gap, not permission to guess |
A Plan is a separate artifact kind in the catalog, not a ninth claim label. Other record types include decision records and consolidation records that preserve choices such as deprecating a planned application or re-scoping a project. The Hub also has operational charters for workflows, skills, agent profiles, and the per-directory guidance for work in different parts of the library.
Two failure modes
Two failure modes taught me the shape of the thing. The first is the contract that is too big: early goal prompts tried to specify everything, and the agent would comply with the letter while drifting somewhere I never intended, or I would get bogged down in my own review gates, because the hub still demands manual maintenance I have not automated yet. The skill that emerged is less about preventing drift and more about noticing it and drawing the agent back to the central thread. The second failure is subtler: a procedure that exists but is never exercised. My scar-tissue rules came from real collisions, and I trust them more than the ones I designed in the abstract.
The claim I want to defend
Which brings me to the claim I actually want to defend. I use “intelligence layer” as a design term for the persistent material around a model in my system: contracts, charters, decision records, review states, knowledge labels, and no-touch boundaries. I route between several models, so those records help keep task context available when the model or session changes. I count a contract as part of that layer when it persists outside one session, the next agent can read and follow it without my repeating it, and I can inspect and revise it as an artifact. This is a claim about how I organize my system, not evidence that records are themselves intelligent or that they improve every model. Their practical value is that a later session can start with more of the task’s context visible.
Three objections, met on their feet
I expect three objections, and I want to meet them on their feet. First: prompting really is getting less important, because models keep absorbing procedure. Briefly, yes, the technique will keep evolving and the surface where careful instruction matters will keep shifting; I do not see model evolution replacing human delegation, human judgment about goals, or human review of at least some model output. Second: this is just software engineering. Yes, and I want to celebrate that rather than concede it; contracts, ownership boundaries, and review gates were always good ideas, and agents are the newest place they pay rent. The third is the one I will actually argue with: that the model is the intelligence. That confuses a component with the system. A capable model coupled with a weak representation of your work gives you fluent amnesia. A capable model coupled with a strong representation system, contracts, records, labels, return routes, gives you something closer to emergent institutional intelligence. The intelligence is in the coupling.
The smallest honest version
If you want to test this yourself, here is the smallest honest version: before your next significant run, write the goal down as a stored contract with the outcome, the boundaries, and the stop condition named; keep it where you can find it next week; and when the run ends, note what the contract caught and what it missed. That is the whole seed. Everything in my system grew from repeating that motion and keeping the receipts.
A fictional example
Suppose you have two drafts of an onboarding note and want to know whether a new engineer can tell what an agent may do and where a person must decide. A loose request might be: “Which draft is better?” A small contract makes the comparison inspectable:
- Task: Compare the two supplied drafts on that one reader question.
- Use: Only the text provided; do not infer what a live system or policy does.
- Return: For each draft, quote the wording that answers the question. Separate what the text states from your interpretation, then list any missing information.
- Boundary: Do not edit either draft or decide which one to publish.
- Stop: End after the comparison and name one question the author could resolve.
This is a fictional teaching example, not a prompt run or an evaluated result. The contract makes the requested comparison and its limits visible; it does not make the comparison correct by itself.
Limits, held loosely
I want to be plain about the limits. This is a field journal about one person’s practice, not a validated method; it comes with no productivity comparison or independent validation. Hearth & Code is also a special case in some respects; it grew around how I think. I have heard similar concerns from other practitioners, but I have not collected evidence that the specific approach here transfers to other agentic systems. Treat it as a candidate to inspect and adapt, not a recipe with demonstrated general results. Held loosely, like everything here.
So, back to the voice chat. In my practice, prompting has been shifting from clever phrasing toward procedure design. I expect that balance to keep changing as models and agent workflows change. When an agent works across tools or sessions, I still need ways to state boundaries and inspect what happened. A contract is one candidate for that job, not a requirement for every task. This is a position from my own practice, not evidence that agents always fail at greater scale or that contracts prevent those failures. I will keep reporting what mine catch, and what they cost.
A procedure-design case for a consequential task
Imagine an agent asked to update a data migration. The contract should name the source schema and target revision, the invariants that must survive, prohibited data changes, the tests that qualify the candidate, and the exact return format. The agent may draft a migration and run released local checks; a database write or production rollout remains a separate transition requiring its own scope and operator. For research, the same structure binds corpus, inclusion rules, extraction fields, uncertainty, and a return that distinguishes source statements from synthesis.
The engineering question is not whether more specification is always safer. Compare a concise instruction and a structured brief on matched tasks. Record omitted constraints, invalid outputs, repair effort, time-to-review, and any case where form encouraged false confidence. Hypothesis: explicit interfaces help when handoffs or correction costs are material; the article does not report a controlled comparison proving that claim.
AI assistance disclosure: AI assisted with research, drafting, and the language-pattern audit of this post. The practice described, the workbook questions and answers, the review judgments, and the posting decision are mine.