Lists of agent toolkits are everywhere: a framework, a vector database, a memory layer, an MCP server or two, browser automation, an observability tool, a durable workflow engine, an evaluation library. Each list is presented as the stack serious teams use. Most will be partly out of date within a year, because the tools in this market are being released, renamed, merged and abandoned at a pace no list can keep up with.
That volatility is a reason to be deliberate, not a reason to wait. Teams still need to build agents now. The question is how to choose tools in a way that survives the next round of change.
CloudNala's view is that an agent toolkit should be defined by a small set of capabilities every production agent needs, a second set added only when a named requirement appears, and an optional set that must prove itself first. Specific products sit behind those capabilities and can be swapped. The capabilities last longer than the tools.
This is the final part of The Agentic Enterprise. Part 4 built the organisation-wide capability map. This part applies the same thinking to the toolkit a delivery team works with day to day.
Karoo's starting point
Karoo Mills is fictional, and its systems and figures are illustrative. After the capability review, Karoo's platform team was asked to publish a standard toolkit for any team building an agent. The first version listed fourteen components. Several were there because one team had used them once. Two overlapped. One had changed its licence terms during the pilot. Nobody could say which were mandatory.
The second version started from a different question: what does every production agent at Karoo need, regardless of what it does?
Core: what every production agent needs
Karoo's core tier has five items. Each one is there because an agent without it cannot be operated safely.
Model access through one route. Agents call models through a shared gateway or a single approved client, not through keys embedded in each application. This gives one place for budgets, attribution and changing providers. It does not make the gateway the whole platform, a point our series The Model Gateway Is Not the AI Platform develops in detail.
Tool contracts. Every tool an agent can call has a written contract: inputs, outputs, errors, side effects, the identity it acts under and whether it is safe to retry. We covered what good tools look like in Tools: how AI agents actually do work.
Tracing. Every run records its model calls, tool calls, inputs, outputs, timings and cost against a thread ID. Without it, no one can debug, evaluate or cost the agent. As A trace is not an evaluation argues, tracing is necessary but not sufficient.
An evaluation set. A maintained set of test cases with expected behaviour, run before every release. Small is fine to start; absent is not.
Identity. Agents act on behalf of a verified person or a named service, with scoped access, as Parts 2 and 3 of this series described.
Notice that none of these is a product name. Karoo picked a product for each, but the standard specifies the capability and the acceptance test ("every tool call appears in the trace with its identity and outcome"), so a product can be replaced without rewriting the standard.
Conditional: when a requirement appears
The second tier contains capabilities that are valuable for some agents and wasteful for others.
- Retrieval earns its place when the agent must answer from content that changes independently of the agent: policies, product catalogues, procedures. If the knowledge is small and stable, putting it in instructions may be simpler.
- Memory earns its place when users return and expect continuity across separate pieces of work, and when the organisation has decided what may be remembered and for how long. Our Memory Is an Architecture Decision series covers the rules.
- A durable workflow engine earns its place when runs wait for people or deadlines, as Part 1 showed. A short question-and-answer agent does not need one.
Each conditional item comes with its trigger written down. A team adding memory must state the requirement it meets.
Optional: prove it first
The third tier is where most fashionable tools sit: multi-agent frameworks, browser automation, graph databases, a second vector store, specialised agent memory products. Some will become core over time. Until then, each needs a named problem, a small trial and evidence.
Browser automation is a good example. It lets an agent operate a website the way a person would, which can be the only option for a legacy system with no API. It is also slow, brittle when pages change, and hard to scope securely. Karoo allows it only where no API or integration exists, with a written exit plan to replace it when one does.
Five gates for anything new
When a team proposes a new tool, Karoo applies five gates in order.
- Names a real problem. Which requirement, in which agent, does this meet that the current toolkit does not?
- Fits identity and audit. Can it act under a verified identity with scoped access, and does it leave records the organisation can keep?
- Can be traced and evaluated. Do its actions appear in the trace? Can its behaviour be tested before release?
- Exit cost is known. If the product disappears, changes its licence or doubles its price, what does replacing it involve?
- Has a named owner. Who maintains it, upgrades it, watches its security advisories and answers for it?
A tool that fails a gate is parked, with the reason recorded. That record stops the same debate from restarting every quarter, and it lets the team revisit the decision when the reason no longer applies.
The fourth gate is easy to skip and expensive to ignore. Several popular agent tools in the past two years have changed licences, been acquired or stopped being maintained. A tool with a low exit cost (a library behind a thin interface) can be adopted more readily than one that shapes how every agent is built.
Security belongs in the toolkit decision
Every tool an agent uses is code that runs with access to prompts, data and sometimes credentials. Agent skills, plugins and MCP servers are executable dependencies, and they need the same scrutiny as any other production dependency: provenance, pinned versions, review before upgrade and least privilege. Our series The AI Software Supply Chain covers this in depth. For the toolkit, the practical rule is simple: no component enters the core or conditional tiers without a named owner who watches its updates.
The series in one line
Across five parts, The Agentic Enterprise has made one argument from several directions. Agents become enterprise systems when they have durable state, accountable handoffs, real integrations, an owned capability architecture and a toolkit chosen by requirement. None of those depends on which model is best this month.
For the series from the start, return to Part 1, An agent without durable state cannot own a long-running process. All parts are on the series page. For readiness questions before the first agent, see Is your organisation ready for agentic AI?.
How CloudNala can help
We help platform and delivery teams define an agent toolkit by capability: the core every agent needs, the conditional items with their triggers, and the gates for anything new. We then map existing tools against it, identify exit risks and ownership gaps, and document a standard teams can actually follow.
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