all-agentic-architectures: 35 Agent Patterns Behind One .run() Contract
35 production-grade agentic AI architectures (Reflexion, LATS, GraphRAG, MemGPT, Voyager, BrowserAgent, ...) — a Python library and runnable textbook with multi-provider LLM support and a 17-task benchmark leaderboard.
At a glance
- What is it?
- FareedKhan-dev/all-agentic-architectures packages 35 agentic AI patterns as Python Architecture classes on LangGraph, with executed notebooks and a 17-task leaderboard. The uniform interface is the real product; the benchmark and the deterministic-picker doctrine are the parts worth arguing about.
- Who is it for?
- Adopt it if you need a working reference implementation of a named pattern (Reflexion, LATS, GraphRAG, MemGPT, Voyager) on top of LangGraph and you are willing to read the notebook before trusting the class. Do not adopt it as a production runtime for a latency-sensitive or cost-sensitive service, and do not treat the leaderboard as a verdict on your own workload.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 86 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is naming a pattern and then actually building it
Most teams that want a Reflexion loop or a GraphRAG retriever do not lack papers. They lack a running implementation they can read in one sitting, wired to a provider they already pay for. The README frames the repository as a library and a living textbook, and the structure backs that up: each of the 35 patterns is a runnable Architecture class plus a Jupyter notebook whose theory is written against a captured run rather than a synthetic example. The audience is engineers who have already decided which pattern they want and now need the mechanics. It is not aimed at someone asking which pattern to use. The repository answers that question only indirectly, through a 17-task benchmark leaderboard that ranks architectures against tasks.
A uniform contract is the actual interface
The README states that every architecture exposes the same .run(task) entry point and returns the same ArchitectureResult shape, so swapping the class swaps the pattern without touching downstream code. The quickstart shows the shape: Reflection(llm=get_llm(), max_iterations=2, target_score=8), then arch.run("Write a haiku about a glacier."), then result.output and result.metadata["final_score"]. That metadata dictionary is where the per-pattern differences surface, which is the honest place for them. If you have written glue code against three agent frameworks, you know how much of the work is adapter code. This design deletes the adapter. The cost is that anything pattern-specific has to travel through metadata or through constructor arguments, and the README does not document a schema for metadata. You will read the class to find out what keys exist.
LangGraph state machines underneath, and the deterministic-picker rule
The library is built on LangGraph state machines, per the README, and the topics list includes langchain and langsmith, so the dependency surface is the LangChain family. That is a real constraint: adopting this library means adopting that stack, its version churn, and its abstractions. The more interesting design choice is what the README calls the deterministic-picker pattern. Every place where an LLM would act as a scorer, the LLM is asked to commit to categorical features (booleans, enums) and Python composes the deciding signal. The README says this is applied in 13 of the 35 architectures, with 9 more described as architecturally immune by design. The stated motivation is the flat-band pathology of LLM-as-Scorer, where a model asked for a numeric score returns a narrow band of values and the ranking carries no information. Committing to an enum and letting Python decide is a defensible fix, and it is the kind of claim a reader can check by opening one of the 13 notebooks. It is also a claim the README asserts without publishing the flat-band measurements that motivated it.
Installing it and getting a first run
The documented install is pip install "agentic-architectures[nebius,faiss,tavily]", which tells you the extras are per-provider and per-tool rather than a single bundle. From a fresh clone the README gives the full path: git clone the repository, cd into it, python -m venv .venv, activate (.venv\Scripts\activate on Windows, source .venv/bin/activate elsewhere), then pip install -e ".[dev,test,docs,nebius,faiss,tavily,networkx]", then cp .env.example .env and fill in NEBIUS_API_KEY and the rest, then pytest -q. The README claims 283 tests pass in roughly 30 seconds. Treat that number as a claim to verify on your machine, not as a property of the software. The nine providers named in the README are Nebius, OpenAI, Anthropic, Groq, Ollama, Together, Fireworks, Mistral and Google, and get_llm() is the documented entry point for picking one. Ollama in that list matters: it is the only named option that keeps inference on your own hardware, which is the difference between a notebook you can run on a plane and one you cannot.
Where this is the wrong tool
The architecture families give away the cost profile. Sampling and search includes Self-Consistency, Tree of Thoughts, LATS, Mental Loop and Ensemble. Every one of those spends multiple LLM calls per task by construction. Memory includes MemGPT, Voyager and Graph Memory, which add persistent state you now have to version, migrate and clean. Tools and Actions reaches from a single search tool up to a real Chromium browser in the BrowserAgent and Computer Use notebooks, and the repository also ships SWE-Agent. A browser-driving agent is a different operational animal from a reflection loop: it needs a headless environment, it fails in ways that depend on page state, and it is not something you put behind a synchronous request handler. If your constraint is p95 latency or per-request cost, most of the search and memory families are the wrong choice regardless of how well they score. The repository does not appear to publish latency or token-cost figures per architecture, so the leaderboard ranks quality without ranking the price you pay for it. That is the biggest gap in the material.
The comparison that matters: a single-pass chain is still the baseline
The obvious alternative is not another agent framework. It is a plain prompt chain: one call, or one call plus a retrieval step, with no scoring loop and no state machine. On tasks where a single well-written prompt already lands in the right answer, Reflection with max_iterations=2 doubles your calls to fix a problem you did not have, and LATS multiplies it further. The difference in approach is the whole point of this repository: it assumes you have a task where iteration, search or retrieved grounding measurably changes the output, and it gives you the machinery for that case. The 17-task benchmark is the repository's own attempt to show where the machinery pays. Use it as a map of which patterns are worth trying on which task shapes, then verify on your own data. Do not read a leaderboard position as a prediction about your workload.
Maintenance, versioning and the MIT licence
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it is the least complicated part of adopting this code. It is not legal advice; read the LICENSE file and your own counsel's view if the stakes are high. On maintenance: the last push recorded is 2026-06-22 and the most recent release is v0.3.0 from 2026-05-28, so the project is active at the time of writing. Version 0.x signals that the public surface is still settling, and with 35 architecture classes plus a metadata dictionary that the README does not pin down, minor releases can move things you depend on. Pin the version in your requirements file rather than tracking main, and read the release notes before upgrading. The heavier maintenance burden is not this library. It is LangGraph and the LangChain family underneath it, plus the provider SDKs for whichever of the nine backends you enable.
Who should adopt it, and what to check first
Adopt it if you are building an agent and you want to start from a named, readable implementation rather than from a blank file, and if the LangChain and LangGraph dependency is already in your stack or acceptable to add. Adopt it if you learn by reading executed notebooks and want the theory attached to real captured output. Do not adopt it if you need a stable 1.0 API surface, if you cannot afford multiple LLM calls per task, or if your agent has to drive a browser in a latency-bound path. Before you commit, do three things. Clone the repository and run pytest -q to confirm the 283 tests actually pass on your machine in your Python version. Pick the one architecture you intend to use, open its notebook, and re-run it with your own provider key so you see the output rather than the captured output. Then check the constructor signature and the metadata keys yourself, because the README documents the uniform contract but not the per-pattern surface, and that surface is where your integration will actually live.
Editorial conclusion
Adopt it if you need a working reference implementation of a named pattern (Reflexion, LATS, GraphRAG, MemGPT, Voyager) on top of LangGraph and you are willing to read the notebook before trusting the class. Do not adopt it as a production runtime for a latency-sensitive or cost-sensitive service, and do not treat the leaderboard as a verdict on your own workload. Before committing, clone the repository, run pytest -q to confirm the 283 tests pass in your environment, then re-run the single notebook for the architecture you care about against your own provider key and compare the captured output with what you get.
Community notes