Twenty agent repositories, five capability families

The platform team at Sneeuberg Insurance, a fictional South African short-term insurer, was handed a screenshot. Someone in the claims division had seen a post listing "the twenty open-source repositories every AI team needs" and wanted to know which ones Sneeuberg was using. The list had a framework next to a vector database, a browser tool next to a workflow builder, and a coding agent next to a memory library. Each logo came with a popularity figure. None came with a licence, a date or a sentence about what the thing actually does.

The team's first instinct was to rank the list. Its second, better instinct was to ask a different question: what kind of capability does each repository provide, and where does its responsibility stop? A framework that manages agent state and a protocol SDK that connects tools are not competitors. A workflow builder with a restrictive licence and a graph library with a permissive one are not the same kind of decision.

This article is the result of that second question. It sorts twenty real repositories into five capability families, records the boundary of each, and dates every fact. It does not name a winner, because there is not one. It gives Sneeuberg, and you, a way to read the next list that arrives.

A list of repositories is not a stack

Popularity lists fail in three predictable ways. They mix categories, so a reader compares a memory library with an orchestration framework. They omit the boundary, so nobody can see that a browser agent brings no identity model with it. And they have no date, so a repository that has been archived, renamed or relicensed looks exactly as healthy as one released yesterday.

CloudNala has made the general case before. An AI ecosystem map can hallucinate too shows how polished diagrams drift from the documentation they summarise, and Capability architecture, not another AI logo landscape argues for mapping capabilities before products. This article applies that discipline to one specific artefact: the repository list that lands on an architect's desk with a request to "pick the stack".

The method is simple. Classify by family first, record the boundary second, verify the time-sensitive facts third, and only then form a view on adoption.

Five capability families

Every repository on a typical list falls into one of five families. The families matter more than the names, because the names will change and the families will not.

1. Orchestration frameworks decide how work moves: which step runs next, what state is carried between steps, how a run pauses for a person and how it resumes after a failure.
2. Development SDKs give a developer the agent loop itself: a model client, tool calling, structured output and tracing, with as little framework as possible around them.
3. Automation and workflow tools let people compose steps, often visually, and run them on a schedule or a trigger. Some are general automation platforms that have added AI nodes. One, a durable execution engine, is not an agent tool at all but is often what long-running agents actually need.
4. Memory, retrieval and knowledge systems store and retrieve what an agent should know or remember: documents, extracted facts, graphs of entities and relationships.
5. Action, browser and coding agents reach outside the conversation to do things: drive a browser, edit a codebase, run commands in a sandbox.

The families overlap at the edges. Several orchestration frameworks ship their own memory, and several SDKs now ship multi-agent patterns. Classify by the repository's primary responsibility, and record the overlap in the boundary column rather than inventing a sixth family.

The matrix, checked on 7 November 2026

The table below was checked on 7 November 2026 against each repository's GitHub page and API, its licence file and, for Python packages, the latest release on PyPI. "Latest" means the release GitHub or PyPI marked as latest on that date; some projects also publish beta or maintenance-line releases alongside it. The selection is a sample, not a recommendation, and inclusion is not an endorsement. Popularity figures are deliberately left out.

Three repositories were checked but left out of the table because their status is the story. The AutoGen README now says the project "has been archived and is no longer actively maintained" and points new users to Microsoft Agent Framework, although the GitHub repository itself was not yet marked read-only when checked. The Semantic Kernel README says "Semantic Kernel is now Microsoft Agent Framework", while Semantic Kernel packages continue to be released. And the Letta README says its current source code now lives in a different repository, letta-ai/letta-code. Part 3 returns to the Microsoft position in detail.

What the check changed

Running the check took less than a day, and it changed the conversation at Sneeuberg more than any ranking would have.

Names and homes move. Three of the repositories had moved or been renamed: Strands to harness-sdk, OpenHands to its own organisation, and Letta's active code to a new repository. GitHub redirects the old addresses, so nothing looks broken until a build script, a security scanner or a procurement record still points at the old name.

Licences are not one category. Most of the twenty use MIT or Apache 2.0. Two do not. n8n uses its own Sustainable Use License and describes itself as fair-code, and Dify uses a modified Apache 2.0 licence with conditions on multi-tenant use and branding. Neither fact makes these tools unsuitable. Both mean someone must read the licence against the intended use, and that is a legal question, not an engineering one. This article is general information, not legal advice.

Version numbers carry signals. Several active, widely used repositories are still on pre-1.0 version lines. That is not a defect, but it tells you to expect breaking changes and to pin versions, a point Pin the version before you pin your hopes on the platform develops.

Cadence varies. Most of the twenty published a release within the past two months. One had not published a GitHub release in over a year. Activity is not quality, and a mature tool can be quiet. But a slower cadence is a question to ask before a tool becomes a standard that forty developers depend on.

Boundaries are where the risk sits. Not one of the twenty supplies Sneeuberg's identity model, its authorisation rules, its audit retention or its incident process. Each repository is a component. The platform around it is still Sneeuberg's to build, which is the argument the rest of this series develops.

What each entry should record

A table in an article has to be short. The working matrix behind it should not be. For each repository, Sneeuberg's platform team now records nine things.

• Purpose. One sentence in the team's own words, not the project's marketing line.
• Family and boundary. What it owns, and what it explicitly leaves to the platform.
• Licence. The licence file as read, with a flag for anything that is not a standard permissive or copyleft licence.
• Maintenance. Latest release, latest commit, and any archive, deprecation or migration notice.
• Security implications. What it can reach, what it executes, and whether it sends data anywhere by default, such as traces.
• Operating model. Library, self-hosted service or hosted service, and who would run it.
• Adoption recommendation. One of four statuses: adopt, trial, assess or hold, with the reason.
• Checked on, checked by. The date and the person, so that every entry can be re-verified.
• Next check. A date, or the event that should trigger a re-check.

Notice what is missing: popularity. Stars and download counts measure attention. They say nothing about whether a component fits Sneeuberg's control boundary, and they are easy to inflate. The broader evidence questions are covered in Open source does not mean low risk or high risk, and this record is where their answers are kept.

Keep the matrix alive

A dated matrix is only useful while the dates are recent. Sneeuberg's rule is that entries marked "adopt" or "trial" are re-checked every quarter, and any entry is re-checked immediately when one of four things happens: a licence change, an archive or deprecation notice, a security advisory, or a major version release.

The re-check is cheap because the record is structured. Someone opens the repository, reads the licence file and the README banner, compares the latest release with the last recorded one, and updates the row. When a status changes, the change is recorded with its reason. A tool moved from "trial" to "hold" because its licence changed should not be quietly reinstated six months later by a team that never saw the reason.

The matrix also needs one owner. In Sneeuberg's case that is the platform architect, with each "adopt" entry assigned a named maintainer. Why an internal MCP registry needs ownership makes the same argument for tool registries, and the reasoning is identical: an unowned list decays into a rumour.

A checklist before a repository enters the matrix

For deciding which capabilities every production agent needs in the first place, What belongs in an agent toolkit sets out core, conditional and optional tiers. The matrix sits underneath that toolkit: it records the evidence for each product chosen to fill a capability.

Key points

• Classify agent repositories by capability family before comparing them: orchestration, SDKs, workflow tools, memory and retrieval, and action agents.
• Record each repository's boundary. None of the twenty supplies enterprise identity, authorisation, audit or incident response.
• Date every fact. In one day's check, three repositories had moved or been renamed, two used non-standard licences and one major project carried an archive notice.
• Leave popularity out. It measures attention, not fit.
• Keep the matrix alive with an owner, a quarterly re-check for adopted tools and event triggers for everything else.

This is part 1 of Building an Enterprise Agent Platform Without Buying Everything. Next: LangGraph and MCP solve different problems.

How CloudNala can help

CloudNala builds and maintains dated capability matrices for agent platforms. We classify the repositories and products your teams are proposing, verify licence, maintenance and default data flows against first-party sources, record each boundary and the platform work it leaves behind, and hand over a matrix with owners, statuses and re-check dates that your architecture board can use.

Background reading: the repositories' own GitHub pages and licence files, PyPI release histories, and the Microsoft Agent Framework overview, all checked on 7 November 2026.

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