all-agentic-architectures: 35 agentic AI patterns as runnable Python classes

The problem: 35 papers, 35 incompatible scaffolds

Agentic AI patterns arrive as papers, not as code. Reflexion, LATS, GraphRAG, MemGPT and Voyager each describe a control loop, and each reference implementation uses its own class names, its own return shape and its own assumptions about the LLM behind it. If you want to know whether Tree of Thoughts beats Self-Consistency on your task, you first have to build both, and the comparison is only fair if both were built the same way.

This repository attacks that directly. According to the README, it packages "every major agentic AI pattern from the literature as a runnable `Architecture` class with a uniform contract." The contract is the product. Every architecture exposes `.run(task)` and returns the same `ArchitectureResult` shape, so swapping Reflection for Reflexion is a one-line change in your code, not a rewrite. The README's own example makes the pitch: "Swap the class, swap the pattern. Your downstream code does not change."

The audience is narrow and identifiable. This is for engineers who already know what an agent loop is and need to pick one, and for people who learn a pattern faster from an executed notebook than from a paper. It is not for someone who wants a managed agent service, and it is not a LangGraph replacement. It sits on top of LangGraph state machines, which pyproject.toml confirms as a core dependency (`langgraph>=0.2.50`).

How the uniform Architecture contract actually works

The README describes the mechanism in one sentence: each pattern is a runnable `Architecture` class built on top of LangGraph state machines. The provider layer is separate. `get_llm()` reads `LLM_PROVIDER` and `LLM_MODEL` from the environment and returns a client, so the architecture code never names a vendor. Nine providers are listed in `.env.example`: nebius, openai, anthropic, groq, ollama, together, fireworks, mistralai and google. Setting `LLM_PROVIDER=ollama` with `OLLAMA_BASE_URL=http://localhost:11434` keeps everything local; setting `LLM_PROVIDER=nebius` sends the same calls to a hosted endpoint. No architecture file changes either way.

The second mechanism is the one worth arguing about. The README calls it the deterministic-picker pattern: "every LLM-as-Scorer surface has the LLM commit to categorical features (booleans, enums) and lets Python compose the deciding signal." The stated reason is the flat-band pathology, where an LLM asked for a 1-to-10 score returns 7 or 8 for almost everything, so the score carries no ranking information. Forcing a boolean or an enum and doing the arithmetic in Python removes that failure mode. The README says this is applied in 13 of 35 architectures, with 9 more described as architecturally immune by design. That is a specific, falsifiable claim about the codebase, and it is the most useful thing in the README.

The architecture families are grouped in the README as Reasoning & Reflection (Reflection, Reflexion, Chain-of-Verification, Self-Discover, Constitutional AI), Sampling & Search (Self-Consistency, Tree of Thoughts, LATS, Mental Loop, Ensemble), Retrieval (Agentic RAG, Corrective RAG, Self-RAG, Adaptive RAG, GraphRAG), Memory (Episodic + Semantic, Graph Memory, MemGPT, Voyager, Agent Workflow Memory) and Tools & Actions (Tool Use, ReAct, Planning, PEV, SWE-Agent, Computer Use).

Install and run your first architecture

The README's quickstart installs from PyPI with three extras. The extras matter: `faiss` is needed for the retrieval architectures, `tavily` for the web-search tool architectures, and `nebius` for the provider client. Pick the extras that match the architectures you intend to run.

pip install "agentic-architectures[nebius,faiss,tavily]"

Then set your provider in the environment. `.env.example` ships the full list and instructs you to copy it to `.env` and fill in your own values. Only the key for the provider you selected needs a value.

cp .env.example .env
# then edit .env
LLM_PROVIDER=nebius
LLM_MODEL=meta-llama/Llama-3.3-70B-Instruct
NEBIUS_API_KEY=your-key-here

The README's first real use is a Reflection loop. `max_iterations=2` and `target_score=8` are constructor arguments, and the result carries both the output and the final score in `metadata`.

from agentic_architectures import get_llm
from agentic_architectures.architectures import Reflection

arch = Reflection(llm=get_llm(), max_iterations=2, target_score=8)
result = arch.run("Write a haiku about a glacier.")

print(result.output)
print("score:", result.metadata["final_score"], "/ 10")

To swap patterns, change the import and the class. The call site stays `arch.run(task)`. If you prefer to work from a clone, the README's collapsed section gives the full path: create a virtualenv, install with `pip install -e ".[dev,test,docs,nebius,faiss,tavily,networkx]"`, copy `.env.example` to `.env`, and run `pytest -q`, which the README says passes 283 tests in roughly 30 seconds.

Where the uniform contract costs you something

A shared `.run(task)` signature is a constraint, not a free abstraction. MemGPT manages a paged memory hierarchy across turns; Self-Consistency samples the same prompt many times and votes. Both are forced through one entry point that takes a task and returns one result. If your application needs to inspect or steer the intermediate state of a specific architecture, the uniform surface is in the way, and the README does not document an escape hatch for that.

The provider abstraction has the same shape of problem. `.env.example` sets one provider for the entire process: "every notebook + every architecture in the library will use whichever provider you set here." That is convenient for a benchmark run and awkward for a pipeline that wants a cheap model for routing and an expensive one for the final answer. Nothing shown here demonstrates per-architecture provider overrides, though the constructor accepts an `llm` argument, so passing a different client per instance is the obvious route.

The README also does not document failure handling. There is no described behavior for a provider timeout, a rate limit, or a response that does not parse into the expected enum. `tenacity>=8.2` is a core dependency, which suggests retry logic exists somewhere, but the README does not say where it applies. If your workload depends on knowing exactly what happens when the third retry fails, you will be reading the source, not the docs.

Finally, the cost profile. LATS grows a tree with rewards, Tree of Thoughts branches, Self-Consistency samples repeatedly. These are token multipliers by construction. The README's 17-task benchmark compares architectures, but it does not present a per-architecture token or latency column in what is documented here, so you cannot budget from the README alone.

Choosing between this and a general agent framework

LangGraph is the closest real alternative, and it is not a competitor so much as the layer underneath. LangGraph gives you the state machine, the graph primitives and the checkpointing. It does not tell you which pattern to build. If you already know you want a ReAct loop with a specific tool set, writing it directly in LangGraph is fewer moving parts than adopting a library whose value is breadth.

The difference in approach is the point. LangGraph is a construction kit; all-agentic-architectures is a catalogue of finished constructions, each one already wired to a provider-agnostic LLM client and already documented in an executed notebook. That is worth the dependency when you are still deciding, and it is dead weight once you have decided.

A second comparison is the notebook itself. The README states that each pattern "ships with a fully executed Jupyter notebook whose theory is written against the captured run, not synthetic examples," and the repository's primary language is listed as Jupyter Notebook. If you learn by reading code next to its real output, a paper plus a reference implementation in another repo is a worse fit than this. If you want a minimal, single-purpose implementation you can read in ten minutes, this repository is the wrong size.

Maintenance, licence and upgrade cost

The repository is not archived. Its last push was on 2026-06-22, and the most recent release is v0.3.0 on 2026-05-28. pyproject.toml declares `Development Status :: 4 - Beta`, so the API is not presented as frozen. The version string in pyproject.toml is `0.3.0`, matching the release tag.

Upgrade cost is dominated by the dependency floor, not by this package. Core dependencies include `langchain-core>=0.3.0`, `langchain>=0.3.0`, `langgraph>=0.2.50` and `langsmith>=0.1.130`. LangChain and LangGraph move quickly, and a lower-bound-only pin means a fresh install can pull a version the library was never tested against. If you pin your own lockfile, expect to re-resolve when you bump any of those four. `requires-python` is `>=3.10`, with classifiers for 3.10, 3.11 and 3.12.

On licence: the project is MIT, declared both in the README badge and in pyproject.toml as `license = { text = "MIT" }`. MIT is permissive, but that says nothing about the licences of the optional extras you install. `faiss` and `tavily` are separate packages with their own terms, and the provider SDKs you pull in through extras carry theirs. Check those independently; this article is not legal advice.

Editorial conclusion

Adopt it if you are choosing between agentic patterns and want to compare Reflection, Reflexion, LATS, GraphRAG or MemGPT behind one .run(task) contract instead of reading five papers and writing five scaffolds. Skip it if you need a hardened runtime: pyproject.toml still declares Development Status 4 - Beta, and the README does not document rollback, retry semantics or what happens when a provider returns malformed categorical output. Before you commit, check the PyPI version against v0.3.0 (2026-05-28) and run the test suite from a fresh clone to confirm 283 tests pass on your Python version.

Frequently asked questions

Official sources

1. FareedKhan-dev/all-agentic-architectures on GitHub
2. License: MIT
3. Project website
4. README
5. Releases