AutoGPT

Enables users to design autonomous agent workflows by dragging and dropping typed blocks onto a canvas and connecting them with edges to define data flow. The frontend uses React Flow for graph visualization, Zustand for state management, and RJSF for dynamic input forms. Blocks are nodes representing LLM operations, integrations, or control flow; edges define typed data dependencies. The system validates graph connectivity and block configurations before execution.

Implements a composable block system where each block is a self-contained unit performing a specific action (LLM reasoning, API integration, data transformation, or control flow). Blocks define input/output schemas using JSON Schema, enabling type-safe data flow between connected blocks. The backend loads block definitions from a registry, validates inputs against schemas, executes the block logic (which may invoke LLMs, external APIs, or Python functions), and returns typed outputs. Blocks can be AI blocks (LLM-powered), integration blocks (external services), or data/control flow blocks (transformations, conditionals).

Provides a Python framework and CLI for developers to build custom agents with a standardized structure. Forge includes project templates that scaffold the basic agent structure (main loop, tool registry, memory management), configuration files for LLM settings and tool definitions, and utilities for common agent patterns (memory, logging, error handling). Developers extend the base Agent class, implement custom tools, and configure the agent via YAML or JSON. Forge includes a CLI for creating new agent projects, running agents locally, and packaging agents for deployment. This enables rapid agent development without building infrastructure from scratch.

Provides a standardized benchmark suite for evaluating agent performance across a range of tasks. The benchmark includes task definitions (goal, success criteria, expected output), execution harnesses that run agents against tasks, and metrics for measuring success (task completion rate, token efficiency, execution time). Tasks are categorized by difficulty and domain (e.g., web research, code generation, file manipulation). The benchmark supports comparing multiple agents or agent configurations, generating reports with pass/fail rates and performance metrics. Results are stored in a database for historical tracking and trend analysis. The benchmark is designed to be extensible; developers can add custom tasks.

Implements encrypted storage for API keys, database credentials, and other secrets used by blocks and agents. Credentials are encrypted at rest using AES-256 encryption with keys managed by the application or external key management service (e.g., AWS KMS). When a block needs a credential (e.g., OpenAI API key), the system retrieves the encrypted credential from the database, decrypts it, and injects it into the block execution context. Credentials are scoped to users or organizations; users cannot access other users' credentials. The system supports credential rotation and audit logging of credential access.

Sends notifications to users when workflows complete, fail, or reach certain milestones. Notifications can be delivered via email, Slack, webhooks, or in-app messages. Users configure notification rules (e.g., 'notify me when workflow fails', 'notify me when execution exceeds 5 minutes'). The system tracks notification delivery status and retries failed deliveries. Notifications include relevant context (workflow name, execution status, error message, execution duration) to enable quick diagnosis. The notification system is asynchronous; notification delivery does not block workflow execution.

Executes agent workflows across multiple Python FastAPI microservices that communicate via RabbitMQ message queues. When a workflow is triggered, the execution engine (scheduler and manager) decomposes the agent graph into a topologically sorted execution plan, then dispatches block execution tasks to worker services via RabbitMQ. Each worker executes a block, persists results to the database, and publishes completion events. The system supports concurrent block execution where dependencies allow, with a credit-based rate limiting system to manage resource consumption. Execution state is tracked in a PostgreSQL database with WebSocket notifications for real-time UI updates.

Abstracts LLM provider differences (OpenAI, Anthropic, Ollama, etc.) behind a unified block interface. AI blocks define which LLM provider to use, model name, and parameters (temperature, max_tokens, etc.) via JSON Schema. The backend resolves provider credentials from a secure credential store (encrypted in database), constructs provider-specific API requests, and handles provider-specific response formats and error codes. Supports streaming responses for real-time token output. The system tracks token usage per execution for billing and quota management via the credit system.

Analyzes the agent workflow DAG to determine execution order and parallelization opportunities. The execution planner performs topological sorting on the block graph, identifies blocks with no dependencies (can execute immediately), and creates an execution plan that respects data flow constraints. Blocks are executed in stages: all blocks in stage N complete before stage N+1 begins, but blocks within a stage execute concurrently. The planner validates that all block inputs are satisfied by upstream outputs, detects cycles (invalid), and optimizes for minimal execution time by maximizing parallelism. Execution state is tracked per block (pending, running, completed, failed) with rollback support for failed branches.

Implements a credit system where each user or organization has a quota of credits that are consumed by agent executions. Block execution costs are defined per block type and LLM provider (e.g., GPT-4 costs more than GPT-3.5). Before execution, the system checks if the user has sufficient credits; if not, the workflow is rejected. After execution, credits are deducted based on actual LLM token usage and block execution time. The credit system supports tiered pricing (e.g., different rates for different user tiers) and can be configured to allow credit overages with billing. Credits are tracked in the database with audit logs for transparency.

Provides a centralized marketplace where users can publish, discover, and reuse agent workflows and custom blocks. Published agents are versioned (semantic versioning), tagged with metadata (category, use case, required credentials), and include documentation. The marketplace supports searching by name, tag, or description. Users can fork published agents to create variants, and the system tracks lineage (original author, fork history). Blocks can be published to a shared library with version constraints, enabling workflows to depend on specific block versions. The marketplace includes ratings and reviews for community curation. Access control supports public, private, and organization-scoped sharing.

Enables block input fields to reference outputs from upstream blocks in the workflow graph. When a block is configured, users can bind input fields to upstream block outputs (e.g., 'use the result of block_5 as input to block_8'). The system maintains a mapping of field references to upstream blocks. At execution time, the executor resolves these references by retrieving the actual output values from completed upstream blocks and injecting them into the current block's input. This enables data flow without explicit data transformation blocks. Field resolution supports nested paths (e.g., 'block_5.result.data[0].name') for accessing nested JSON structures.

Provides real-time visibility into agent execution progress through WebSocket connections. As blocks execute, the backend publishes execution events (block started, block completed, block failed, execution completed) to WebSocket channels. The frontend subscribes to these channels and updates the UI in real-time without polling. Execution state includes block status, input/output values, execution duration, and error messages. The system maintains execution history in the database for post-execution analysis. WebSocket connections are authenticated and scoped to the user's workflows to prevent unauthorized access.

The original AutoGPT implementation (in the 'classic/' directory) is a standalone Python agent that uses chain-of-thought reasoning to decompose goals into sub-tasks. The agent maintains a memory of previous thoughts and actions, generates new prompts based on this memory, and uses a tool registry to call external functions (web search, code execution, file operations, etc.). The agent loops: think (generate next action via LLM), act (execute tool), observe (process result), repeat until goal is achieved or max iterations reached. This is distinct from the platform's block-based approach; it's a single-agent loop rather than a DAG of blocks.