Research Packets

Open by naming the change in deliverable, because it is the quiet premise of the whole course. When research is done by hand, the deliverable is usually a presentation: a curated narrative of what the researcher concluded, with the evidence compressed into a few pull quotes. When an agent does the gathering and structuring, it can produce something better — a packet where the question, the sources, the method, the findings, and the evidence trail all travel together — and the human's job shifts from assembling the deck to auditing and interpreting the packet.

Be explicit that the packet is not bureaucracy. The fields exist because they are exactly what a reviewer needs to decide whether the work can be trusted, and exactly what a later agent needs to reuse the work as briefing input. Clever bespoke formats fail because the next person, or the next agent, cannot reuse them.

This module deliberately precedes the method modules. Deep desk research, teardowns, synthesis, and funnel diagnosis all change shape depending on the topic — but they all land in the same packet structure. Get the container right once and the rest of the course slots into it.

Walk the six parts in order, because the order is the argument. The question comes first and is human-written: it names the decision the research would change, which is the single best defence against the agent's tendency to accumulate everything vaguely related. Sources and method are where agentic research earns trust — every claim is dated, attributed, and marked for whether the source actually says it or the packet infers it, and the method section records how the evidence was gathered and what was deliberately left out.

Findings are the part most people think of as the research. In a packet they are ranked claims, not a wall of notes, and observation is kept visibly separate from inference — a discipline that Module 2 spends a whole slide on. The evidence trail is what makes the findings auditable: a reviewer should be able to pick any claim and follow it back to a quote, a link, a file, or a screenshot.

The last part is the one agents cannot own. Open questions name what the packet does not know; risk notes flag screenshots, claims, and sensitive territory before anything goes public; and the decision — approve, defer, reject, needs more research — is recorded by a person. The packet ends with judgment, not with a summary paragraph.

Use the diagram to make the packet feel like infrastructure rather than paperwork. Read it in two passes. First pass, ownership: the question and the decision carry the human-led colour, the gathering parts — sources, method, evidence — are agent-built, and findings sit in between because the agent drafts them and the human decides what they mean. That ownership split is the same human-gate pattern this school uses everywhere: the agent runs production, the human holds the ends.

Second pass, the downstream band. The question keeps later runs and briefs scoped to a decision instead of general curiosity. Sources get re-checked when the packet is regenerated — packets in fast-moving areas go stale, and regeneration is cheaper than arguing about memory. The method is what lets a sceptical reviewer challenge or re-run the work. Findings become the constraints and direction lines in later design briefs, which is the subject of slide seven. The evidence trail is what reviewers spot-check rather than re-read in full. And the decision is the gate: nothing moves from research into a brief or a public page before it.

If participants take one thing from the diagram, it should be that every field in the packet exists because something downstream consumes it. Fields nobody consumes can be cut.

Be specific about where the leverage actually is, because the honest list is less glamorous than the marketing version. Coverage is the obvious one: an agent can read the documentation, changelogs, reviews, and pricing pages of a dozen products, or a year of support tickets, in the time a researcher spends on two. The quality of any single judgment is lower than a good researcher's; the floor across the whole corpus is far higher than what a tired person produces at item thirty of forty.

Structure and recall are the underrated pair. People write their best source notes on day one and their worst on day five; an agent fills the same fields with the same discipline on every item. And because everything is text in a repository, recall is mechanical — the exact quote, the URL, the date checked — rather than reconstructed from memory in front of a stakeholder.

Traceability and re-running are what make packets durable. Hand-built research loses the claim-to-evidence link the moment the deck gets edited. A packet keeps it, and when the underlying sources change — a tool renames a feature, a competitor changes pricing — the cheaper move is often to re-run the packet against fresh sources rather than argue about which parts of the old one still hold. The school's own research runs work this way, and the worked example later in the module shows one.

This slide is the counterweight to the previous one and deserves equal time. Novelty first: an agent synthesising desk sources will converge on the consensus view of those sources, because that is what synthesis of existing text does. If the question needs a framing nobody has written down yet, the agent can assemble the raw material but the reframe comes from a person. Treat agent output as a very well-organised literature review, not a discovery.

Contact with users is the hard limit. An agent can draft a discussion guide, transcribe, and theme — Module 3 covers all of that — but it cannot sit in the room, notice the pause before an answer, or build the trust that makes someone say what they actually think. Research programmes that replace contact with desk synthesis drift towards confident descriptions of users nobody has spoken to recently.

The last three are about epistemics. Agents do not reliably know what is missing: if no source discusses a failure mode, the packet reads as if the failure mode does not exist, which is why the open-questions field is mandatory rather than optional. Fluency flattens confidence — a low-confidence inference reads as smoothly as a verified fact unless the packet forces confidence labels. And consent, privacy, and publication ethics are accountability questions; the agent can flag them in risk notes, but a person answers for them.

The timing in the title is the point: these standards belong in the agent's instructions — the harness, in this school's vocabulary — before the first run, because retrofitting them means re-litigating work that already exists. Once they are written down, the agent applies them with more consistency than a person would, which is one of the few places where the agent's lack of judgment is an advantage.

The says-versus-infers rule matters most in fast-moving tooling and competitive research, where a feature name or a marketing page routinely sounds more capable than the behaviour underneath. The school's own source-note template makes them separate fields: what the source directly says, and what this packet infers. Dating is the second habit: a packet built on a Monday can be quoting stale pricing by Friday, so volatile claims carry a date checked and get re-fetched before anything is published — the same conservatism this course applies to its own time-sensitive claims.

The three-level confidence scale is deliberately blunt. High means the source was checked and the behaviour was tested locally; medium means the source was checked but not tested; low means anecdotal or unclear, and low-confidence material does not get published as guidance — it gets a follow-up check or a test. The last two rows are hygiene with legal weight: keep excerpts short and pointed rather than copying whole documents into the repository, and record screenshot ownership at capture time, because an image that was fine to study is not automatically fine to publish.

This slide is the bridge between this course and the design-side workflows the school teaches elsewhere. A design brief asks for the user job, the constraints, the references, and the review criteria. A good packet already contains most of that: the findings supply the constraints and the direction, the question names the decision the work serves, and the evidence trail explains why each constraint exists — which matters as much for the agent generating the design as for the teammates reviewing it.

The practical mechanics are unglamorous. Briefs cite packets by path, and packets sit in the same repository as the design work, so the agent generating a screen can be pointed at the packet that motivated it. That is the difference between a brief that says reduce friction at sign-up and one that says the packet at this path shows the drop happens at the email-verification step, with the evidence two clicks away.

The open-questions field earns its keep here too. Gaps the research could not close should appear in the brief as named assumptions rather than disappearing, because a named assumption is something a team can decide to test, while a silent gap becomes a confident design decision nobody remembers making. Module 6 of this course is entirely about this insight-to-brief step; this slide plants the connection.

The example on the slide is a real folder from this school's own repository — one of more than twenty research runs under content/research-runs/ as of June 2026 — not a proposed ideal. The conventions are deliberately dull. The folder name is the run date plus a slug for the question, which makes runs sort chronologically and makes staleness visible at a glance. The file names are identical across every run: the report with the findings, the raw signals as structured data, candidate actions split into new material and updates to existing material, the visual plan with rights noted, the compliance or risk notes, and the decision log.

Say why this matters more in agentic research than it did before. An agent asked to build on previous research can only do so if previous research is findable and predictable: same paths, same file names, same fields. The repository layout is effectively part of the method. It is also what makes packets citable — a brief can reference a finding by path and heading, and a reviewer can follow that path months later.

Map the files loosely onto the anatomy from earlier so the structure does not feel like a second thing to learn: the question and method live at the top of the report, findings and evidence fill its body and the signals file, candidates are the packet reaching towards briefs, and the risk notes and decision log are the human end of the packet. Adapt the file names to your own context freely; what cannot vary is that every run uses the same ones.

Walk the table as a story, because it shows the anatomy doing real work. The run is 2026-06-01-choosing-your-agent-platform in this school's research-runs folder. The question was narrow and decision-shaped: the school planned an article comparing four agent platforms for design work, and the run existed to confirm what the article could safely claim. The sources section shows two of the standards from earlier in action — every claim is dated, and findings from a previous run are explicitly reused rather than silently re-asserted.

The headline finding is the kind that desk research at agent scale is good at surfacing: one of the four platforms named in the article title was being retired for individual users roughly two and a half weeks after the planned publication date. Publishing the comparison as drafted would have dated the article almost immediately. The packet also caught several facts inherited from the book manuscript that were no longer true — capabilities the book said a platform lacked that it had since gained. None of this required insight; it required checking every claim against a current source and writing down the date.

Point at the confidence discipline in the evidence row: facts fetched directly from official pages are marked as such, facts that arrived via search snippets are marked re-verify before quoting, and pricing is treated as volatile by default. Then the decision log records the human call about what the article does. That is the whole loop of this module in one folder: agent-built coverage and traceability, human-owned question and decision.

Risk notes are the part of the packet that feels optional until the day they are not. The most common risks in agentic design research are mundane: stating that a tool supports a workflow when the source only implies it, overclaiming what an agent can do, using screenshots whose ownership was never recorded, exposing internal research metadata — run identifiers, internal status labels — on public pages, and writing guidance that sounds universal when it was only ever true for one stack or one team. The packet does not replace counsel or a privacy review; it keeps these questions visible at the moment they are cheapest to answer.

The scope warning deserves its own sentence. Agent-scale research makes it easy to generate confident, general-sounding claims from thin evidence — one failed experiment, one vocal reviewer, one competitor's edge case. The discipline is to name the scope in the finding itself: in this corpus, for this segment, on this date.

The decision log is the packet's full stop. Approve, defer, reject, or needs more research — recorded with a name and a date. This is the same gate pattern used everywhere in this school's workflows: the agent can prepare everything up to the decision, and the decision is a person's. Teams that skip the recorded decision end up with research that was technically done but never owned, which is how findings get re-litigated months later.

Like the exercises across this school's courses, this one is deliberately analogue: a page, not a terminal. The aim is to surface how much of packet quality is decided before any agent runs — in the question, the source list, and the standards — and most participants find the first bullet hardest. Questions arrive as topics: onboarding, pricing, the competitor's new feature. Turning a topic into a decision — what would we do differently depending on the answer — is the single most valuable rewrite, and it is exactly the discipline that stops agent-scale research becoming unfocused accumulation.

The third bullet forces the honest split from earlier in the module. If the question genuinely needs new contact with users, the packet should say so and scope what desk research can and cannot answer in the meantime, rather than letting coverage substitute for contact. The fourth bullet is small but binding: writing the standards line now means the first real run inherits it.

If running this live, have a few people read their question-as-decision out loud and push on it: who makes that decision, when, and what evidence would actually move them. Questions that survive that push are worth a packet. Keep the pages — Module 2 opens by scoping a deep research run, and this definition is its starting input.

Recap by connecting the bullets rather than repeating them. The packet structure exists because of the strengths-and-limits split: agents are good at coverage, structure, recall, and traceability, so those parts are agent-built; they are bad at novelty, contact, and knowing what is missing, so the question, the open-questions field, the risk notes, and the decision stay human. The source standards and the folder conventions are what turn a one-off good packet into a repeatable practice — they live in the harness and the repository, not in anyone's memory.

The worked example is the proof point worth restating: a real run caught a deprecation and a set of stale facts that would have undermined a published article, purely because the method forced every claim to be checked and dated. That is the realistic promise of this material — fewer embarrassments and faster decisions, not magic insight.

Preview Module 2 concretely. It takes the packet into the noisiest territory: deep desk research and competitive teardowns, where an agent can produce enormous coverage very quickly. The module covers scoping the question so breadth stays useful, capturing flows and patterns with screenshot evidence and the rights questions that come with it, and the discipline of keeping observation, inference, and recommendation visibly separate. Participants who did the exercise bring their packet definition with them.