AgentForge

AgentForge is a standalone Python framework for coordinating specialized software agents through reusable workflows.

A human states a Task. The Orchestrator files a GitHub issue carrying a frozen plan and the Roster of Roles that will execute it. agentforge implement <n> runs the Issue's Workflow and opens a draft pull request for a human to sign off. No workflow ever merges.

Status

The Workflow runtime now runs multiple Roles in order. The default feature Workflow invokes the Implementer, the Tester, Security, and then the Reviewer, posting each Agent Result to the Issue before starting the next Step.

$ agentforge plan "add a retry to the loader"

The Orchestrator has questions before it writes anything down.
Answer them, or press Enter on an empty line to plan with what it has.

  Which loader — the orders one, or the returns feed?
  > orders

  Retry on 5xx only, or timeouts too?
  > both, cap it at three attempts

Filed issue #12: https://github.com/acme/pipelines/issues/12
  Roster: implementer (standard)
  Interview: 2 question(s) answered

Run it with:  agentforge implement 12

$ agentforge implement 12 --allow-commands
  [ok] implementer (standard) — Wrapped the fetch in a bounded retry.
  [ok] tester (cheap) — pytest: 24 passed.
  [ok] security (deep) — Audited the change; no findings.
  [ok] reviewer (deep) — The change matches the plan. unslop: clean on attempt 2.

Draft pull request: https://github.com/acme/pipelines/pull/13
AgentForge stops at Sign-off. A human merges.

The two commands can run on different machines. Nothing is shared between them but the issue number.

The interview happens while you are still at the keyboard, because ADR-0003 freezes the plan the moment it is filed. It is rounds of one-shot invocations rather than a conversation — the Provider port has no session — and it ends as soon as the Orchestrator has enough, or as soon as you press Enter on an empty line. With nothing interactive attached, there is no interview at all: a scheduled Run has nobody to ask, and blocking on an answer that will never arrive is worse than planning from what was typed.

A term you settle in the interview is recorded in the project's own CONTEXT.md so the same question is not asked next week. That leaves changes in your working tree; agentforge plan says which files, and they are yours to review and commit.

Opening that gate is also what makes a Run produce files nobody asked for: running a suite writes __pycache__, and possibly coverage data and a cache directory. AgentForge commits every change to a file git already tracks, and an untracked file only when the frozen plan or an agent's own result named it. Everything else stays in your working tree and is listed in the pull request under Left uncommitted, so a repository with no .gitignore still gets a diff that is only the work. AgentForge does not write a .gitignore for you. See ADR-0015.

Without --allow-commands, the Implementer remains default-deny and the Tester reports that it could not run the suite; it never substitutes reading tests and claims completion. Security, the Reviewer, and the Architect need no such flag — auditing, reviewing, and designing are reading. All six Roles CONTEXT.md names now run. Plugins have landed, and with them the data-engineering ones: a repository whose files import pyspark has its Roles told to write DataFrame expressions rather than RDDs, and a Databricks workspace gets Unity Catalog naming and the Delta MERGE idioms in the prompts that write code and the workspace's own posture in the one that audits it. A repository that matches neither hears neither. agentforge init is still to come. See docs/PLAN.md.

Before the first Role is invoked, AgentForge resolves a Context Pack from the frozen plan — the files it names, the symbols and imports inside them, the tables a query touches, the keys a config file sets — and hands the same pack to every Role, so six Agents do not each rediscover one repository. The pack is a head start rather than a boundary: a Role that needs a file it does not name reads that file. Every Run Log entry then ends with what that Step consumed, in whatever unit the Provider reports it — dollars from claude, tokens from codex, and "not reported" where a CLI says nothing, because a blank reads as free. The last comment carries the Run's total. To find out what the pack is worth on your own repository, run the same issue again with --no-context-pack and compare the two totals.

The Reviewer writes the prose a human reads at Sign-off, and that prose is scanned by the vendored unslop scanners before it is posted. The first draft is written with write-plainly in front of it — what the three scanners count, stated for a draft rather than as findings on one — because a rewrite reaches a phrase and one of the scanners reads the shape of the whole document. A finding sends the Reviewer its own findings to rewrite against, twice at most, and the skill is not delivered again there: a finding already names the phrase, the line, and a replacement. The scan is a Command and not a Gate: prose that still scans dirty on the third attempt is posted anyway with the report attached, because holding a finished Run on a cosmetic check trades a real cost for a stylistic one. The report reaches the Run Log either way.

Before 1.0 the stable surface is the Issue body: what AgentForge writes into an issue keeps parsing, so a Run filed by one version resumes under a later one. Everything importable under agentforge_framework.* is private and changes without notice. See ADR-0011.

Install

AgentForge publishes to no package index yet, so neither route below is pip install agentforge-framework. Both put the same agentforge command on your path.

The distribution is agentforge-framework and it imports as agentforge_framework, because an older and larger project holds agentforge on PyPI and imports under that name. Decorating both means the two can sit in one environment without either shadowing the other.

Installing puts two commands on your path, agentforge and agentforge-framework, and they are the same program. Use agentforge; the whole of this README does. Reach for the long one only if you also have that other project installed, because its 0.5.0 through 0.6.5 declare an agentforge command too and whichever was installed last wins. See ADR-0013.

From a release wheel, to run AgentForge against your own repositories. Download the wheel attached to the latest release and install the file you downloaded:

$ pip install agentforge_framework-0.2.0-py3-none-any.whl
$ agentforge --version
agentforge 0.2.0

Publishing a release is a wizard rather than a checklist: bash scripts/publish-wizard.sh registers the Trusted Publishers on TestPyPI and PyPI, rehearses the whole upload path against TestPyPI, and stops before the one irreversible step. Whoever cuts the next release runs it instead of reading release.yml.

From a clone, to work on AgentForge itself. An editable install leaves the command pointing at the checkout, so an edit takes effect without reinstalling, and [dev] adds the pytest and ruff that CI runs:

$ git clone https://github.com/yashmhatre/AgentForge.git
$ cd AgentForge
$ pip install -e ".[dev]"

What each release contains is in CHANGELOG.md.

Requirements

• Python 3.11 or newer
• git, and a repository with a GitHub remote
• The GitHub CLI, authenticated
• A coding-agent CLI. claude ships supported; codex exists to keep the provider port honest.

AgentForge never touches a model API and handles no credentials of its own. Whatever your coding-agent CLI is already authenticated with is what a Run costs.

Commands

agentforge run writes into your working tree and commits nothing: review the diff and commit it yourself. It never replaces a file that is already there, and a Command that runs a process is bound by the same default-deny posture as everything else (ADR-0007) -- typing the command is the grant. Which Commands you have depends on which Plugins answer for the repository you are in, which outside a Run is what its root markers say: a dbt_project.yml gets you dbt chores. See ADR-0019.

Both agent commands take --provider and --tier. A bare --tier deep moves every Role; --tier implementer=deep moves one.

Either flag beats the issue. Without one, the tier beside a Role in the Roster table is the tier that Step runs at — the Orchestrator's judgement about how hard this particular Task is, frozen with the rest of the plan, so a resumed Run costs what the first invocation would have. A Role the Roster does not name runs at its declared default. See ADR-0014.

Workflows

Three ship. The Orchestrator picks one while it plans and names it in the Issue body, so a human reading the Issue knows which Roles are about to touch their repository and in what order — the Roster table is that Workflow's Roles. A project adds its own by dropping a definition beside them, and it becomes selectable too.

review is the only one with no Implementer. It ends at a draft pull request like the others, because the branch already carries the commits it was pointed at.

The Architect is in none of them. It runs deep, most Tasks do not need a design pass, and one on every Run would be the most expensive default in the project — so the Orchestrator selects it for design-heavy Tasks, and a project that always wants one names it in a Workflow of its own. Its design reaches the Run Log rather than the next Role's prompt, which is a limit of what a Context Pack carries today.

A step may declare a Gate that must clear before the next one starts. None of the shipped definitions do: a Gate suspends the Run until it clears, and a default Workflow that stops to wait on somebody is a choice a project makes rather than one it inherits.

Project configuration

agentforge init writes .agentforge/config.yaml for the repository you run it in. It reports what it found -- the languages git knows about, the Plugins your root markers answer for, the suite it detected and the evidence for it -- and writes the two things AgentForge reads. It refuses before creating anything if the repository has no GitHub remote, because ADR-0002 makes that a precondition for every Run. Re-running never clobbers a config you have edited: it reports what differs and writes nothing, and --force replaces it.

The file is not a precondition. Without one, the documented Provider capability defaults are Claude native and every other Provider fragment, and the tests Gate runs pytest.

providers:
  claude:
    capability_tier: native
  codex:
    capability_tier: fragment

gates:
  tests:
    suite: pytest

There is no plugins: key. Which Plugins answer for a repository is decided per Run from the frozen plan's blast radius (ADR-0016), so a repository-level list would be inert and misleading -- init prints what it detected instead. The file holds what AgentForge reads and nothing else; see ADR-0020.

A Role declares the skills it needs. A native Provider receives them through its CLI's skill mechanism; a fragment Provider receives the same SKILL.md text appended to the prompt. Capability Tiers are configuration, never the result of probing an installed CLI.

Most skills are vendored third party (see skills/MANIFEST.yaml). Two are AgentForge's own. grill-with-docs is the interview and the writing-down as one job, built out of grilling and domain-modeling: a native Provider is named the composite and fans it out itself, and a fragment Provider gets the composite and both parts inlined, because it has no mechanism to fan out with. write-plainly composes nothing — it is derived from what the three unslop scanners enforce, since upstream keeps its own writing doctrine in a references/ tree this bundle does not vendor.

A Workflow step declaring gate: tests runs gates.tests.suite and holds the Run when it fails, posting the output to the Issue. The default is pytest. A string is split the way a shell would split it; a list is taken as written, which is how a path with a space in it gets named. The Gate runs the suite itself rather than believing what the Tester said about it, and it needs no --allow-commands: ADR-0007 governs what a Role may run, and this is the project's own declared suite rather than a command a model chose.

A suite that ran and failed suspends the Run — the commit that fixes it clears the Gate. A suite that could not be run at all halts the Run, because there is nothing there for a later Run to clear.

gate: security needs no configuration. It reads the Security Agent's Findings out of the Run Log: none of them clears it, and any of them suspends the Run and marks the Security Step to run again, so the audit that resumes reads the fixed code rather than the verdict about the old code.

Project layout

• core/ — the contracts, the command runner, the GitHub boundary, the plan format, and the run loop.
• agents/ — the Role definitions and their prompts.
• providers/ — one adapter per coding-agent CLI.
• workflows/ — the three shipped Workflow definitions.
• context/ — the Context Pack resolver and its per-language Extractors.
• plugins/ — one package per technology, contributing the conventions a repository is held to, the readers its files are read with, and the Gate kinds its Workflows can name; core/registry.py decides which are active for a Run.
• skills/ — vendored third-party skills. Never edited in place; see skills/MANIFEST.yaml.

Read CONTEXT.md before writing anything, and docs/adr/ for the decisions that constrain it.

Tests

$ pip install -e ".[dev]"
$ pytest

The suite runs offline: no network, no GitHub account, and no coding-agent CLI installed. One fake command runner stands in for every external process.