AgentForge puts multi-agent orchestration in YAML Cogs

The Cog file is the unit of composition, not the agent class

AgentForge separates three concepts that many agent frameworks collapse into one object. Agents hold identity and behaviour, Cogs describe workflows, and Memory is an optional layer. The README calls Cogs the primary way to compose agents into reusable workflows, and the mechanism is declarative: branching logic, multi-agent steps and memory all get expressed in YAML files rather than in Python control flow.

That choice has a clear consequence for reviewers. A Cog can be diffed, reviewed and stored next to the rest of configuration, which is attractive when several people need to agree on what an agent pipeline actually does. It also means the framework carries a second runtime of its own, since whatever parses and executes the YAML has to define its own semantics for branching. The README does not document rollback for a bad Cog, nor a validation step that would reject a malformed workflow before it runs.

Agents are configured in the same declarative style. Prompts come from YAML prompt templates, and personas live in separate persona YAML files that set identity, style and context. Prompt templates are described as flexible and able to adapt to context and memory, and the framework adds on-the-fly prompt editing so prompts can be changed in real time without restarting the system. For an interactive workshop, that is the feature that saves the most time.

One runtime, many model providers, and a Codex path that needs its own spec

The framework is model agnostic in the practical sense. The README names OpenAI, Google's Gemini and Anthropic's Claude among the supported APIs, and it adds local models served through Ollama or LMStudio. Different agents in the same Cog can run on different models, which is the reason the abstraction exists: a cheap local model for classification, a hosted model for the step that needs quality.

The dependencies back that claim with named clients rather than an internal abstraction of their own. The pyproject.toml dependency list includes openai, anthropic, google-generativeai, google-api-python-client, groq and oauth-cli-kit. The presence of oauth-cli-kit>=0.1.3,<1.0.0, together with a top-level file named OPENAI_CODEX_OAUTH_SPEC.md and a documentation guide called first_real_model_run.md that describes a default Codex OAuth model path, suggests the OAuth route is a first-class option rather than an afterthought. The exact flow inside that spec is not reproduced in the project overview, so treat it as something to read before you plan around it.

The trade-off is that the same flexibility applies to failure. Nothing in the overview describes retry behaviour, rate-limit handling or fallback when a chosen provider is unavailable, so a Cog that mixes providers inherits the reliability of the least reliable one.

Memory is declared inside the Cog and handed to agents automatically

Memory in AgentForge is a set of nodes that you declare inside a Cog. Those nodes are then made available to agents automatically, which removes the usual wiring step where each agent is constructed with a reference to a store. The README also calls memory optional, so a first run does not require it.

The dependency list suggests where the storage comes from. chromadb>=1.1.0 sits alongside sentence-transformers, numpy>=2.0.0 and scipy, and the README lists an Integrated Memory feature for coherent, context-aware interactions. The repository layout adds storage and memory references to the advanced guide, and package-data configuration ships YAML files under setup_files, which is where a scaffolded workspace is likely to pick up defaults.

There is a cost to this design that is easy to miss. The quickstart guide is described as scaffolding a .agentforge/ directory, so the project writes into your working tree. Chroma brings its own storage and embedding stack on top of the model client, which turns a light experiment into a heavier installation than the idea of a low-code framework suggests.

The dependency set is heavier than the low-code promise implies

AgentForge is described as a low-code framework, and the code you write is indeed small. The install is not. The declared dependencies include chromadb, numpy, sentence-transformers, spacy, pymupdf, beautifulsoup4, scipy, semantic-text-splitter, discord.py, xmltodict, requests, PyYAML and ruamel.yaml. Both PyYAML and ruamel.yaml are present, and the optional extra named other adds opencv-python, Pillow and pytesseract for image and OCR work.

Most of those are large wheels. spacy and sentence-transformers in particular pull model downloads and native dependencies, and the package metadata states that the project needs Python >=3.12,<3.15, so three interpreters are eligible and older ones are not. The ruff configuration targets py312 and the classifiers list only Python 3.12 and 3.14, so 3.13 works but is not explicitly claimed.

None of that makes the project wrong. It makes the first run slow and the environment fragile, and it means an evaluation of AgentForge is also an evaluation of how long a cold install takes on your machines. It is worth measuring that before you decide whether the framework is worth the footprint.

Getting to a first run: packaging, the docs hub and a credential-free smoke test

The project publishes to PyPI as agentforge, and the README points new users at the documentation hub in docs/README.md rather than at schemas, memory, storage or the legacy Tools/Actions references. That ordering is deliberate: the hub gives a recommended sequence for a first smoke test, a first real model run and the beginner Cog examples.

The packaging metadata is the part that can be quoted precisely. The build backend is setuptools with a src layout, and the project identity and Python floor look like this:

[project]
name = "agentforge"
version = "0.6.6"
description = "AI-driven task automation system"
readme = "README.md"
requires-python = ">=3.12,<3.15"
license = "GPL-3.0-or-later"

The version there is worth noting. It reads 0.6.6, while the newest release tag on the repository is v0.5.1 dated 2025-02-09. The overview does not explain how releases relate to the version in pyproject.toml, so pinning a dependency to a published tag may get you older code than the current tree.

For a first real use, follow the quickstart guide at docs/guides/quickstart.md. The overview states that it installs, scaffolds .agentforge/ and runs a no-credential debug smoke test, so you can confirm the install is sound before supplying any API key. Then move to docs/guides/first_real_model_run.md for the default Codex OAuth model path or another provider. The overview gives no shell commands for either guide, so read them in the repository rather than guessing at flags.

A pre-alpha package with release tags that stopped in early 2025

AgentForge is not archived. The last push was on 2026-08-10, which is recent in calendar terms. The release history tells a flatter story: v0.4.0 on 2024-10-08, v0.5.0 on 2025-02-04 and v0.5.1 on 2025-02-09. No tag covers the 0.6.x version that the packaging metadata declares.

The project also labels itself plainly. The pyproject.toml classifier reads Development Status :: 2 - Pre-Alpha, and the README description calls it an Extensible AGI Framework while the package description reads AI-driven task automation system. A pre-alpha classifier is a signal about interface stability, and for a project where the public surface is YAML schemas, changing a schema breaks a workflow file that looked fine a week earlier.

Licensing follows GPL-3.0-or-later, with the LICENSE file included and the README naming the GNU General Public License v3.0. Anyone embedding AgentForge inside a proprietary product should read that obligation themselves, since the framework pulls the workflow, the memory layer and the model client together in one install and the GPL question depends on how you link and distribute it.

Where AgentForge sits against plain SDK scripting

The realistic comparison is not another agent framework but the direct approach: a few lines of the openai or anthropic client, a Python function for the branching, and a dictionary for the prompt. That alternative gives you full control over retry logic, token accounting and error handling, and it installs in seconds. What it does not give you is the thing AgentForge is actually for: a set of YAML files that several people can read, review and change without touching Python.

The other side of that choice is worth stating plainly. Once your logic moves into Cogs and prompts move into YAML templates, the debugging surface grows, and the framework's own documentation becomes part of your critical path. The README itself advises starting with the public docs hub before opening schemas, memory, storage, subclassing, utilities or legacy Tools/Actions references, and the mention of legacy Tools and Actions tells you the project has renamed things at least once.

For a research group or an internal prototype, that trade is usually worth it. For a service with an uptime target, the pre-alpha status and the absence of documented rollback make it a harder sell.

Editorial conclusion

AgentForge fits teams that want agent behaviour reviewable as YAML and that can live with a pre-alpha package and a heavy install. It does not fit production services that need a stable release trail, since the newest release tag is v0.5.1 from 2025-02-09 while pyproject.toml declares version 0.6.6. Before adopting it, check the Python floor of 3.12, run the no-credential smoke test in docs/guides/quickstart.md, and confirm your chosen model path works with the provider you intend to use.

Frequently asked questions

Official sources

1. DataBassGit/AgentForge on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases