Nasdanika

When Architecture Reads the News

Why the true consumer of technology updates isn’t your attention — it’s your architecture repository

Published on Medium on July 19, 2026. Tags: Agentic AI, Knowledge Management, Model Driven Engineering, GitOps, Software Engineering

When Architecture Reads the News

On a recent developer community call the conversation turned to a familiar complaint: we are drowning in news. Releases, deprecations, new models, new frameworks, security advisories. The proposed remedy was equally familiar: better targeting. Java developers should get Java news, React developers should get React news.

Reasonable. Also, I think, aimed at the wrong reader.

The feed is not the answer

The industry’s standard answer to information overload is a personalized feed. daily.dev does this well: two thousand sources, AI ranking, a daily briefing. If the goal is to keep a human pleasantly informed, that lane is served, and I have no intention of competing in it.

But ask a different question: why does a release announcement matter to you professionally? Not because it is interesting. It matters when it invalidates or reinforces something you have decided. A release fixes the bug you wrote a workaround decision around. A model vendor changes pricing and flips the economics of an architecture choice. A framework deprecates the API your integration standard depends on.

In other words, the natural consumer of most professional news is not your attention. It is your repository: the place where your decisions are recorded. A feed can only interrupt you. A repository could act.

Developers and technologies are a graph

Here is the mental model I keep returning to. Developers are nodes in a graph. So are technologies. A Java developer connects to Java, a UI developer connects to React, and both connect to shared things: the build pipeline, version control. Teams, components, and architecture repositories are nodes too.

News is emitted by nodes and travels along connections. Each traversal attenuates the message’s strength. When the same message reaches you through several paths, the strengths add up. The effect is exactly what targeting is supposed to achieve, but emergent rather than configured: things close to you, or reachable through many of your connections, arrive loud; distant single-path noise fades to nothing. Readers of my earlier stories will recognize the family: this is messaging over executable graphs, and the propagation semantics belong to the same lineage as Waypoint.

Nodes are not passive relays. A node can accumulate messages for a day and emit one AI-generated digest: backpressure applied to human attention. It can filter by type, gate on strength, or, and this is where it gets interesting, trigger an agent.

Git is the substrate

None of this needs a platform. A developer defines their node in Markdown, YAML or Groovy DSL in their personal repository and, via a pull request to a shared registry or a server-wide scan, becomes discoverable. Technology nodes live in their own repositories. Message delivery is a commit into an updates/ folder, or a pull request. Propagation runs on scheduled scans or commit hooks. Identity, history, provenance, and access control come free with Git: signed commits tell you who really emitted a message, repository permissions decide who may deliver where.

If this sounds like GitOps, it should. GitOps already treats the repository as a message bus and the commit as an event; controllers watch and reconcile. Renovate and Dependabot already deliver one narrow genre of news, version updates, as pull requests, and the world has accepted that interaction completely. I am proposing to generalize the pattern from deployment manifests and lockfiles to organizational knowledge.

And not everything worth reacting to lives in Git. In most organizations the decision-relevant news sits in Confluence spaces, Jira projects, office documents, and vendor web pages. Those enter the graph through snapshot gateways: a connector pulls the source on a schedule, stores a snapshot as a model in a repository, and the diff between consecutive snapshots becomes the message. Picture a central AI group that publishes its catalog of approved models on a Confluence page. A scheduled pull snapshots the page; the day a new frontier model appears in the catalog, the diff propagates to every architecture repository whose model-selection decision cited the old catalog. There is a quiet bonus here: a decision can cite the snapshot commit rather than a live URL, so “what did the source say when we decided” stays verifiable long after the page has changed or vanished.

The part that actually matters

Targeted news for humans is the visible motivation. The durable value is one step further, in architecture as code.

A message lands in the updates/ folder of an architecture repository. It triggers an architect agent. The agent scans the repository, decision records in particular, and asks: what does this change? Perhaps there is an ADR whose stated premise is the very bug this release just fixed. Perhaps a new LLM announcement flips a model-selection decision. The agent drafts the modifications, opens a pull request with evidence quoted and cited, and assigns it to a human reviewer. The human decides. Only the human decides; research on LLM-based decision checking is quite clear that these systems belong in hybrid workflows, as early warning rather than final word, and the security lesson of the bot-PR era is that automated pull requests must earn trust with evidence.

Now notice what happens after the merge. The accepted decision change is itself news. It becomes a message to every repository that depends on that decision, traveling the same graph with the same attenuation. Decisions form a dependency graph across repositories; change propagates along it and terminates naturally instead of flooding.

Release notes become messages. Decision changes become messages. The architecture stops being a snapshot that decays from the moment it is written and becomes something closer to a nervous system: the outside world changes, the change travels to exactly the artifacts it affects, and a human is presented with a reviewed, evidenced proposal instead of a feed item.

What exists and what doesn’t

Every piece of this has prior art, which is a feature. Backstage put the organization’s technology graph into YAML in Git, but the catalog is passive. Renovate delivers news as PRs, but only version news, assessed against manifests rather than decisions. ADR tooling and recent research can review decisions competently, but assume someone decides when to run the review. The missing piece is the connective tissue: an explicit, owned graph over which news travels to the artifact it affects, arriving as a reviewable commit that wakes an agent. That is the piece I intend to build, in the open, as part of the Nasdanika Product Management model’s neighborhood.

Conclusion

If your organization records decisions at all, ask yourself one question: when the world changed last month, how many of your recorded decisions quietly became fiction, and how would you know? If the honest answer is “we wouldn’t,” that is the problem worth solving, and I would like to hear how you would solve it.

Resources

Landscape:

AI + decision records: