For the past several months, I have been building agentic harnesses around a profile fleet and a set of contractual task instructions. The work started from a practical frustration. A goal and a loop could get an agent moving, but they rarely said which source was current, what had to remain untouched, what a completed handoff looked like, or when the agent should stop and return a decision to me.
I began adding that missing structure deliberately. The result is a working practice I call contract-driven prompting: shaping an LLM task as an agreement about inputs, boundaries, and return conditions, rather than treating it as a single well-worded request.
This is not a claim that I have discovered a validated method. It is an operational observation from my own system, and a hypothesis worth testing. The question is whether a clear contract can improve a defined kind of downstream work, or whether a simpler prompt reaches the same result with less friction.
The problem is re-entry
Language models are fluent at carrying a conversation forward. That fluency becomes less useful when the work has to survive a handoff, a source change, a review boundary, or a return weeks later. In those conditions, the real problem is often re-entry: can a person reconstruct what was asked, what was used, what changed, and what still requires judgment?
I noticed this while moving between research passes, implementation tasks, public drafts, and governed reviews. The task could be plausible and still be hard to trust. A source might be missing. A good-looking answer might collapse evidence and inference. A model might continue past a decision that should belong to a person. The repair cost appeared later, when I had to rediscover the context.
Contract-driven prompting is my attempt to make that middle layer visible. It gives a task an intermediate representation between an initial intention and a finished response. I want to see the workbench before I ask the agent to use it.
A compact contract
The smallest form I have found useful has five parts:
INTENT
Produce a reviewable article candidate for agentic engineers.
INPUTS
Use supplied author notes and named public sources.
INVARIANTS
Keep first-person meaning with the author.
Separate evidence, observation, inference, and proposal.
Do not disclose private material or claim unmeasured performance.
BOUNDS
Do not publish, alter sources, or invent citations.
Stop when source support or authorial intent is missing.
RETURN
Provide the draft, source ledger, uncertainty note, and one next decision.The parts are deliberately ordinary. Intent says what the work is for. Inputs name what may be relied on. Invariants protect conditions that should remain true. Bounds describe where the task ends. Return makes the outcome usable by someone who did not witness the original exchange.
Structured output is useful here, but its role is limited. OpenAI’s Structured Outputs guide describes adherence to a supplied JSON Schema, including explicit refusals. [evidence] OpenAI Structured Outputs A schema can make a result easier to parse and inspect; it cannot make a claim true, choose an appropriate source, or give an agent permission to cross an authorship or publication boundary. Shape is not truth, and a task contract is not authority.
I use terms such as atoms, primitives, components, and intermediate representation because they help me distinguish levels of work. An atom is something I should not silently change: a source, date, claim, path, or constraint. A primitive is a small operation, such as comparing sources or flagging missing evidence. A component is a repeatable arrangement of those operations. The intermediate representation is the visible plan that allows the work to be inspected between request and result.
Why use bounded structure?
Powers of two have become a practical organizing convention in my work. A 16- or 32-part frame offers enough room to separate concerns. A larger charter can establish a reviewable limit around a complex workflow. The numbers do not have special cognitive force. They are a way to name capacity, surface omissions, and make a review workload easier to partition.
That convention has helped me generate more alternatives and trace more downstream work than an unstructured goal loop often did. This is a personal observation from one operating context. It may be explained by richer context, better task decomposition, or the fact that the act of writing a contract forces a clearer decision. I do not yet know which explanation carries the most weight.
The convention should lose when it adds ceremony without improving the task. If six elements are enough, a sixteen-part template is an unnecessary burden. If a 1,024-line charter hides a simple choice, the charter has failed its own purpose.
A workshop with visible limits
The image that helps me is a workshop bench. The tools are named, the materials are visible, and the sharp edges are marked before the work begins. The contract does not prevent filler, hallucination, or an invented connection. It does give the operator more places to inspect when those failures appear.
There are useful precedents for parts of this approach. DSPy presents a framework for programming language-model systems. LMQL provides a language for constraints and control flow in LLM interaction. The paper Imprompt: A Language Framework for Prompt Programming studies a typed prompt-language approach. [evidence] None of those precedents settles the broader question I am pursuing: how should an agentic task represent sources, scope, review gates, and a return path when its output will matter to a human system?
That question also has a simple objection. A sufficiently capable operator may get the same result from one concise natural-language instruction. If that happens, the concise instruction is the better design. Formality should make a task easier to direct or review, not simply make it feel more sophisticated.
From preference to a testable technique
The next step is a comparison, not a declaration. Take a small set of representative agentic tasks. Keep the model, available context, and success criteria constant. Run one condition with a concise natural-language request and another with a contract that names inputs, invariants, bounds, and return requirements.
Before running it, agree on what will be measured: task completion, unsupported claims, human repair effort, time to re-enter the work, and whether a later operator can understand the handoff. Record the source quality and task decomposition too, because either could explain an apparent gain. If the contract adds cost without reducing repair or increasing legibility, that is evidence against using it. If it surfaces failure earlier or makes a later review materially easier, that is evidence worth examining.
I want to develop contract-driven prompting as a method that can be shared, challenged, and made smaller where smaller is better. My current system is designed around the way I work: a digital hearth and hub for sources, boundaries, and return paths. Whether that structure is accessible to other people remains an open question.
The practical starting point is modest. For the next consequential task, name the intent, one or two hard boundaries, the sources that matter, a finite scope, and the return you need. Then ask what changed. Did the contract prevent a mistake? Did it add friction? Did it make the next session easier to enter? Or did it hide a decision that should have stayed visible and human?
AI assistance disclosure: AI assisted with source comparison, outline development, structural critique, and candidate editing. Scott supplied the operating context, method framing, observations, boundaries, and release decisions for this article.
Hearthside expansion / author review candidate
This added reflection is a private-to-public projection prepared in my requested voice. It remains subject to my factual, privacy, and authorship review.
The charter is a conversation with my future self
A goal prompt is often addressed to an agent, but I have found that its most important reader may be me several days later. The charter preserves what I was trying to protect when the task began: which source was current, what could not change, why one check mattered, and where the work was meant to stop. It turns intention into something returnable.
This is particularly useful when the task crosses disciplines. A writing request can contain an information-architecture decision. A design correction can expose a semantic problem. A platform plan can carry a privacy boundary. The charter gives those concerns names without requiring the agent to infer which one should dominate.
I do not expect the first contract to be perfect. In fact, its failures are part of the evidence. If the agent repeatedly asks the same question, the input may be underspecified. If the result is structurally correct but unusable, the output contract may be optimized for the validator rather than the reader. The charter can be revised because its assumptions are visible.
The private projection behind this method is that I need a bridge between associative thinking and sequential execution. The charter lets me preserve the constellation while choosing one path through it. It does not ask me to stop seeing the whole; it asks the current task to declare which part it can responsibly carry.
Where specification helps and where it harms
Specification helps when misunderstanding would be expensive or difficult to reverse. Public claims, durable records, external effects, privacy boundaries, and multi-stage handoffs benefit from explicit inputs and return conditions. The structure gives the agent and reviewer a shared object around which to disagree.
It harms when every ambiguity is treated as a defect to eliminate. Creative work often needs language that remains suggestive. Early research may need several live interpretations. A personal reflection can lose its grain when converted too quickly into fields. The contract should protect these qualities rather than flatten them into machine convenience.
It also harms when form becomes a substitute for judgment. A complete packet can still contain a weak source, a self-serving interpretation, or a needless project. Structural validity should make review easier, not make the work look reviewed. I try to keep the human question visible beside the machine-readable form.
My rule is to specify the edges more strongly than the center. Be exact about sources, permissions, prohibited effects, and what the return must expose. Inside those boundaries, allow the method and language enough flexibility to respond to the actual material.
The experiment I want to run
I want to compare three conditions rather than only a short prompt and a large contract. The first is a concise natural-language request. The second adds a bounded context and explicit output. The third adds formal stages, checks, and receipts. The question is where each layer begins to repay its coordination cost.
The tasks should vary in consequence and ambiguity: a factual lookup, a source synthesis, a code change, a public essay, and a plan that could lead to an external effect. The model and source set should remain fixed within each comparison. Human repair should be counted, including the time spent restoring voice and privacy boundaries.
I would measure more than completion. Did the result preserve source identity? Did it distinguish observation from proposal? Could another reader resume the work? Did the contract surface a failure earlier? Did the additional structure create false confidence? These questions treat inspectability as part of performance.
Until that comparison exists, contract-driven prompting remains a personal operational hypothesis. It has helped me shape complex work and reduce some forms of re-entry cost. That is enough to keep investigating, not enough to ask other people to inherit the full apparatus.