Agenta wraps coding harnesses in a shared automation workspace
Agenta puts an organizational layer around agent harnesses. A user describes work in chat, gives the agent files and tools, then can share the configured agent with teammates or run it later from a schedule or connected-app event. Claude Code, Pi, and Codex are supported harnesses. AGENTS.md, skills, and MCP servers define behavior and tools, while Agenta stores configuration versions and traces each run.
This is broader than a chat interface. The self-hosted architecture includes a Next.js studio, 2 FastAPI services, worker processes, an agent runner, PostgreSQL, Redis, SuperTokens, and S3-compatible storage. That stack provides shared workspaces, background jobs, authentication, traces, and durable files. It also means adoption is an operations decision. Someone who only wants to run Codex against a repository will add far more machinery than the coding harness itself requires.
Agents handle variable work; fixed workflows belong elsewhere
Agenta's distinction from n8n, Activepieces, and Zapier is sensible. Those tools express predictable steps and transitions. Agenta gives a model room to plan, call tools, react to results, and revise its approach. The same agent can work with a person in chat and later run in the background. That fits research, document maintenance, triage, and other jobs where the route changes with the input.
It is a poor match when every action can be written down in advance. A fixed 5-step synchronization is easier to audit in a workflow graph than in an agent trace. Agenta does let operators mark tools as automatic, approval-required, or blocked, but permissions do not make model reasoning deterministic. Put judgment-heavy work in the agent and keep predictable transfers, retries, and data updates in a conventional automation tool.
What happened when we ran it
Our sandbox worked in the api/ project at commit 83ae42a. Installation succeeded in 28 seconds, added 35 packages, and occupied 37 MB. The build then succeeded in 7 seconds. Pip-audit reported 0 known vulnerabilities in the installed Python environment. These are good results for that backend slice, though they do not represent the web studio, Docker services, databases, or agent sandbox runtime.
The test command exited with code 4 after 6 seconds, before reporting any collected or passed tests. Pytest read api/pytest.ini and rejected the configured -n and --self-contained-html arguments as unrecognized. The API development dependency group lists pytest-xdist and pytest-html, which correspond to parallel and HTML-report behavior, but the log only proves that those flags were unavailable to the command we ran. It does not establish why the installed test environment lacked them.
Our checkout contained 14,128 files, about 1,430,074 lines of source, and occupied 267.4 MB. The scan found 25 CI workflow files, no Dockerfile, and no top-level tests directory. Docker deployment assets live deeper under hosting/docker-compose, so the scan signal should not be read as an absence of container support. The failed API test remains the relevant developer finding: the measured install and the repository's configured pytest arguments did not line up in our fresh environment.
The default local runner shares files and credentials
Agent execution has 2 documented sandbox choices. Daytona gives each run a separate cloud machine and limits what credentials cross into it. The default local mode runs every harness inside one runner container. Local agents share that container's filesystem, environment, mounts, runner token, and any mounted subscription login. One user's agent can read another user's working directory when both use that boundary.
Agenta's docs correctly limit local runs to one person or a trusted team. They recommend Daytona when several people can start jobs or when users do not fully trust each other. This is more than a performance setting. It determines whether an agent can reach another run's files and secrets. Tool-level approvals can restrict declared actions, but they do not isolate processes that already share the runner container.
Open-source teams get sharing, while governance costs extra
The MIT-licensed edition includes the studio, API, runner, local and Daytona sandbox providers, and team sharing. Self-hosters can use existing Claude, Pi, or ChatGPT subscriptions only with local runs. They can also configure model API providers, connect MCP tools, or use Composio's catalog of more than 1,000 apps. Schedules and events provide the background triggers available today.
SSO, roles, and access controls are enterprise features under a separate license. That boundary matters because the quick-start guide says sign-ups are open by default and each reachable user can create an organization. Before putting Agenta on a public host, administrators need to restrict registration, configure TLS and routing, decide where agents execute, and understand which governance controls their edition provides. A local demo on port 80 does not answer those production questions.
August releases are active, while planned connectors remain planned
Version 0.114.1 was released on August 26, 2026, with work on voice input, tool switches, MCP project secrets, approvals, sessions, and legacy provider records. GitHub showed 4,578 stars and 307 combined open issues and pull requests. The repository was pushed on August 28, with same-day work on streaming, provider authentication, approvals, and a later 0.114.x release. The open count includes pull requests, so it is evidence of a busy queue rather than 307 known bugs.
Several attractive items remain unchecked in the README: generic webhook triggers, OAuth MCP transports, Slack and other messaging channels, and a mobile version. Agenta does support MCP servers using API keys or no authentication, plus Claude Code and Codex as harnesses today. Buy for that current surface. The 35-second API install-and-build result makes evaluation cheap, but the failed pytest configuration and shared local-runner boundary deserve resolution before a multi-user rollout.