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.
Modern agentic systems often struggle with the reliability of LLM-as-scorer mechanisms, where probabilistic free-text outputs lead to inconsistent agent behavior—colloquially known as the "flat-band pathology." This repository addresses that instability by implementing a deterministic-picker pattern, requiring LLMs to commit to categorical features (booleans, enums) rather than unstructured scores, allowing Python to compose the final decision signal.
What This Does
The project provides a Python library implementing 35 distinct agentic AI patterns, ranging from Reflexion and LATS to GraphRAG and Voyager. Each architecture ships as a runnable Architecture class with a uniform .run(task) interface, all documented in Jupyter notebooks located in docs/architectures/ and notebooks/. A central technical discipline across 13 architectures is the deterministic-picker pattern, which structures LLM outputs into categorical features for reliable Python-side composition; a further 9 architectures are architecturally immune to the scorer pathology by design. The library is multi-provider, supporting Nebius, OpenAI, Anthropic, Groq, Ollama, Together, Fireworks, Mistral, and Google, and is built on top of LangGraph state machines.
How It Is Wired
Execution begins by instantiating a specific Architecture subclass (e.g., Reflection, LATS) from src/agentic_architectures/architectures/. These classes accept an LLM instance via get_llm() and a task string. The uniform .run(task) method triggers the architecture-specific state machine logic. The deterministic-picker logic is embedded within the scorer components of architectures like Reflexion, ensuring the LLM's output is parsed into structured Python types before further processing. The pyproject.toml file manages package dependencies, while environment variables configured in .env.example handle LLM provider credentials. The code touches external networks via API calls to the configured LLM providers and manages state internally through LangGraph state persistence.
Configuration: Copy .env.example and populate the required API keys for the desired LLM provider (e.g., OPENAI_API_KEY, ANTHROPIC_API_KEY).
Running it: Use the uniform .run(task) interface demonstrated in the quickstart:
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)
Real-World Use
A practical use case involves deploying Reflexion to improve output quality in a closed-loop generation task. By instantiating Reflection(llm=get_llm(), max_iterations=2), the architecture iteratively queries the LLM and scores outputs against a target, leveraging the deterministic-picker to halt when the score threshold is met. This pattern is applicable for improving reliability in tool-use agents or code generation workflows where output validation is critical.
Code Health & Issues
A heuristic analysis identified one low-risk finding: dependencies are declared in pyproject.toml without a corresponding lockfile, which may lead to non-reproducible builds across environments. Beyond this, the repository structure is well-organized with extensive documentation and test coverage (283 passing tests per the README), though the absence of a lockfile is the primary static analysis finding.
The Bottom Line
This repository is a valuable resource for experimenting with and comparing 35 major agentic AI patterns within a consistent framework. The multi-provider support and the deterministic-picker pattern offer a practical solution to LLM reliability concerns. However, the lack of a dependency lockfile presents a reproducibility risk for production deployment that should be addressed before integrating into strict CI/CD pipelines.
What the analyser found
Deployment readiness
6/7
✓Container image
✓CI pipeline
✗Lockfile committed
✓Test suite
✓README
✓License
✓No committed secrets
Composition
270 files
Python148
Jupyter Notebook70
Markdown25
YAML14
JSON6
CSS1
ReactDocker
Module dependencies
The 10 most depended-upon modules of 148, from static import analysis. Red outline marks a module in an import cycle.
Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.
high3
medium5
low1
Pin third-party GitHub Actions to a commit SHAhigh4 occurrences
A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.
Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.
Commit a lockfile beside the manifesthigh
pyproject.toml
manifest with no lockfile in scope
An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.
Fix: Run the package manager once and commit the generated lockfile.
Remove continue-on-error from steps that gate correctnesshigh
.github/workflows/docs.yml
line 50 on a correctness step
A failing test suite reports a green check, which is precisely the path this audit exists to close.
Fix: Delete continue-on-error, or move a genuinely advisory step into a separate non-required job.
Pin the container base image by digestmedium
docker/Dockerfile
python:3.11-slim
An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.
Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.
Gate pull requests on a dependency vulnerability scanmedium
.github/workflows
no dependency scan in CI
This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.
Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.
Set persist-credentials: false on checkoutmedium
.github/workflows/ci.yml
checkout keeps the token, then dependencies are installed
The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.
Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.
Add a non-root USER to the imagemedium
docker/Dockerfile
CMD or ENTRYPOINT with no USER directive
A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.
Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.
Pin the resolution so a vulnerable version cannot installmedium26 occurrences
no lockfile, and the declared ranges reach langchain-core@0.3.0 CVE-2025-68664 (critical) +13 more; langgraph@0.2.50 CVE-2026-48776 (critical) +2 more; langchain@0.3.0 CVE-2026-45134 (high) +3 more; and 1 more package(s)
The range includes versions with published advisories and nothing in the repository records which one was resolved, so two installs a month apart can differ in whether they are vulnerable and neither is reproducible from what is committed.
Fix: Commit the lockfile, which fixes the resolution and makes this answerable.
Set timeout-minutes on the workflow jobslow3 occurrences
.github/workflows/ci.yml
3 workflow(s) declare no job timeout
A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.
Fix: Add timeout-minutes with a realistic bound to each job.
Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.