Where to Track What Changed: Staying Current After This Domain Ages#

TL;DR#

Every lesson 01 through 06 in this subject will be wrong within months, not years - that is by design, not a defect (agent-docs/fast-moving-domain-policy.md). This lesson does not teach what changed; it teaches the durable skill of finding out what changed: preferring primary sources (official specs, changelogs, vendor engineering blogs, release notes) over secondary aggregator content, evaluating any given source's reliability before trusting it, and running a sustainable cadence for staying current that does not require re-reading the entire field from scratch every quarter. This is the one methodology in this subject that does not expire when the products it was written about do.

The idea#

This subject exists because agentic-engineering cannot anchor itself to a settled book the way the other eight domains do (agent-docs/fast-moving-domain-policy.md). Lessons 01-06 accepted that instability and named concrete products anyway, on a fixed quarterly review cadence, because refusing to teach current tools until the field "settles" was never a real option. But a taught snapshot, however carefully dated, has a shelf life measured in the same months the field itself moves on - which means the actual skill a learner needs, once this subject's lessons age past their next_review dates, is not "know the current landscape" (impossible to guarantee in a static document) but "know how to re-derive the current landscape yourself, reliably, on an ongoing basis." That second skill is durable in exactly the sense agent-docs/fast-moving-domain-policy.md defines: it would still be true and still be useful even if every product named in lessons 01-06 disappeared tomorrow and was replaced by something with different names.

This is also, not incidentally, a completely general information-literacy skill that predates agentic engineering by decades - librarians and researchers have taught primary-vs-secondary source discipline and reliability evaluation for as long as there has been more written material than any one person could personally verify. What is specific to this domain is not the mental toolkit, which is old and well-tested, but the particular categories of source worth tracking (model provider pricing pages, protocol spec repositories, vendor engineering blogs) and the cadence the field's rate of change demands. This lesson applies old, durable judgment to a new, fast terrain.

How it works#

Primary sources over secondary aggregator content, and why the distinction matters more here than usual#

A primary source, in this context, is the document the fact originates from: a vendor's own pricing page, a protocol's own specification repository, a changelog written by the team that shipped the change, an engineering blog post from the team that built the feature. A secondary source is anyone else's write-up, summary, or analysis of that primary source - a "2026 pricing guide" blog post, a listicle comparing frameworks, an aggregator site that republishes vendor announcements with commentary.

The general information-literacy case for preferring primary sources - fewer opportunities for transcription error, summarization drift, or an intermediate author's own misunderstanding to enter the chain - applies here with extra force for a structural reason specific to this domain: secondary content about a fast-moving field goes stale in a way secondary content about a stable field does not, and it often does so silently, with no correction issued. A textbook chapter about a stable algorithm stays correct indefinitely once written. A blog post titled "Complete Guide to [Provider] Pricing 2026," written in month 3 of the year, is often still ranking in search results in month 9, unrevised, after the provider has changed prices twice. This lesson's own research for lessons 05 and 06 hit this directly: a source dated earlier in the same month referenced an OpenAI model family by a name that had already been superseded by the time the lesson was written three weeks later, while the primary pricing documentation reflected the change immediately. The secondary source was not dishonest - it was accurate when written and stale by the time it was read, with no mechanism to signal that staleness to a reader landing on it cold.

A concrete rule of thumb this implies: when researching a perishable fact, locate the primary source first (the vendor's own docs, the spec's own repository, the changelog's own feed) and use secondary sources only to discover that something changed or to find where the primary source lives - never as the final citation for the fact itself. This is exactly the research discipline this subject's own authoring instructions impose on lessons 05 and 06 (see their source: front matter, which cites primary vendor documentation pages, dated, ahead of any secondary comparison article).

Evaluating a source's reliability before trusting it#

Not every claimed-primary source is equally trustworthy, and not every secondary source is equally worthless - a well-run engineering blog from the team that actually shipped a feature is closer to primary than a press release written by a marketing team once removed from the engineers, even though both are "the vendor's own words." A practical, general-purpose framework from information-literacy practice - often taught as the CRAAP test (Currency, Relevance, Authority, Accuracy, Purpose) - gives a checklist that generalizes cleanly to this domain:

Currency: does the source carry a visible date, and is that date recent enough to matter for a fast-moving fact? A pricing page with no visible last-updated date is a yellow flag; a changelog entry with a commit date or release date is not.
Relevance: does the source actually address the specific claim being verified, or something adjacent that's being generalized from? ("The API supports streaming" is not evidence for "the SDK's streaming defaults changed in this release.")
Authority: who wrote it, and do they have first-hand knowledge? A vendor's own engineering-blog post from the team that shipped a feature carries more authority than a third-party aggregator's paraphrase of a press release about that feature.
Accuracy: can the specific claim be cross-checked against another independent source, ideally a primary one? A single secondary source making a surprising claim (e.g., an unusually large price cut) is worth corroborating before it goes into anything load-bearing.
Purpose: is the source trying to inform, or trying to sell something (including selling itself via SEO-optimized "complete guide" content designed to rank rather than to stay accurate)? A vendor's own pricing page has an obvious incentive alignment with accuracy (customers billing off a stale price they were misled about is a support and trust cost the vendor bears); an SEO content farm's incentive is page views, and accuracy is a means to that end, not the end itself.

Worked example. Researching current API pricing for landscape-snapshot/05 turned up nine-plus search results, most of them third-party "2026 pricing guide" articles from sites with no visible engineering relationship to the vendors they were describing. Applying Currency and Authority together narrowed the useful set fast: the vendor's own pricing documentation page (highest authority, and in Anthropic's case carrying an explicit dated note about a specific pricing change taking effect on a specific date) outranked every aggregator, and where the aggregator sites disagreed with each other or with the primary source - which happened, concretely, on Google's Gemini Pro-tier pricing in this lesson's companion research - the primary source's own page was treated as authoritative and the discrepancy was flagged rather than silently resolved by picking whichever number sounded more confident.

What to actually track, and at what cadence#

Applied to this specific domain, the useful primary-source categories are a short, stable list even though what each category contains changes constantly: - Vendor pricing and model-release pages (e.g., a provider's own /pricing and model-changelog documentation) - the primary source for everything landscape-snapshot/05 covers. - Protocol and spec repositories (e.g., MCP's own specification repository, the AGENTS.md specification's own repository under its governing foundation) - the primary source for everything landscape-snapshot/03 and landscape-snapshot/06 cover, and generally more reliable than any vendor's description of how it implements a spec, since the spec repository is upstream of every implementation. - Vendor engineering blogs, specifically the team-authored kind rather than corporate press-release channels - the primary source for why a change was made, which release notes alone rarely explain, and directly useful for landscape-snapshot/01 and landscape-snapshot/02's territory (product and framework changes). - Benchmark and leaderboard sites' own methodology pages - not the leaderboard numbers themselves (which move constantly and are exactly what landscape-snapshot/04 snapshots) but the methodology documentation, which changes slowly and is what lets a reader judge whether a leaderboard number is even measuring what they think it measures.

A sustainable cadence does not mean monitoring all of this continuously - that is not durable practice, it is a recipe for burnout in a field that generates announcements weekly. Current practitioner guidance on staying current in fast-moving technical fields converges on a two-speed pattern: a lightweight, frequent pass (skimming primary changelogs and release notes for the small number of sources that matter most to your actual work, on the order of weekly or biweekly) paired with a deliberate, scheduled deeper pass (reviewing what actually changed enough to matter, revising any documents or mental models that depended on the old state, on a cadence measured in months). This is not a novel idea invented for this lesson - it is the same two-speed pattern this repository's own agent-docs/fast-moving-domain-policy.md already implements structurally for landscape-snapshot itself: next_review dates force a scheduled deeper pass every quarter, while nothing stops (and good practice encourages) a lighter, more frequent check of the small number of primary sources each lesson actually depends on.

This repository's own quarterly cadence as one instance of the general pattern#

agent-docs/fast-moving-domain-policy.md is not a metaphor for this lesson's advice - it is a literal, inspectable instance of it. Every lesson in landscape-snapshot carries a next_review date set to its created date plus one quarter; a review is either "still accurate" (bump the date, no rewrite) or "changed" (rewrite the affected part, normal PATCH or MINOR). That is the deliberate, scheduled deep pass described above, made concrete and enforced by a release-cutting workflow step that scans for lapsed next_review dates rather than relying on anyone remembering to check. The lightweight frequent pass this lesson also recommends is left to the individual maintainer's judgment - the policy does not mandate weekly monitoring, because forcing that would itself violate the "review cadence proportionate to actual volatility" judgment this lesson is trying to teach.

The generalizable lesson from this repository's own solution: a durable practice for staying current is not "monitor everything, always" - it is a two-speed system with an explicit, calendared trigger for the expensive pass, so staying current doesn't depend on remembering to feel like it's time. Any engineer, team, or codebase can adopt the same shape - a scheduled deep review with a hard trigger, plus lightweight ambient monitoring of the handful of primary sources that actually matter to their work - regardless of whether they ever touch this specific repository's tooling.

Pros#

Primary-source-first research is directly verifiable by the reader - a citation to a vendor's own dated pricing page can be re-checked by anyone in thirty seconds, unlike a citation to "industry reports suggest," which cannot.
A calendared review cadence (this repository's quarterly next_review, or any team's chosen equivalent) converts "stay current" from an ambient anxiety with no defined end state into a bounded, schedulable task - the same reframing agent-security-and-operations/05's budget caps apply to runaway cost, applied here to runaway staleness.
The CRAAP-style reliability checklist is cheap to apply (five short questions) and transfers to any domain, not just this one - a skill worth having independent of whether the learner ever revisits agentic-engineering specifically.

Cons#

Primary sources are not always available or not always clearly primary - a protocol with no public spec repository, or a vendor that only communicates pricing through sales calls, forces a fallback to secondary sources with no clean substitute; the discipline in this lesson reduces but does not eliminate that gap.
A quarterly (or any fixed-cadence) review can still miss a fast-moving change that matters between reviews if there is no lightweight monitoring layer running concurrently - the two-speed pattern only works if both speeds are actually maintained, not just the calendared one.
Applying a full CRAAP-style evaluation to every single claim does not scale; in practice it has to be reserved for claims that are surprising, load-bearing, or contested - over-applying it to routine, uncontroversial facts is its own form of wasted effort.

Alternatives#

Delegating currency-tracking to a third-party aggregator or newsletter entirely - lower effort, but reintroduces exactly the staleness and authority risk this lesson warns against unless the aggregator itself is evaluated with the same reliability checklist; reasonable as a discovery mechanism ("something changed, go check the primary source") but not as a citation of record.
Continuous, unscheduled monitoring with no calendared deep-review trigger - can catch changes faster than a quarterly cadence, but has no forcing function to guarantee comprehensive review actually happens, and tends to degrade into either constant low-value noise-watching or silent neglect once initial enthusiasm fades; the calendared trigger exists specifically to survive that decay.
Freezing a document and never revisiting it, accepting known staleness - a legitimate choice for content whose cost of being wrong is low and whose audience already discounts it appropriately (this is, in effect, what a durable-tagged lesson elsewhere in this domain implicitly assumes about its own boxed-off product examples); not appropriate for anything a reader might treat as current fact, which is why landscape-snapshot explicitly rejects this option for itself.

When to use it#

Apply this lesson's discipline any time a claim in this domain matters enough to be load-bearing - citing a price in a budget proposal, choosing a protocol based on its current adoption, picking a model tier for a production system - and especially once any specific lesson in 01-06 has passed its next_review date, at which point this lesson's method (not that lesson's remembered content) is the actually-reliable resource. It also applies well beyond this repository: any engineer working in a field that changes faster than their reference material can be re-published needs some version of this two-speed, primary-source-first practice.

When NOT to use it#

Do not apply full source-reliability scrutiny to low-stakes, easily-correctable claims - checking five sources to confirm a fact that costs nothing to be wrong about for an hour is disproportionate, and this lesson's own "Cons" section names that failure mode directly. Do not treat a calendared review cadence as sufficient on its own without any lightweight ambient monitoring - a purely scheduled system with no monitoring in between reviews will still be blindsided by changes that mattered before the next scheduled check arrived.

Key takeaways / mental model#

This subject's other six lessons will be wrong by the time you read this one, to varying degrees - that is the expected, designed-for outcome, not a failure of authoring. What outlives them is the method: find the primary source before trusting a secondary summary, evaluate any source's currency/relevance/authority/accuracy/purpose before treating it as fact, and run a two-speed cadence - lightweight ambient monitoring plus a calendared, forced deep review - rather than either constant panic or comfortable neglect. This repository's own agent-docs/fast-moving-domain-policy.md is not a special case of this lesson; it is this lesson, already built and already running, one calendar-triggered review at a time.

Self-check questions#

Explain the structural reason a stale secondary source about a fast-moving field is more dangerous than a stale secondary source about a stable field, using this lesson's own research experience (the OpenAI model-family naming discrepancy) as a concrete example.
Walk through the CRAAP framework (Currency, Relevance, Authority, Accuracy, Purpose) against a specific claim from landscape-snapshot/05 or /06 of your choosing - which criterion would have caught a problem first, and why?
Why does this lesson argue that "monitor everything continuously" is not actually a more reliable practice than a calendared two-speed system, despite sounding more thorough? What failure mode does each approach risk that the other does not?
agent-docs/fast-moving-domain-policy.md's next_review mechanism is presented in this lesson as an instance of a general pattern, not a repository-specific quirk. Design an equivalent cadence for a team tracking a fast-moving dependency (e.g., a rapidly-evolving open-source library) outside this repository - what would the "calendared deep review" and "lightweight ambient monitoring" look like concretely?
A learner reads landscape-snapshot/05, notes it is past its next_review date, and asks you what the current model pricing actually is. What should you tell them to do, and what should you explicitly not do (in terms of trusting your own memory of the lesson)?
This lesson is tagged durability: durable despite living inside the one subject in agentic-engineering built to be perishable. Explain, in your own words, why that placement is consistent rather than contradictory, using agent-docs/fast-moving-domain-policy.md's own definition of durable vs. perishable.

References#

This repository's own agent-docs/fast-moving-domain-policy.md, as the primary, inspectable case study for this lesson's central pattern.
Web Literacy for Student Fact-Checkers and related library-science guides on the CRAAP test (Currency, Relevance, Authority, Accuracy, Purpose) for source evaluation - general information-literacy practice, not AI-specific.
Purdue OWL, Evaluating Sources and Willamette University Libraries, Primary vs Secondary sources - general primary-vs-secondary source evaluation guides.
Built In, Chicago Software Engineers Share Their Hack for Staying Current: Learn With Intention (2026).
landscape-snapshot/05 and landscape-snapshot/06, whose own authoring research (documented in their front matter and in this lesson's worked examples) supplied the concrete primary-vs-secondary discrepancies referenced above.