AgentForge GitHub

A research assistant that shows its sources and its failures.

AgentForge runs a Researcher, an Analyst and a Reviewer in sequence. Every URL in a report comes from a real search or page fetch, and a run that goes wrong says so instead of returning a made-up answer.

View the code Run it locally

Built with CrewAI, FastAPI, React, Vite and TypeScript.

Follow one question through the pipeline

Select an agent to see what it hands to the next one.

Illustrative sample. Composed to show the output format. It was not produced by a model run, and the example.org sources are placeholders.

Sample question What are the main trade-offs between multi-agent and single-agent LLM systems?

Evidence notes

  • web_search multi-agent LLM systems trade-offs
  • fetch_page example.org/source-a
  • web_search multi-agent LLM cost and latency

  • Specialized agents keep each prompt focused, which can improve quality on multi-step tasks.

    Page read example.org/source-a. Confidence: medium.

  • Every extra agent is another model call, so cost and latency go up.

    Search result only example.org/source-b. Confidence: medium.

  • Not verified: whether the benefit holds with small local models.

Hands to the Analyst: these notes and the source URLs.

Evidence and interpretation, kept apart

Evidence
One source reports that focused prompts help multi-step tasks. One search snippet reports higher cost with more model calls.
Interpretation
Multi-agent setups probably pay off when a task has distinct phases, and cost more without benefit when it does not.
Gaps
Nothing gathered on failure modes, such as agents repeating each other's mistakes.
Limitations
Only two sources, and one was not read in full.

Hands to the Reviewer: the analysis and the researcher's original notes.

Final report

Summary

Multi-agent setups trade extra cost and latency for more focused steps. The evidence gathered is thin, so treat both points as leads to verify, not conclusions.

Failed check

claim_2_snippet_only: the cost claim rests on a search snippet. The page itself was not read.

Evidence

  • example.org/source-a (placeholder)Page read
  • example.org/source-b (placeholder)Search result only

Limitations

Two sources. No evidence on small local models.

Returned to the browser as structured JSON, with the source list recorded by the tools.

Built so a report can be checked

Four choices that decide whether you can trust what comes back.

Sources come from tools, not from the model
The source list is recorded when the search and fetch tools run, so the model cannot add a URL to it. Each source says whether the page was read or only appeared in search results.
Failures stay failures
A model error, a timeout, or a missing source list ends the job as failed, with the reason. The interface never falls back to sample output.
Progress is real
The agent cards and timeline are driven by events emitted during the run: agent started, tool called, agent finished.
Long jobs do not hold a connection open
Starting a run returns a job id immediately and the browser polls for updates. Free hosting proxies tend to cut long requests, and this avoids that.

The interface

A sidebar, live agent cards, a timeline of backend events, and a report viewer with Markdown download.

AgentForge workspace during a run. The Researcher card shows Working with the page it is reading, and the timeline lists backend events.
While the agents work.
AgentForge workspace after a run, showing a report with summary, findings, evidence links and limitations.
A finished report.

Both screenshots were captured against a stubbed backend, so the report text is placeholder output from the test harness.

How the pieces connect

The browser starts a job and polls it. Worker threads run the crew, and the tools feed a source collector that the final result reads from.

AgentForge architecture The React UI posts a research request to FastAPI and polls for status. FastAPI hands the job to a job manager that runs a Researcher, Analyst and Reviewer in order. The Researcher uses web search and page fetch tools, which record every URL in a source collector. Tool calls record every URL into a source collector. The job manager combines the Reviewer's report with the collected sources. React UIVite + TypeScript FastAPI/api/research Job managerthread per job Researcher Analyst Reviewer web_searchfetch_page Source collectorevery URL touched poll for status
Solid arrows are control flow. Dashed arrows are polling, tool results, and the finished report returning to the job manager.

What has been verified

Measured on the first commit. Nothing here is estimated.

Measured

Measured results
Backend tests21 passing: validation, missing model, success, failure, timeout, CORS, URL guard, parsing
Frontend unit tests5 passing, 0 lint warnings
Production build353 kB JavaScript, 109 kB gzipped
Browser run in ChromiumForm validation, live progress, report, download, history, failed run, and a mobile layout with no horizontal scroll, against a stubbed backend
Clean checkoutFresh clone, fresh install, all of the above passes

Not yet verified

  • A full run against a live language model.
  • How well the free DuckDuckGo-based search holds up under real use.
  • A deployed backend. This site is static and does not call one.

Results from live runs will be added here once they exist.

Run it on your machine

You need Python 3.10 or newer, Node 20 or newer, Git, and one model: a Gemini or Groq API key, or a local Ollama install.

  1. Clone and set up

    The setup script creates the Python environment, installs both halves, and copies the .env templates.

  2. Add your model

    Open backend/.env and set AGENTFORGE_MODEL and AGENTFORGE_API_KEY. For Ollama, use ollama/llama3.1 and AGENTFORGE_BASE_URL=http://localhost:11434.

  3. Start both servers

    Open localhost:5173. The header should read "Backend connected" next to your model name.

git clone https://github.com/SahajIVVIX-1/AgentForge.git
cd AgentForge
scripts/setup.sh        # Windows: scripts\setup.ps1
# edit backend/.env: model and API key
scripts/dev.sh          # Windows: scripts\dev.ps1

Small local models can struggle with structured output. When that happens the report is shown as raw text with a visible failed check.