Agenta Documentation

repository·main·Indexed 26 days ago

https://github.com/agenta-ai/agenta

Agenta is an open-source workspace for building, running, and managing AI agents. It supports interactive chat and autonomous background agents with built-in observability, team collaboration, and model harnesses. The documentation covers architectural design for public edge, cross-service, and in-service interfaces, as well as guides for database migrations using Alembic and the generation of Python and TypeScript client packages.

Tokens
253.7K
Snippets
490
Records
1.2K
Agent score
89%

What's inside Agenta

  1. Overview of Agenta features

    main

    Agenta is an open-source workspace for building, running, and sharing specialized agents. Key features include:

    • Workspaces: Shared environments for collaborating with agents on files (documents, research, wikis).
    • Human Approval: Granular permissions for tools, allowing you to specify which actions are automatic, require approval, or are blocked.
    • Background Agents: Agents that run on a schedule or are triggered by events in connected apps.
    • Observability: Tracing for every model and tool call, including tracking token usage and estimated costs.
    • Integrations: Support for MCP (Model Context Protocol) servers and over 1,000 apps via Composio (e.g., Gmail, Slack, Notion, GitHub).
    • Team Access: Role-based access control for sharing agents within a team.
  2. Overview of Agent Workflow Interfaces

    main

    The Agenta agent workflow stack is composed of several layers: a Python service, a Node runner, a sandboxed harness, a browser client, the vault, and a trace pipeline. Because these components interact across different processes and services, they rely on specific contracts (interfaces).

    Interfaces are categorized by their blast radius:

    • Public edge: Contracts used by browser and workflow clients. Changes here are highly sensitive as they affect external callers.
    • Cross-service: Contracts that cross process, container, or external service boundaries (e.g., between the service and the agent runner). These require careful version management as different sides may deploy at different times.
    • In-service: Contracts that stay within a single process or package. These affect internal adapters, tests, and extension points.
  3. Overview of the Sessions domain

    main

    The sessions domain serves as the durable coordination layer for agent sessions in Agenta. It is divided into several sub-domains that manage state, live streams, event records, human-in-the-loop interactions, and file system mounts.

    Sub-domains

    Sub-domainResponsibilityStorage
    statesManages durable SDK SessionRecord and sandbox resume pointers.Postgres (session_states)
    streamsHandles live control, ownership, heartbeats, and liveness for ACP streams.Postgres (session_streams) + Redis
    recordsManages append-only persisted session stream contents (events).Tracing DB (records)
    interactionsManages Human-in-the-loop (HITL) requests like approvals, inputs, and tool confirmations.Postgres (interactions)
    mountsProvides durable object-store mounts for agent working directories.Postgres (mounts)
  4. Overview of Stateless Playground

    main

    The Stateless Playground is a project-level feature in Agenta that provides a playground experience without being bound to a specific application.

    Key characteristics include:

    • Project-level access: Accessible at the same level as evaluations or prompts.
    • Shared Service: Always runs against the shared completion service (and eventually chat).
    • Draft-only mode: All variants and revisions are treated as drafts; users cannot save changes.
    • Functionality: Allows users to create prompts, run them, and add test cases without being connected to a pre-existing prompt.
  5. Overview of SDK local tools feature

    main

    The SDK local tools feature allows standalone Agenta Python SDK users to run an agent's tools during a fully local execution. This setup requires no Agenta backend service and no sandbox-agent sidecar.

    It works by resolving an agent's tool references into runnable specifications and supplying the necessary secrets, all without calling the Agenta service. This feature is designed to work in conjunction with the LocalBackend engine, which moves the agent runtime into the SDK to run a harness on the user's own machine.

  6. Overview of @agenta/* workspace packages

    main

    The @agenta/* packages are internal workspace packages within the Agenta monorepo. They provide shared utilities, UI components, and entity definitions used across the platform.

    Available Packages:

    • @agenta/shared: Shared utilities, state atoms, and API helpers (Active).
    • @agenta/ui: Shared UI components including tables, selection systems, and presentational components (Active).
    • @agenta/entities: Entity definitions and data fetching atoms (Planned).
  7. Overview of Agenta

    main

    Agenta is an open-source workspace designed for building and running specialized AI agents. It allows you to build agents through conversation, connect them to various applications, and deploy them to run either interactively with your team or as background agents triggered by schedules or events.

    Key capabilities include:

    • Model & Framework Agnostic: Switch between different running frameworks (like Claude Code or Pi) and models (OpenAI, Anthropic, Ollama, etc.) without rebuilding your agents.
    • Open Standards: Build using AGENTS.md, skills, and MCP (Model Context Protocol) servers.
    • Reliability & Versioning: Track every execution and maintain version history for agent configurations to analyze failures and compare changes.
    • Background Agents: Automate repetitive tasks via scheduled runs or event-based triggers from connected applications.
    • Observability: Monitor model calls, tool usage, token consumption, and estimated costs.
    • Integration: Connect to apps via MCP or Composio (supporting 1000+ apps like Gmail, Slack, Notion, and GitHub).
  8. Overview of Agenta View Improvements

    main
    The Agenta View Improvements initiative focuses on consolidating and improving the display of data values (JSON, chat messages, text, inputs/outputs) across the platform. The goal is to resolve readability issues in observability and traces by moving away from raw JSON strings toward structured, role-based displays and providing view mode switching (JSON, rendered, text, markdown).
  9. Overview of AI Services (Tool Calls) REST API

    main

    The AI Services workspace defines a REST API designed for "tool call" shaped AI services. This allows agents to interact with specific AI-driven tools as part of their workflow.

    Currently, the implementation includes a single tool:

    • tools.agenta.api.refine_prompt: A tool that calls a deployed prompt within an internal Agenta organization.

    Note: For the refine_prompt tool, Bedrock credentials are managed within the Agenta app configuration rather than through backend environment variables.

  10. Overview of HTTP (remote) MCP transport

    main

    The HTTP (remote) MCP transport is a design feature in Agenta that enables Model Context Protocol (MCP) servers to be accessed over HTTP rather than via stdio. This approach is intended to be simpler than stdio because it avoids launching child processes, managing command/args/npx bootstrapping, and handling per-process scoped environment variables.

    Key characteristics include:

    • Secret-aware: It leverages Agenta's existing named-secret resolution system.
    • Simplified Runner Delivery: It removes the need for complex process management.
    • Configuration: The SDK resolver and configuration already support transport: "http", url, and named secrets for serialization to the /run wire.
  11. Overview of Build-kit Tools Cleanup

    main

    The Build-kit tools cleanup is a design initiative to redesign the playground build kit (the 'inside' tool set used by a playground agent to build itself). The goal is to execute verdicts from the builder tooling review and port the agent-creation-lab playbook into the inside skills.

    Key objectives include:

    • Renaming discovery operations (discover_tools, discover_triggers) via a hard migration.
    • Reducing the default tool overlay from 19 tools to approximately 13 using an explicit list in overlay.py.
    • Moving logic-bearing internal tools (like test_run) to run as server-side handlers on the existing tool-call plane, registered through the platform catalog.
    • Replacing multiple cross-referencing authoring skills with a single ordered playbook skill.
    • Maintaining zero changes to approval semantics in op_catalog.py.