Agenta: a self-hosted workspace for building agents that run on a schedule

The problem Agenta targets: agents that live in one person's terminal

Most agent tooling today produces something that only its author can run. The agent is a folder of prompts and scripts on one laptop, tied to one model, invoked by hand. Agenta's pitch is that the agent becomes a shared artifact: you build it by chatting with it, you connect the apps it needs, and you share it with your team. The README frames the workspace as a place where you and the agent work on files together, writing documents, organizing research or maintaining a wiki. The second half of the pitch is recurrence. For work that repeats, Agenta offers background agents that run on a schedule or when an event occurs in a connected app. That is a different product category from a chat client. It is closer to a job runner whose jobs happen to be language-model agents, with the model calls, tool calls, token usage and estimated costs recorded per agent. The audience is a small team that has already decided agents are useful and now needs them to survive past the demo, without standing up a bespoke orchestration layer around a CLI.

How an agent is defined: AGENTS.md, skills and MCP servers

Agenta leans on conventions that already exist in the agent ecosystem rather than inventing a schema. The README states that you define an agent with AGENTS.md, skills and MCP servers, and that you can bring skills and MCP servers in from elsewhere. That choice matters because it means the agent definition is portable text, not a proprietary graph. The harness is a separate axis: Agenta supports Claude Code, Pi and Codex as harnesses today, and the README says more are planned. Model choice is broader, described as almost any model, self-hosted or behind an API. The practical reading is that the harness is the execution loop and the model is a parameter inside it, so you can swap either without rebuilding the agent. The repository is primarily TypeScript, with a Python package published on PyPI under the name agenta, which suggests the server side and the SDK do not share a language. I cannot confirm from the supplied material how the two halves communicate or where the boundary sits; the README does not describe the architecture, only the user-facing concepts.

Background agents and the permission model that makes them tolerable

An agent that runs on a schedule without a human watching is an agent that can send the wrong email at 3am. Agenta's answer is per-tool permissions. The README states that you specify permissions for each tool and choose which actions background agents can run automatically, which need your approval and which are blocked. That is a three-state model rather than a binary allow or deny, and the middle state is the interesting one: a background run can pause and wait for a person. The README does not say how long an approval can pend, what happens if nobody responds, or whether approvals are delivered through a specific channel. Those are the questions that decide whether the model works in practice, and the supplied material does not answer them. Integrations arrive two ways: directly through MCP, or through Composio, which the README describes as covering more than 1,000 apps including Gmail, Slack, Notion and GitHub. Composio is a third-party dependency, so the reach of your integrations is bounded by someone else's catalogue and pricing, not by Agenta alone.

Getting it running: cloud first, self-hosting for the subscription trick

The README offers two paths. The fastest is Agenta Cloud, linked at cloud.agenta.ai. The self-hosted path is the one with the distinctive claim: when you self-host Agenta, the README says you can run agents locally with your existing Claude or ChatGPT subscription, so you do not have to move every task to metered API billing. That is the single most concrete reason to pick Agenta over a hosted alternative, and it is also the reason the self-hosted path carries the operational burden. Beyond that framing, the supplied README is truncated before it reaches the installation commands, so I cannot give you a docker compose invocation, an environment variable name or a port number without inventing them. The honest position is that the setup instructions live in the documentation at agenta.ai/docs, and the repository also publishes a Python package on PyPI, which is the likely entry point for programmatic use. Treat the docs, not this article, as the source for exact commands. What I can say from the material is that the project ships frequently: three releases, v0.115.2 through v0.115.4, landed within a week in September 2026, with the latest push to main on 10 September 2026.

The licence is the first thing to check, not the last

The repository metadata reports the licence as NOASSERTION, which means GitHub's classifier could not map the LICENSE file to a known identifier. The README, meanwhile, displays an MIT badge. Those two signals disagree, and the badge is the weaker one: a shields.io image is a string in a markdown file, not a legal statement. Until you open the LICENSE file in the repository and read it, you do not know the terms. This is not a hypothetical concern for a product whose selling point is self-hosting. If your organisation's policy requires an OSI-approved permissive licence, or if you intend to embed Agenta in something you distribute, the classifier result is a stop sign until resolved. I am not giving legal advice here; the point is narrower. The material available to me contains a contradiction about licensing, and the only way to settle it is to read the file. Do that before you spend a sprint integrating MCP servers against it.

Where Agenta is the wrong tool

The failure mode that the README implies but does not dwell on is operational. Agenta is a self-hosted service, and the team-access feature, role-based access control and run tracing all live inside that service. If nobody on your team will own upgrades, you will be running an old build. The release cadence gives a sense of the surface area: patch releases on 7, 9 and 9 September 2026, with a version number already past 0.115. That is a lot of version churn for a system you are expected to keep available for scheduled jobs. A second boundary is the harness list. Claude Code, Pi and Codex are supported today; anything else is a promise, not a feature. If your team has standardised on a different agent runtime, Agenta is not currently the tool for you. Third, the approval workflow for background agents is only as good as its notification path, which the material does not describe. If your scheduled agents touch production systems, verify that path before you let one run unattended.

How it differs from wiring agents together yourself

The obvious alternative is composition: take an agent CLI you already use, wrap it in a scheduler such as cron or a workflow engine, and store prompts in a git repository. That approach gives you total control and no new dependency, and for a single developer running two jobs it is probably the right answer. The difference in approach is what Agenta adds on top of the runtime. A scheduler runs a command; Agenta keeps a version history of each agent configuration and traces every run, so you can compare changes and understand failures, in the README's phrasing. A scheduler has no concept of per-tool permissions or human approval; Agenta does. A scheduler gives you no shared workspace where a teammate can open the same agent and continue the work. You can build all of that yourself, and teams do, but you are then maintaining an orchestration layer whose only user is your own company. Agenta's bet is that this layer is generic enough to share. The counter-bet is that a general layer will not fit your specific approval rules, and you will end up forking it. Which bet wins depends on how unusual your workflow is.

Maintenance cost and what to verify before you commit

Two cost centres are visible from the material. The first is upgrades. Between 7 and 9 September 2026 the project published three patch releases, and the version number sits above 0.115, which tells you the API and configuration surface are still moving. Plan for a regular upgrade cycle rather than a set-and-forget deployment, and read the release notes for each bump before applying it. The second is integration dependency. Composio provides the 1,000-plus app catalogue, so your Gmail, Slack, Notion and GitHub connections route through a third party even when Agenta itself runs on your hardware. That is a supply chain you should name explicitly in any internal review. Before adopting, verify four things: the actual licence text in the repository, since metadata and README disagree; the current harness list in the docs, since the README describes planned additions rather than shipped ones; the behaviour of a pending human approval when a scheduled agent blocks on it; and the upgrade procedure, because you will be using it often. If those four checks come back clean for your team, Agenta is a reasonable way to keep agent work on a subscription you already pay for instead of a meter that runs while you sleep.

Editorial conclusion

Adopt Agenta if you already pay for Claude Code, Pi or Codex access, want agents that run on a schedule against Gmail, Slack, Notion or GitHub, and are willing to operate the runtime yourself. Do not adopt it if you need a permissively licensed codebase you can fork without reading a lawyer's summary, or if you have no capacity to run and upgrade a self-hosted service. Before committing, open the LICENSE file and confirm the actual terms, then check the docs for the current supported harness list, because the README says more harnesses are planned rather than shipped.

Official sources

1. Agenta-AI/agenta on GitHub
2. Issues
3. Project website
4. README
5. Releases