AutoGPT - Developer Guide
AutoGPT is an open-source platform to build, deploy and run continuous AI agents that automate multi-step workflows. You assemble an agent visually by wiring together blocks — each block is one discrete action — into a graph, then run it on demand, on a schedule, or in response to external triggers. This guide is the developer entry point: it explains what AutoGPT is today, how the platform is put together, the vocabulary you need, and where everything lives in the repo.
This guide is based on the official AutoGPT documentation (agpt.co/docs) and the Significant-Gravitas/AutoGPT GitHub repository (dev branch), reviewed on June 25, 2026. Code signatures and file paths are quoted from the repository source; the platform moves fast, so always cross-check against the current dev branch before relying on a specific detail.
1. What AutoGPT is (and what it isn't)
The name "AutoGPT" covers two distinct projects that live in the same repository. Knowing which one you are looking at saves a lot of confusion.
| AutoGPT Platform | AutoGPT Classic | |
|---|---|---|
| What it is | A modern platform to build, deploy and run AI agents as visual workflows | The original 2023 standalone autonomous agent |
| How you use it | Web UI (low-code Agent Builder) + a server backend | Python toolkit, CLI and a reference agent |
| State | Actively developed, the focus of the project | Legacy / maintenance, kept for reference |
| Lives in | autogpt_platform/ | classic/ (Forge, benchmark, frontend) |
| License | Polyform Shield | MIT |
The rest of this guide is about the Platform. Classic is summarised in §6.
Think of the Platform as a visual programming environment for AI agents. Instead of writing a script that calls an LLM and some APIs, you drop blocks on a canvas and connect them. The runtime executes that graph for you, handles credentials, retries, scheduling and billing of credits, and lets you publish the result for others to run.
2. The two halves of the Platform
The Platform is split into a frontend (where humans build and operate agents) and a server (where agents actually run).
Frontend
A Next.js / TypeScript web application. It is where you:
| Capability | What it does |
|---|---|
| Agent Builder | A low-code canvas to design and configure agents by connecting blocks |
| Workflow management | Build, modify and optimise the graph; each block performs a single action |
| Deployment controls | Manage an agent's lifecycle from testing to production |
| Library / Ready-to-use agents | Pick a pre-configured agent and run it without building anything |
| Agent interaction | Run your agents and provide their inputs through the UI |
| Monitoring & analytics | Track runs, outputs and performance over time |
Server
The backend is the "powerhouse" where agents run. Once deployed, an agent can be triggered by external sources (webhooks, schedules, manual runs) and operate continuously. The server is a set of Python services and contains:
- Core logic — the graph engine and the block library that drive execution.
- Infrastructure — the supporting services (database, queue, cache, auth, file scanning, …).
- Marketplace — a catalogue where you can find and deploy pre-built agents.
Under Docker Compose the backend is not a single process but several cooperating services — a REST API server, an executor, a websocket server, a database manager, a scheduler and a notification server — plus their dependencies (Postgres via Supabase, Redis/FalkorDB, RabbitMQ, ClamAV). You don't need to think about each one to build agents, but it's useful to know the backend is a distributed set of services when self-hosting (see Self-Hosting).
3. Core concepts
These five terms appear everywhere in the UI, the docs and the code. Internalise them before going further.
| Concept | Definition |
|---|---|
| Block | The smallest unit of functionality — one block does one thing (call an LLM, send an email, do maths, read a webpage). Blocks have a typed input schema and a typed output schema. |
| Node | A specific instance of a block placed on the canvas, with its inputs configured. The same block can appear as many nodes. |
| Link | A connection from an output pin of one node to an input pin of another. Links are how data flows through the agent. |
| Graph | The whole agent: a set of nodes connected by links. "Agent" and "graph" are effectively synonyms — the graph is the agent's workflow. |
| Agent | A graph you can run, schedule, publish and share. An agent has versions. |
Two more terms for distribution:
- Marketplace — the public catalogue of agents others have published; browse, test and deploy them.
- Library — your own collection of agents (built or added from the marketplace), ready to run.
┌─────────┐ link ┌──────────────┐ link ┌──────────────┐
input ───▶ │ Node A │ ───────────────▶│ Node B │──────────────▶│ Node C │ ───▶ output
│ (Block) │ output → input │ (Block) │ │ (Block) │
└─────────┘ └──────────────┘ └──────────────┘
one Graph = one Agent
A block's run() method is an async generator: it yields one or more (output_name, value) pairs. Each yielded value travels along every link attached to that output pin and lands on the connected input pin of the downstream node. This streaming model is why a single block can emit multiple results over time, not just one return value. The mechanics are covered in Building Blocks.
4. Tech stack
| Area | Technology |
|---|---|
| Backend language | Python (~69% of the repo) |
| Frontend language | TypeScript (~29%) |
| Containerisation | Docker Engine ≥ 20.10, Docker Compose ≥ 2.0 |
| Database | PostgreSQL via Supabase, accessed through Prisma |
| Queue / cache | RabbitMQ, Redis / FalkorDB |
| Schema/validation | Pydantic models for every block's input & output schema |
| Standard (Classic) | Agent Protocol by the AI Engineer Foundation |
The use of Pydantic is important for developers: a block's input and output schemas are Pydantic models, which are converted to JSON Schema and stored in the database. That JSON Schema is what the Agent Builder renders as a form, and what the executor validates against at run time.
5. Monorepo layout
The repository is a monorepo. The two licensing zones map onto two top-level areas:
AutoGPT/
├── autogpt_platform/ # ← the Platform (Polyform Shield License)
│ ├── backend/
│ │ └── backend/
│ │ ├── blocks/ # the block library — _base.py defines the Block class
│ │ ├── data/ # block.py, model.py (SchemaField, Credentials, …), graph, execution
│ │ ├── sdk/ # the Block SDK (auto-registration, provider/credentials helpers)
│ │ └── integrations/ # provider definitions, OAuth, webhooks
│ ├── frontend/ # Next.js web app (Agent Builder, Library, Marketplace)
│ ├── docker-compose.yml # the full self-host stack
│ └── .env.default # template you copy to .env
│
├── classic/ # ← AutoGPT Classic (MIT License)
│ ├── forge/ # agent-building toolkit
│ ├── benchmark/ # agbenchmark
│ └── frontend/ # classic GUI
│
├── docs/ # documentation source
└── run # root CLI (./run setup | agent | benchmark) — Classic
The files most relevant to block development — backend/data/block.py, backend/blocks/_base.py and backend/data/model.py — are dissected in Building Blocks.
6. AutoGPT Classic (legacy)
Everything outside autogpt_platform/ is the original AutoGPT, under the MIT license. You will rarely need it for new work, but for context:
- Forge — a ready-to-go toolkit that handles the boilerplate of building your own standalone agent. Its components can also be reused individually.
- agbenchmark — a benchmarking harness for any agent that speaks the Agent Protocol; published on PyPI as
agbenchmark. - Classic GUI — a simple frontend that connects to agents via the Agent Protocol.
- Root CLI —
./run setup,./run agent,./run benchmarktie these together. Run./run setuponce to install dependencies.
If your goal is to build modern agents, ignore Classic and work in autogpt_platform/.
7. Licensing — read this before you build commercially
AutoGPT uses two licenses, split by folder. This matters if you plan to host or commercialise:
| Scope | License | Practical meaning |
|---|---|---|
Everything in autogpt_platform/ | Polyform Shield | Source-available. You may use, self-host and modify it, but the Shield license restricts offering it as a competing commercial product/service. |
Everything outside autogpt_platform/ (Classic, Forge, agbenchmark, Classic GUI) | MIT | Permissive — use freely, including commercially. |
Polyform Shield is not an OSI "open source" license in the strict sense — it is source-available with a non-compete restriction. Before building a commercial offering on top of the Platform, read the actual license text in the repo and get your own legal review. The summary above is orientation, not a legal opinion.
8. Where to go next
| You want to… | Read |
|---|---|
| Run the Platform on your own machine | Self-Hosting — requirements, Docker setup, ports, troubleshooting |
| Write your own block | Building Blocks — the Block class, schemas, run(), credentials and testing |
| Compare AutoGPT to other agent frameworks | Agent comparison overview |
9. Sources
- Significant-Gravitas/AutoGPT —
README.md,autogpt_platform/backend/backend/data/block.py,autogpt_platform/backend/backend/blocks/_base.py,autogpt_platform/backend/backend/data/model.py(devbranch, reviewed 2026-06-25) - AutoGPT documentation — agpt.co/docs
- Repository — github.com/Significant-Gravitas/AutoGPT