I run a recurring engagement type for university technology transfer offices: take a batch of invention disclosures, verify the actual IP position on each one, and produce a set of commercial and regulatory assessment deliverables, per-technology one-pagers, a portfolio summary, partner landscape maps, an inventor-facing presentation. It's a real, multi-step workflow with a lot of ways to get a small step wrong in a way that produces a confidently wrong deliverable. At some point I stopped re-explaining that workflow from scratch every time I ran it with an AI assistant and started building it into something the assistant could execute repeatably and correctly on its own. What that actually took is a more interesting story than "write good instructions," and it's worth walking through, because most of the lessons generalize past this one workflow.
The first version was too trusting
The naive version of teaching an AI a document workflow is a prose description of the steps: read the patents, write the summaries, build the deck. That version fails in ways that are individually small and cumulatively serious, because a language model given loose instructions will do something reasonable at every step, and "reasonable" isn't the same as "correct" when the underlying documents have traps built into them.
The first real trap in this workflow is that WIPO PCT publications, the international patent filings that make up most university disclosure portfolios, arrive as PAMPH files. Those are ZIP archives of scanned page images, not searchable text PDFs. An instruction that says "read the patent filing" without accounting for that will get you an assistant that tries to extract text from an image and either fails outright or, worse, hallucinates plausible-sounding content instead of the real filing. The fix isn't a smarter instruction. It's an explicit, mandatory procedural step: extract the archive, render the specific page you need, and read it as an image, every time, no exceptions for files that "look like" they might be text-based.
That's the first lesson worth generalizing: a workflow built from real documents needs to encode the actual, specific failure modes of those documents, not a generic description of the task. You don't discover those failure modes by writing instructions in the abstract. You discover them by running the workflow for real, watching where it goes wrong, and writing the fix into the instructions as a rule, not a suggestion.
Sequencing matters more than any individual step
The single most consequential rule in this workflow isn't about formatting or tone. It's about order: verify co-applicant status on every disclosure, against the actual patent cover page, before producing any deliverable at all. A co-applicant institution that isn't the client's own tech transfer office can block unilateral licensing outright, and if that check happens late, or gets skipped for disclosures that "look" clean from a summary spreadsheet, the assistant can produce a polished, professional-looking licensing recommendation for an asset the client doesn't actually have unilateral authority to license. The deliverable isn't obviously wrong. It reads as confident and complete. That's what makes a sequencing error more dangerous than a formatting error: a wrong number in a table looks wrong. A correct-looking document built on an unverified assumption doesn't announce itself as a problem until someone downstream, ideally not a funder or a licensing partner, catches it.
Encoding that meant writing the rule as a hard gate rather than an early step in a list: nothing else in the workflow proceeds until this specific check has been done, for every disclosure, against the primary document rather than a summary of it. Sequencing rules like this are the ones worth spending real thought on, because they're the ones a fast, capable assistant is most likely to reorder or compress on its own if you don't make the dependency explicit.
Reference examples beat prose specifications for anything visual
For the document deliverables themselves, the workflow doesn't describe fonts, colors, and layouts in prose. It points at real finished examples and says: match this file's structure, and sample its actual design values directly from the file, not from a description of the file. That distinction matters because a written color specification goes stale the moment the client rebrands, and because two similar colors can be visually indistinguishable at screen resolution while being meaningfully different in the underlying file. An instruction that says "use the client's navy blue" is fragile. An instruction that says "extract the exact hex value from the template's XML before you generate anything, and audit your own output against that same set afterward" is durable, because it points at ground truth instead of at a memory of ground truth.
This generalizes past design tokens. Anywhere a workflow has a "match the reference" requirement, pointing the assistant at the actual reference artifact and having it extract the specification directly, rather than writing the specification down once and trusting it to stay accurate, produces something that survives the underlying materials changing without needing the instructions rewritten every time.
Knowing which QA findings are real
Quality control for this workflow includes rendering every generated document to check for layout defects, overlapping elements, text overflow, misaligned footers. The complication is that the rendering environment doesn't have the client's actual fonts installed, so it substitutes a different typeface, and that substitution changes text width enough to create wraps and overflows that don't exist in the real, correctly-rendered file. An assistant that doesn't know this will spend real effort "fixing" a defect that isn't there, tuning a value against the wrong font's metrics, and can easily make the actual file worse in the process.
The fix baked into the workflow is a comparison step: render the pristine, untouched reference template through the same broken pipeline first. If the reference shows the same wrap or overflow, the rendering environment is lying, not the document, and there's nothing to fix. Only a difference from that baseline is a real defect. That's a specific, non-obvious piece of judgment, knowing that your own verification tooling has a known distortion and building the correction for that distortion directly into the workflow, and it's exactly the kind of thing that only gets discovered by actually running the process and noticing when a "fix" made something worse instead of better.
Consistency at scale means computing, not deciding
The workflow includes a step that sorts commercial partners into outreach tiers based on several factors: strength of technology match, regulatory pathway maturity, existing distribution in the target market. Across a portfolio with more than a hundred candidate companies, if that sorting is left to case-by-case judgment on each one, it will be inconsistent, not because the judgment is bad, but because "case by case" doesn't scale to that volume without drift. The workflow instead defines a deterministic rule set for tier assignment and has the assistant compute the tier from the underlying data rather than assign it by feel. A company whose only technology match sits against a disclosure with an unresolved IP gap gets demoted a tier automatically, regardless of how good the strategic fit looks otherwise, because the rule says so, not because someone decided it in that specific instance. That demotion is itself a useful finding to hand the client. It wouldn't be reliable if it depended on remembering to apply the same judgment call the same way the hundredth time as the first.
The workflow document is never finished
Every one of these rules exists because a real engagement surfaced the failure mode first. The document that encodes this workflow carries an explicit, numbered list of lessons learned from prior engagements, and the expectation is that it grows every time something goes wrong in a new way. That's the part of this that's easy to underrate: teaching an AI assistant a real document workflow isn't a one-time authoring exercise. It's closer to writing and maintaining a procedure document the way you would in an actual quality system, versioned, updated when a gap surfaces, and treated as authoritative only up to the point where it's been checked against reality. The workflow that runs correctly on the tenth engagement isn't the one that was well-written on day one. It's the one that got corrected nine times by someone paying attention to exactly how and why it went wrong.