The loop is where the edges come from. Context goes to the model, the model picks a tool, the tool layer runs it, the result lands back in context, and the model decides whether the answer is good enough or another reasoning cycle is warranted [10]. Every one of those decisions adds an edge after deployment [12]. That is the specific reason the old deliverable stops working: you cannot project TPS per downstream service from a diagram whose branch count is chosen while the request is in flight [4][9].
So I have stopped asking teams for the path and started asking for the boundary. In my context, which is customer-facing and internal agentic services with real users, the reviewable artifact is a short list of caps: iterations per request, spend per request, the tool allowlist for each agent role, and which of those tools hold write credentials. Those are pre-deploy facts. They hold whatever the model decides at step seven. The author of the source post makes the weaker version of the same argument, saying the graph can be constrained and must be [12], and he notes that treating the new edge cases as best-effort stopped being tenable once real products shipped agentic flows [17].
The lens gives you the grid to work through rather than the answers. It keeps the six pillars and reinterprets each one through five characteristics [14], which is thirty pillar-by-characteristic cells per review [16]. Nobody's review calendar grew by the same factor.
Before you adopt the grid, check that its premises describe your system. The five characteristics are load-bearing only if the model actually chooses tools without instruction at each step and retains state across sessions [14]. Traditional ML did not qualify: the model was a component with a latency budget, not a decision-maker [6]. A prompt chain with fixed edges and one inference node is closer to that case, and ordinary WAF still covers it. The parts of an agentic stack that also stay covered are the wire protocols, since MCP and A2A remain request-response and rate-limit and observe as before [7], and the individual components, which harden without much reinterpretation [8]. The gap sits one layer up, at the orchestration that composes them. Memory is the piece that resists caps: it carries privacy, integrity and cost problems stateless REST services never had [15], and a request that looks isolated inherits whatever earlier sessions left behind [11].
Two caveats on the evidence. This is one practitioner's account, published on dev.to by an engineer who has run reviews at Amazon retail, AWS, his own startup and now healthcare [1], and the passage where he says Google's Cloud Architecture Center describes the same shift in nearly identical terms is cut off mid-sentence in the copy we have [18][19]. The claim about AWS's stated scope is quoted from that post, not from the lens itself [13].
