By the end of its review, Sneeuberg Insurance's platform team had a dated matrix of twenty repositories, a clear separation between orchestration and tool protocol, and scenario-based guidance on five frameworks. Sneeuberg Insurance is fictional, and its teams, systems and figures are illustrative. What it did not yet have was a stack. The draft architecture for the first production agent had fourteen boxes, and the head of claims operations asked a fair question: which of these do we actually need for the first agent, and who will look after each one when the project team has moved on?
That question is the subject of this final part. Its argument is in two halves. First, the right stack is the smallest one that meets the agent's autonomy tier, and the tier, not the ambition, decides what is required. Second, every component that survives the cut needs an owner, including the free ones. Open source removes the licence fee. It does not remove patching, dependency risk, support, exit planning or decommissioning.
Start from the autonomy tier
Most stack debates start from components. Start instead from what the agent is permitted to do, because each step up in authority adds requirements that cannot be skipped.
Sneeuberg uses four tiers.
Tier 0: assist. The agent drafts, summarises or answers from approved content, and a person does everything that matters. The minimum stack is model access through one approved route, versioned instructions, tracing, a small evaluation set, the user's own identity and a data classification for what may be sent to the model.
Tier 1: read. The agent calls tools that read from business systems. Add written tool contracts, a scoped service identity for each tool, retrieval that respects the user's permissions, and logging of every tool call.
Tier 2: recommend with approval. The agent prepares an action and a person approves it. Add durable state so the run can wait for the person, an approval recorded in the system of record against the approver's identity, and authority rules enforced by that system rather than by the agent.
Tier 3: act within limits. The agent executes bounded actions on its own. Add delegation limits checked server-side on every action, budget and rate limits, a tested way to stop the agent and reverse what it did, an incident runbook, and continuous evaluation that can block a release.
What belongs in an agent toolkit sorts agent capabilities into core, conditional and optional. The tier is what tells you which of the conditional ones this agent actually needs.
Sneeuberg's household claims triage agent is a tier 2 agent. It recommends a route and, for fast-track claims, a payment, and a handler approves. That single decision removed several boxes from the draft. A separate long-term memory product, a second vector store, browser automation and a multi-agent layer all belonged to requirements the agent did not have. The same reasoning, applied to cloud operations agents, appears in From read to write: the authority ladder.
Build, buy, reuse or avoid
With the tier set, each remaining component gets one of four decisions. The default order of preference is reuse, then adopt or buy, then build, because reuse adds the least new ownership.
| Component | Sneeuberg's decision | Reason |
|---|---|---|
| Identity provider and workload identities | Reuse | Already operated, audited and integrated with HR leavers |
| API gateway and logging | Reuse | Existing control point; extended with an allow-list per agent |
| Observability stack | Reuse | Agent traces exported over OpenTelemetry to the existing backend |
| Case management system | Reuse | The approval and the evidence belong in the claims record |
| Model access | Buy | Managed model service in the insurer's cloud region, under contract |
| Orchestration framework | Adopt open source | Pinned version behind a thin internal interface |
| MCP servers for policy, claims and documents | Build | Nobody else can describe Sneeuberg's systems or enforce its rules |
| Evaluation set and authority rules | Build | They encode the business's own judgement and delegation matrix |
| Long-term memory product | Avoid, for now | No requirement at tier 2; revisit with a named use case |
| Browser automation | Avoid | Every target system has an API |
| Multi-agent framework | Avoid | One process, one owner, one agent |
Two patterns in the table are worth naming. What Sneeuberg builds is the part that encodes its own business: tool contracts, authority rules and evaluation cases. What it reuses is the part it already operates well. The open-source framework sits in the middle, adopted but wrapped, so that the decision can be reversed. Buy, build or grow? discusses how cheaper code changes the procurement side of this decision.
Open source does not remove platform ownership
The orchestration framework costs nothing to download. It is not free to own. Sneeuberg's platform team wrote down five responsibilities that come with every adopted open-source component, and named a person for each.
Patching. Someone watches the project's releases and security advisories, assesses each one, and upgrades on a schedule. Agent frameworks in this market release often. In part 1's check on 7 November 2026, most of the twenty repositories had published a release within the previous two months, and several were on pre-1.0 version lines where breaking changes are expected. An upgrade is a production change and needs the same evidence, as An MCP upgrade is a production change argues for tool servers.
Dependency risk. A framework brings its own dependencies, and those bring theirs. The owner keeps a software bill of materials, pins versions, and knows what to do when one of them is compromised. What to do when an AI dependency is compromised sets out the response.
Support. Community support is valuable and has no service level. The owner decides, before the first incident, whether that is acceptable for a tier 2 agent or whether a commercial support arrangement or deeper in-house expertise is needed. "We will raise a GitHub issue" is a support plan only for problems that can wait.
Exit planning. Projects are renamed, relicensed, superseded and archived. Part 3 recorded a real example: Microsoft's AutoGen README now says the project is archived and no longer maintained, and directs users to Microsoft Agent Framework, checked on 7 November 2026. A team that built on it now has a migration it did not schedule. Sneeuberg's exit plan for its framework is three lines: the internal interface the framework sits behind, the format its checkpoints are stored in, and an estimate of the effort to move to the second-choice framework.
Decommissioning. Every agent will eventually be retired or replaced. The owner knows, in advance, what retiring it involves.
None of this argues against open source. Open source does not mean low risk or high risk makes that case. The point is narrower: adoption is the start of an ownership commitment, and the commitment needs a name next to it.
Plan the decommissioning before the launch
Retiring an agent is not the same as switching it off. Sneeuberg's decommissioning checklist for the triage agent has seven steps, written before go-live.
- Stop new runs, and let in-flight runs finish or hand them to the manual queue with their state.
- Revoke the agent's workload identity and every credential issued to it.
- Remove its MCP server registrations and gateway allow-list entries.
- Apply the retention policy to checkpoints, traces and any stored conversation data. These can contain personal information, so retention and deletion follow the insurer's POPIA-aligned records policy. This is general information, not legal advice.
- Keep the case records, which belong to claims, not to the agent.
- Archive the evaluation set and the final version of instructions and tool contracts, so a later audit can reconstruct what the agent did.
- Record the retirement decision and its reason in the architecture record.
Archived does not mean failed covers the organisational side of retirement. The technical side is simpler if it was planned before the first run.
Cost and supportability
The smallest stack is also the cheapest to support, and the saving is mostly people, not licences. Each additional component needs someone to upgrade it, monitor it, understand its failure modes and answer for it in an incident. Sneeuberg estimated support effort per component in a simple, illustrative way: a reused component adds little, an adopted open-source component adds a recurring share of an engineer's time for patching and upgrades, and a built component adds its maintenance plus its evaluation cases.
On that basis the draft fourteen-box architecture would have needed roughly twice the ongoing ownership of the eight-component stack it chose. The exact ratio is illustrative and will differ for every organisation. The direction will not.
Cost also lives in the defaults. A framework that sends traces to a vendor by default, a workflow tool whose licence restricts multi-tenant use, or a memory product that stores everything it extracts can each create cost later, in compliance work, renegotiation or data clean-up. Checking defaults is cheaper than reversing them.
A minimum-stack checklist
| Question | Required at tier |
|---|---|
| Is the autonomy tier written down and agreed with the business owner? | All |
| Does every component trace to a requirement of that tier? | All |
| Is each component marked build, buy, reuse or avoid, with a reason? | All |
| Does every adopted open-source component have a named owner for patching? | All |
| Is there a software bill of materials with pinned versions? | 1 and above |
| Is the approval recorded in the system of record, not only in the trace? | 2 and above |
| Is authority enforced by the system of record on every action? | 2 and above |
| Has stopping and reversing the agent been tested? | 3 |
| Is there an exit plan for the framework and the model service? | All |
| Is the decommissioning checklist written before go-live? | All |
For the broader question of whether a system is ready to go live at all, see What does production-ready actually mean?, and for the governed foundation the agent runs in, see Agentic landing zones.
Key points
- Let the autonomy tier decide the minimum stack. Each step from assist to read, recommend and act adds requirements that cannot be skipped.
- Prefer reuse, then adopt or buy, then build. Build what encodes your own business: tool contracts, authority rules and evaluation cases.
- Open source removes the licence fee, not the ownership. Name an owner for patching, dependency risk, support, exit planning and decommissioning.
- Write the exit plan and the decommissioning checklist before go-live.
- The smallest stack is cheapest mainly because it needs fewer people to keep it safe.
This is part 4, the final part, of Building an Enterprise Agent Platform Without Buying Everything. Previous: Framework, SDK, workflow tool or agent platform?. To start the series from the beginning, read Twenty agent repositories, five capability families.
How CloudNala can help
CloudNala helps platform teams cut a proposed agent architecture down to the smallest stack that meets its autonomy tier. We set the tier with the business owner, trace every component to a requirement, mark each one build, buy, reuse or avoid, and write the ownership record for each open-source component: who patches it, how it is supported, how you would leave it and how the agent will be retired.
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 Agent Platform Review or write to us at consult@cloudnala.co.za