The diagram arrives in a team chat with the caption "this is the whole stack, saving it for the proposal". It is beautifully drawn. A vendor's name sits at the centre, and around it, in tidy coloured lanes, are models, developer tools, an agent runtime, a protocol, a memory service, a marketplace and an enterprise governance layer, joined by confident arrows. Nobody knows who made it. It may have been drawn by a careful analyst, a marketing team, a conference speaker or a generative tool asked to "map the ecosystem". It looks authoritative, which is the problem.
A large language model can produce a fluent answer that is partly invented. A diagram can do the same thing in a different medium. Its layout implies integrations that may not exist. Its category names impose a structure the vendor never described. Its product names may be out of date by the time it is shared, and some boxes may simply have been made up. The difference is that people have learned to doubt a chatbot's prose. They rarely doubt a well-made diagram.
This article sets out a method for checking an ecosystem map before it influences an architecture decision, a procurement or a client document. It uses dated examples from first-party documentation, checked on 5 November 2026. The examples show the kinds of discrepancy to look for. They are not a ranking of any vendor, and they will age.
Why maps go wrong
Ecosystem maps fail in predictable ways, and knowing the ways makes them easier to check.
- Time lag. Products are renamed, merged, moved into preview, moved out of it or retired. A map is a snapshot, usually undated.
- Layout as claim. Two boxes placed side by side, or joined by an arrow, read as "these work together". Often the mapmaker placed them there because they belong to the same category, not because an integration exists.
- Categories as product. Lane titles such as "memory layer" or "governance plane" are the mapmaker's interpretation. They can make a loose set of features look like a coherent product.
- Generated content. Maps produced or tidied by generative tools can contain plausible names that no vendor uses, in the same way generated prose can cite papers that do not exist.
- Copying. Maps are copied and redrawn. Each redraw can drop a qualifier such as "preview" or add an arrow nobody checked.
CloudNala has made the related argument that an AI architecture should be described as capabilities, not a logo landscape, and has shown how to read the CNCF landscape without treating it as a shopping list. This method is narrower: it is a fact-check for a single map you are about to rely on.
Four labels for every box and arrow
The core of the method is to give every element on the map one of four labels, based on the evidence you can find for it.
Confirmed product. A first-party source, such as the vendor's documentation, product page or official announcement, names the product exactly as the map does and describes it as generally available. Record the source and the date you checked it.
Preview. A first-party source confirms the product or feature exists but labels it beta, preview, experimental or limited availability. Record the label, because it changes what you can promise. A preview may change behaviour, may lack support commitments and may be excluded from data-handling terms that apply to the generally available service.
Inferred architecture. The element is the mapmaker's interpretation: a category title, a grouping, or an arrow implying an integration or data flow that no first-party source documents. Inferences can be correct. They are still not facts, and they must be labelled as interpretation if the map is reused.
Invented label. No first-party source uses the name at all, and it is not a reasonable description of something that exists. Remove it. If it appears in a document your organisation has already shared, correct it.
There is one more status that cuts across the first two: stale. A product that existed under the map's name but has been renamed or retired is confirmed history and current misinformation at once.
Dated examples of what the labels catch
We use Anthropic's documentation as the worked example. The same kinds of discrepancy occur on maps of every major AI vendor.
A stale name. Anthropic's current documentation describes the Claude Agent SDK for Python and TypeScript and links to a migration guide for moving "from the Claude Code SDK packages to the Agent SDK". A map that still shows a "Claude Code SDK" box is describing an earlier name. That is a small error with real consequences if a proposal promises integration with a package name the vendor has moved away from.
A preview shown as a product. The same documentation describes Claude Managed Agents, a hosted agent harness, as being in beta, requiring a beta header, and states that it is not currently eligible for zero data retention. A map that showed managed agents as a standard enterprise service, without that status, would invite an architecture decision on terms the vendor has not offered. Similarly, Anthropic's context editing capability is documented as beta.
Governance drawn as ownership. Maps often place the Model Context Protocol inside a single vendor's ecosystem. On 9 December 2025 Anthropic announced that it was donating MCP to the Agentic AI Foundation, "a directed fund under the Linux Foundation" co-founded with Block and OpenAI. A map that draws MCP as a proprietary component of one vendor's stack misstates who governs the protocol, which matters to anyone assessing lock-in. MCP in plain language explains what the protocol does.
An arrow nobody documented. An arrow from a hosted agent service to an organisation's "enterprise data layer" implies a supported, governed integration. What first-party documentation usually describes is a mechanism, such as tool connections or MCP servers, through which your own team can build that connection, with your own identity, permissions and logging. The arrow is inferred architecture. The work, and the accountability, sit with you, as Agent capability is not agent authority argues.
The method, step by step
- Date and source the map. Record where it came from, who made it if known, and when you received it. If the map carries no date, treat everything on it as needing checks.
- Inventory every element. List each box, lane title and arrow in a simple table. It is tedious and quick, and it is the step that turns a picture into something checkable.
- Check names against first-party sources. For each product name, find the vendor's own documentation or announcement. Record the URL, the exact name used, the stated availability and the date checked. Third-party articles and other maps are not evidence for this step.
- Check each arrow. For each implied integration, find first-party documentation of that integration. If none exists, label the arrow as inferred.
- Label category titles as interpretation. Lane names are the mapmaker's model of the market. Keep them only if they help, and mark them as yours if you reuse the map.
- Record the result as claims. Each element that will influence a decision becomes a row in an AI claims register, with its grade and an expiry date. Product facts in AI move quickly; three months is a reasonable default.
- Decide what the map may be used for. A checked and labelled map may be used internally as orientation. Only confirmed and preview elements, with their status shown, belong in a client proposal, a board paper or a procurement document.
Redraw, do not annotate forever
Once a map has been checked, it is often better to redraw it than to keep a heavily annotated copy. A redrawn version should:
- show only elements you have confirmed or labelled as preview, with the status visible;
- show arrows only where an integration is documented, and draw inferred relationships differently, for example as dashed lines labelled "our design";
- carry a date, a list of sources and an owner;
- describe capabilities in your own terms, with vendor products as dated examples of how each capability might be met.
That last point turns a vendor map into an architecture view. It also makes the diagram useful after the vendor's next renaming. Architecture diagrams should be evidence makes the general case; an ecosystem map is simply a diagram whose evidence comes from outside your organisation.
When the map was drawn by an AI tool
Generated diagrams deserve the same method and one extra precaution. A generative tool asked to map an ecosystem will draw on whatever it learnt before its training cutoff, and may fill gaps with plausible names. Ask the tool for its sources and treat any it cannot provide as unsupported. Better still, give the tool the first-party documentation you have checked and ask it to draw only what that documentation describes, then review the result against the inventory. The same principle appears in Letting AI agents draw the architecture: the tool can draw quickly, and a person remains responsible for what the drawing claims.
A checklist before reuse
- Does the map carry a date and a source, and have you recorded both?
- Has every element been inventoried and given one of the four labels?
- Has every product name been checked against a first-party source, with the date of the check?
- Are preview and beta statuses visible wherever the map is reused?
- Are undocumented arrows drawn or labelled as inferred?
- Have invented and stale elements been removed or corrected?
- Do the decision-relevant elements appear in your claims register with an expiry date?
Key points
- Ecosystem maps can be wrong in the same way generated prose can: fluent, confident and partly invented.
- Label every box and arrow as a confirmed product, a preview, inferred architecture or an invented label, and watch for stale names.
- Check names and integrations against first-party sources only, and record the date of each check.
- Use checked maps for orientation; put only confirmed and clearly labelled preview elements into proposals and decisions.
- Redraw the result as capabilities with dated product examples, so the view survives the next renaming.
For related reading, see What belongs in an agent toolkit, Diagrams generated from reality and The AI claims register.
How CloudNala can help
CloudNala reviews AI ecosystem and architecture diagrams before they shape decisions. We inventory and check each element against first-party sources, label what is confirmed, preview, inferred or invented, and redraw the result as a dated capability view your architects and executives can rely on, with the claims recorded for the next review.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Architecture Review or write to us at consult@cloudnala.co.za