AutoGPT

Users design autonomous agent workflows by dragging blocks (nodes) 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. The backend persists agent graphs as directed acyclic graphs (DAGs) in the database, enabling version control and collaborative editing. This abstraction eliminates the need to write agent orchestration code manually.

AutoGPT abstracts LLM provider differences (OpenAI, Anthropic, Ollama, LlamaAPI) through a unified block interface that accepts provider-agnostic prompts and parameters. The backend's credential management system encrypts and stores API keys per user, routing requests to the appropriate provider's SDK at execution time. Dynamic fields in block schemas allow users to select models and providers without code changes, and the system handles provider-specific response parsing (token counts, function calling formats, streaming).

Users can schedule agents to run on a recurring basis using cron expressions (e.g., 'every day at 9 AM', 'every Monday at 5 PM'). The scheduler service maintains a queue of scheduled executions and triggers them at the specified times. Agents can also be triggered via webhooks, allowing external systems to invoke agents (e.g., a form submission triggers a data processing agent). Webhook payloads are passed as input to the agent, and responses are returned to the caller. The system logs all scheduled and webhook-triggered executions for audit purposes.

Users can share agents with team members by assigning roles (viewer, editor, owner) that control what actions they can perform. Viewers can execute agents but not modify them; editors can modify agents and execute them; owners can modify, execute, and share agents. The system tracks who made changes to agents (via version history) and enforces access control at the API level. Shared agents appear in the user's workspace with a 'shared' badge, and users can see who has access to each agent.

The system tracks execution metrics for each agent: success rate, average duration, credit usage, and error frequency. A dashboard displays these metrics over time, enabling users to identify performance bottlenecks and cost drivers. Detailed execution logs include block-level timing (how long each block took), LLM token usage, and error messages. Users can filter executions by date range, status, or error type. The system alerts users if an agent's success rate drops below a threshold or credit usage spikes unexpectedly.

The Classic AutoGPT component is a standalone agent framework (separate from the Platform) that implements an autonomous agent loop: perceive environment, reason about goals, decompose tasks, use tools, and update memory. The agent maintains a long-term memory of past actions and outcomes, enabling it to learn from failures and avoid repeating mistakes. Tool use is implemented via function calling (OpenAI/Anthropic APIs), and the agent can invoke external APIs, run code, and read files. The Forge toolkit provides utilities for building and testing custom agents, and the agbenchmark framework benchmarks agent performance on standardized tasks.

The agbenchmark framework provides a standardized set of tasks (e.g., 'write a Python script to calculate Fibonacci', 'fetch data from an API and transform it') that agents can be evaluated against. Each task has a clear success criterion (e.g., 'output matches expected result'), and the framework measures success rate, execution time, and cost. Agents are ranked on a leaderboard, enabling comparison across different approaches and implementations. The framework is extensible; developers can add custom tasks and evaluation criteria.

The block system defines a standardized interface (input schema, output schema, execution logic) that developers can implement to create reusable workflow components. Custom blocks are registered in a block registry, versioned, and can be published to a marketplace for discovery and reuse. The backend's block loader dynamically instantiates blocks at execution time based on block type and version, supporting both built-in blocks (AI, integration, data flow) and community-contributed blocks. RJSF is used to auto-generate input forms from block schemas.

The execution system is a distributed microservice architecture where the REST API service receives execution requests, publishes them to RabbitMQ queues, and worker services consume and execute agent graphs. The executor service traverses the DAG, instantiates blocks, passes data between blocks, and handles failures with retry logic. A credit system tracks execution costs (per LLM call, per block type, per execution duration) and enforces rate limits per user. The scheduler manages job queues and worker allocation, enabling horizontal scaling by adding more worker instances.

The backend exposes a WebSocket API that clients can connect to for real-time updates during agent execution. As blocks execute, the system emits events (block_started, block_completed, output_generated, error_occurred) to connected clients, enabling live progress visualization. Streaming outputs from LLM blocks are forwarded directly to clients via WebSocket, reducing latency compared to polling. The frontend subscribes to these events and updates the UI in real-time, showing execution progress, intermediate results, and errors.

Block input schemas are defined as JSON Schema, and the frontend uses RJSF to automatically generate interactive forms for users to configure block parameters. RJSF supports custom widgets for complex input types (file uploads, credential selectors, model dropdowns), and the form validation is performed client-side before execution. The schema-driven approach allows block developers to define input contracts without writing UI code, and users can configure blocks without understanding the underlying schema structure.

The credentials management system encrypts and stores user API keys (for LLM providers, integrations, etc.) in the database, keyed by user ID. At execution time, the system retrieves and decrypts credentials, injecting them into blocks without exposing keys in agent definitions or logs. The system maintains an audit log of credential access (which user accessed which credential, when, from which block), enabling security monitoring. Credentials are scoped to users, preventing cross-user access and enabling multi-tenant isolation.

Every time a user saves an agent graph, the system creates a new version snapshot in the database, storing the complete DAG topology, block configurations, and metadata (creator, timestamp, description). Users can view the execution history for any agent, including which version was executed, execution status, duration, and credit usage. The system supports rolling back to previous versions, and execution history is immutable for audit purposes. Version diffs show what changed between versions (blocks added/removed, parameters modified).

The block system enforces type contracts: each block defines output types (e.g., 'text', 'json', 'image'), and edges can only connect outputs to inputs of compatible types. The frontend validates connections at graph design time, preventing type mismatches. At execution time, the executor validates data flowing through edges and raises errors if types don't match, preventing silent data corruption. The schema-driven approach enables IDE-like autocomplete for block outputs and inputs, guiding users to valid connections.

The marketplace is a curated library of pre-built agents that users can browse, filter by category/use case, and deploy with a single click. Each agent listing includes a description, screenshots, ratings, and usage statistics. Deployed agents are cloned into the user's workspace, allowing customization. The backend tracks agent popularity (downloads, ratings) and surfaces trending agents. Agent creators can publish agents to the marketplace and earn credits or revenue (if monetization is enabled).