Section 1
Do not update articles from memory alone
Agentic design changes quickly. Tools add features, remove behavior, rename concepts, and change how designers should work with agents. Updating articles from memory creates stale material, but publishing every tool announcement creates noise.
A research packet sits between those extremes. It gives an article update a paper trail: what changed, where the signal came from, why it matters to design practice, which public pages or workflows it affects, what risks need review, and what editorial decision was made.
The packet is not a bureaucracy layer. It is a quality filter. It protects the school from shallow tool news while still letting the curriculum evolve when a tool change affects briefing, critique, harnesses, visual QA, design systems, or publishing workflows.
Section 2
What counts as a signal
A signal is any piece of evidence that might change what designers should learn or do. It can be a release note, a reader question, a failed agent run, a screenshot of a new UI pattern, a repository change, a conference talk, or an internal experiment.
The mistake is treating every signal as content. Most signals are not articles. Many are notes, examples, warnings, updates to an existing guide, or things to watch for later. The packet forces the editor to translate the signal into design relevance before writing public material.
- Tool signal: a coding agent adds background workers, visual comparison, memory, or browser automation.
- Practice signal: designers start using a new prompt pattern, critique loop, or harness structure.
- Failure signal: an agent repeatedly produces the same weak interface, missing state, or accessibility bug.
- Reader signal: subscribers ask the same question about workflow, taste, review, or production readiness.
- Evidence signal: screenshots, code diffs, or audit reports show a repeatable design problem.
Section 3
The update loop
The loop starts with a signal. The packet records the source, extracts the design implication, proposes candidate actions, and asks for a decision. Only after that decision should the article, workflow, or newsletter be updated.
Nothing should auto-publish from a daily research scan. The point of the packet is not to remove editorial judgment. The point is to make judgment easier by putting evidence, context, and risk in one place.
Signal
Source check
Design implication
Candidate
Decision
Draft update
Publish or archive
feeds next cycleA research packet turns raw signals into reviewable candidates before any public article changes.
Section 4
Case study: background design-review agents
Imagine a tool introduces a way to run background agents while the main agent continues implementation. The raw tool announcement is not an article yet. It might be a small update to a multi-agent workflow, a warning inside a critique-loop article, a new team process, or simply an archive note.
The packet asks: what does this change mean for designers? If background agents can inspect screenshots while a main agent codes, the practical design implication is not parallelism as a feature. It is a new review shape: one agent can implement while another gathers evidence, but the designer still needs a clear ownership model and a final decision point.
That distinction matters. A shallow update would say designers can now use multiple agents at once. A useful school update would explain when parallel critique helps, what files each agent may touch, how to avoid duplicate work, and how the designer merges findings into a single revision plan.
Raw tool signal
Official source
Design implication
Affected article
Proposed visual
Editorial decision
A signal becomes useful only after it is translated into design relevance and candidate actions.
Section 5
Build the packet folder
A research packet should be boring and repeatable. Clever formats fail because the next editor or agent cannot reuse them. The value is in stable fields: source, claim, interpretation, affected material, proposed public change, risk notes, visuals, and decision.
Keep source excerpts short. The packet should point to sources and summarize relevance; it should not copy entire posts, docs, or articles into the repo. When the source is a screenshot, record who owns it and whether it can be used publicly.
content/research-runs/2026-06-01-agent-tool-watch/ ├── research-report.md ├── signals.json ├── article-candidates.md ├── update-candidates.md ├── visual-plan.md ├── risk-notes.md └── decision-log.md
Section 6
Write source notes that an editor can trust
Source notes should separate what the source says from what the editor infers. This is especially important in fast-moving AI tooling, where a feature name can sound more capable than the actual behavior.
A useful note has four parts: the observed change, the source link or local evidence, the design implication, and the confidence level. If confidence is low, the packet should recommend a test or a follow-up source check before publication.
## Signal [short description of the observed change] ## Source - URL or local evidence path: - Date checked: - What the source directly says: - What this packet infers: ## Design implication [briefing, workflow, review, visual QA, design system, publishing, or no practical impact] ## Confidence - high: verified by source and local test - medium: verified by source, not locally tested - low: anecdotal or unclear; do not publish as guidance yet
Section 7
Use a candidate decision matrix
Not every signal deserves a new article. A good decision matrix keeps the publication layer focused. It also prevents the school from becoming a feed of tool updates that age badly.
The decision should be based on practice change. If the signal changes how a designer briefs, structures, reviews, or ships agent work, it may deserve curriculum. If it is only a renamed button or a vendor announcement with no workflow impact, it probably belongs in the archive or newsletter.
The signal changes a major design workflow and needs examples
The signal modifies an existing concept, tool section, or warning
The signal is procedural and reusable across projects
The signal is useful but small, speculative, or still evolving
The signal is interesting but not relevant to agentic design practice
The same signal can become an article, an update, a workflow template, a newsletter note, or nothing.
Section 8
Good vs bad packet decisions
A bad packet decision reacts to novelty. A good packet decision reacts to changed practice. This keeps editorial energy focused on what readers can actually use.
New feature looks interesting; write article
Feature changes critique workflow; update multi-agent article with ownership rules
Reader asked about prompts; publish a prompt list
Three readers hit the same briefing failure; write a case-study section with before/after prompts
Tool screenshot looks cool; add it to homepage
Screenshot demonstrates a new visual QA state; use only if rights and context are clear
The decision should explain why the signal belongs in public curriculum or why it should stay in research.
Section 9
Risk notes are part of the packet
A research packet should flag risk before writing public copy. Does the article mention a tool trademark? Does it include screenshots? Does it make claims about privacy, accessibility, law, finance, medicine, or professional advice? Does it need source attribution or disclosure?
The packet does not replace counsel. It keeps risk visible before publication. For Agentic Design School, the most common risks are stale tool behavior, overclaiming what an agent can do, using unowned screenshots, exposing internal workflow metadata, and writing guidance that sounds universal when it is only true for one stack.
- Do not expose research run IDs, compliance status labels, or internal editorial state on public pages.
- Do not claim a tool supports a workflow unless the source or local test confirms it.
- Do not use screenshots publicly unless rights and context are clear.
- Do not turn one failed experiment into universal advice without naming the scope.
Section 10
Reusable candidate template
Use this template when a daily research scan produces a possible article or update. It is intentionally plain because the packet should be easy for an agent to read and easy for a human to approve.
## Candidate Signal summary: [what changed or what was observed] Source and confidence: [where it came from, date checked, confidence level] Why it matters for agentic design: [briefing, workflow, review, design system, visual QA, research, or publishing impact] Affected articles or workflows: - [article or workflow] Proposed public change: - [new article, update, template, newsletter note, archive] Practical example needed: - [case study, prompt, file structure, screenshot, diagram, table] Risk notes: - [claims, screenshots, trademark, privacy, accessibility, legal-sensitive language] Decision: - [ ] approve - [ ] defer - [ ] reject - [ ] needs more research
Section 11
Use packets to keep articles alive
A school about agentic design cannot be static. The articles should have review dates, update notes when needed, and a clear path for new signals to become better examples.
The packet is how the school stays current without becoming a tool-news stream. It helps editors ask the right question: does this change what a designer should do on Monday morning? If yes, update the curriculum with examples. If no, archive the signal and move on.
1. Capture the signal with source and date. 2. Separate direct source claims from editorial inference. 3. Name the design implication or mark "no practical impact." 4. Choose candidate action: article, update, workflow, newsletter, archive. 5. Draft the practical example before public prose. 6. Add visual plan and risk notes. 7. Record the editorial decision. 8. Update the article only after the decision is approved. 9. Keep the packet for future review.
