Every few months a new AI ecosystem map circulates. Models in one corner, vector databases in another, agent frameworks, evaluation tools, guardrails, observability, memory, gateways, browser automation, each category packed with logos. They are impressive pieces of research, and they are shared widely because they capture how crowded the market feels.
They are also a poor basis for decisions. A logo map answers "what products exist?" An organisation needs to answer different questions: what jobs must be done for our AI systems to work safely, which of those jobs do we already do, who owns each one, and which product, if any, should help? A logo map has no relationships, no owners and no sense of what depends on what. Teams that plan from one tend to buy a product per category and end up with tool sprawl and unclear ownership.
CloudNala's position is that AI adoption should be planned from a capability architecture: the jobs the organisation needs done, how they depend on each other, how mature each one is and who owns it. Products are chosen last, to fill named gaps.
From logos to jobs
Karoo Mills is fictional, and its systems and figures are illustrative. By the time its HR agent was in production, Karoo had accumulated nine AI-related tools across three teams. The HR delivery team used one agent framework, the finance team had trialled another, and the data team had stood up a vector database for an analytics assistant. The rest included two model providers, a guardrail library, an evaluation tool used by one team, and tracing that covered only the HR agent.
Asked to present Karoo's "AI architecture", the platform team's first attempt was a slide of those nine logos arranged by category. The steering committee's response was the right one: which of these do we need, and who is responsible for them?
The second version described capabilities instead. Each capability is a job, stated in business-neutral language, that any production agent at Karoo relies on:
- Business workflows: the processes agents take part in, and the systems of record that own them.
- Agent runtime and orchestration: where agents run, how their state persists, how long runs are scheduled and resumed (see Part 1).
- Models, routing and gateway: access to models, routing between them, budgets and attribution.
- Data, retrieval and memory: the content agents answer from and what they may remember.
- Identity, policy, evaluation and audit: who agents act for, what they may do, how quality is tested and what is recorded.
That is not the only valid breakdown. The point is that each layer is a job someone can own, and each depends on the ones beneath it.
The question a logo map cannot answer
Once the jobs are named, the useful view is a simple table: capability, current status, owner.
Karoo's table made two things obvious that the logo slide had hidden.
First, the most serious gaps were not missing products. Karoo had an evaluation tool. Nobody owned evaluation as a capability, so only one team used it and nothing stopped an untested agent change reaching production. The same was true of tracing and cost per case: one agent was instrumented, the others were not, and no one was accountable for the gap.
Second, some apparent duplication was harmless and some was not. Two agent frameworks used by two teams was tolerable for now. Two different approaches to identity for agents was not, because it meant two different answers to "whose authority is this agent acting under?"
Dependencies change the order of work
A capability map also shows sequence. Evaluation depends on tracing: you cannot judge behaviour you cannot see. Cost per case depends on tracing and on identity, because cost must be attributed to a workflow and a consumer. An agent registry depends on ownership being agreed, because a registry without owners is a list.
Karoo's resulting plan was short and unglamorous:
- Assign owners to the two unowned capabilities: evaluation, and tracing with cost per case.
- Make tracing a requirement for every agent in production, using the tool already in use.
- Extend the existing evaluation tool to all agents and make passing evaluations a release condition.
- Standardise identity for agents across teams before any new agent goes live.
- Revisit the duplicate frameworks in six months, with usage evidence.
No new product was bought. Several existing ones started being used properly.
How to build your own capability map
The method works for any organisation and takes a few workshops, not a programme.
List the jobs, not the tools. Start from what a production agent needs to be trustworthy: where it runs, what it knows, who it acts for, what it may do, how it is tested, what it records, what it costs. The 48 production concepts we published earlier are a useful prompt list.
Draw the dependencies. Which capability must exist before another can work? This sets the order.
Mark status honestly. In place, partial or missing, with a sentence of evidence for each. "We have a tool" is not evidence of a capability; "every production agent uses it and failures block release" is.
Name an owner per capability, by role. If no one will own it, record that. An unowned capability is a risk, whatever products sit underneath it.
Map products last. Only now place existing tools against capabilities, note overlaps and gaps, and decide whether any gap needs a product, a process or simply an owner.
Three objections, and honest answers
Karoo's steering committee raised three objections that come up in most organisations.
"Is this not just enterprise architecture paperwork?" It can become that if it grows into a hundred-row inventory. Karoo's map has five layers and fourteen capabilities, fits on one page and is reviewed quarterly. Its job is to make ownership and sequence visible, not to describe everything.
"The market moves too fast for a map." Products move fast. The jobs do not. Every production agent Karoo builds next year will still need identity, tracing, evaluation, a place to run and content to answer from. A capability map ages far more slowly than a logo map, which is the reason to plan from it.
"Our vendor's platform covers all of this." Sometimes a single platform does cover several layers, and that can be a sensible choice. The map still applies: it shows which capabilities the platform covers, which it covers partially, which it leaves to you, and who inside your organisation owns each one. A platform can supply the tooling for evaluation. It cannot supply the person who decides an agent has failed its evaluations and must not be released.
Where logo maps still help
Ecosystem maps are not useless. They are good for horizon scanning, for noticing a category you had not considered, and for vendor conversations once you know what job you are hiring a product to do. Use them after the capability map, as a catalogue to shop from, not as the architecture.
For how capability gaps show up as operating-model problems, see Agentic AI needs an operating model, not just an agent. Gateway questions are covered in depth in our series The Model Gateway Is Not the AI Platform.
Next: Part 5, What belongs in an agent toolkit. All parts are on the series page.
How CloudNala can help
We run short capability-mapping workshops that turn an organisation's collection of AI tools into a capability architecture with status, dependencies and owners, then produce a sequenced plan that fixes ownership and evidence gaps before recommending any new purchase.
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 Agentic AI Architecture Review or write to us at consult@cloudnala.co.za