Trinity: a self-hosted runtime that puts each AI agent in its own Docker container

The problem Trinity addresses: agent sprawl without a control plane

The README frames the choice as three bad options. SaaS agent platforms move data outside your security perimeter and create vendor lock-in. Custom builds take what the README claims is 6 to 12 months and 500K or more in engineering. Frameworks, in its phrasing, give you no observability and no fleet management. Trinity's answer is to be neither a framework nor a hosted service: it is a runtime you install, and the agents it runs live in Docker containers on your machines. The intended audience is an operator who already has infrastructure and wants agents to be a workload on it, with scheduling, health monitoring, cost tracking and an audit trail attached. That is a narrower audience than the word platform suggests. If you want to call a model from inside an existing Python application, Trinity is the wrong shape of software, because the unit of deployment is a container and the unit of management is a fleet.

Container-per-agent isolation and what sits around it

The architectural claim repeated throughout the README is that each agent runs in its own isolated Docker container. Around that, the platform layers real-time observability, fleet-wide health monitoring, cron-based scheduling, agent-to-agent delegation and cost tracking. The v0.9.0 release notes add bidirectional A2A, which means agents can both initiate and accept delegation rather than only receiving it. The architecture explainer video is described as following a single scheduled task end to end through the container, a gate, delegation, an approval step, the audit trail and breaker machinery. That list is the most concrete description of the runtime loop available in the supplied material, and it implies two things worth noting. First, there is an approval checkpoint in the path, so not every agent action is unconditionally autonomous. Second, a breaker exists, which suggests the project expects agents to fail repeatedly and needs a way to stop that. How those components are configured is not spelled out in the README excerpt, so treat the gate and breaker as features to verify in docs/user-docs rather than as documented guarantees.

Getting it running: trinity-cli, Docker and one database switch

The badges indicate Python 3.13, Vue 3 on the front end, and Docker as a requirement rather than an option. The CLI ships as the trinity-cli package on PyPI, so installation runs through pip or a comparable installer against that package name. The README's quick start section is referenced by anchor but its contents are not reproduced in the material available here, so the exact bootstrap commands cannot be quoted. What is documented precisely is the database decision. SQLite is the zero-config default for local development and evaluation. Production instances should run PostgreSQL, and you opt in with a single DATABASE_URL environment variable, with the setup guide at docs/POSTGRESQL_SETUP.md. For anyone already on SQLite, the README points to the Trinity Ops Agent repository and its /migrate-to-postgres skill, described as a gated, validate-then-cutover flow that leaves the SQLite file untouched so rollback is immediate. There is also a pointer for automated readers: AGENTS.md is described as a task router with exact commands, key facts and verification steps.

The v0.9.5 release candidates and what the version number tells you

The most recent tags are v0.9.5-rc1 and v0.9.5-rc2, both dated September 2, 2026, with the repository last pushed on September 10, 2026. A release candidate at the 0.9.x line is a specific signal: the project is still pre-1.0, interfaces can move between minor versions, and the newest work is published for testing rather than as a stable target. The stable milestone in the supplied material is v0.9.0 from August 17, 2026, which introduced Workspace as a client-facing surface, fresh-install provisioning with a remote template registry, a GitHub import wizard, manifest install UI and guided credentials, a multi-source skills library, bidirectional A2A, dashboard list and grid views, and automatic database backups. That is a large amount of surface area added in one release. For an operator, the practical consequence is that pinning to v0.9.0 and reading docs/releases/0.9.0.md before upgrading is more defensible than tracking main.

Where the model breaks down: SQLite in production and container overhead

The README's own warning is the clearest limitation in the material. PostgreSQL is recommended for production, and SQLite is positioned as the default for local development and evaluation only. Anyone who deploys the zero-config path and then grows into real usage is on a migration path, not a supported production configuration. The existence of a dedicated gated migration skill for that move suggests the project expects it to happen often and to need care. The second limitation is structural. Container-per-agent isolation buys you separation and observability at the cost of a Docker dependency on every host, plus the image and volume management that comes with it. The README does not describe resource limits per container, so whether one runaway agent can starve its neighbours is not answerable from the material provided. Third, the README is written with a strong commercial voice, complete with a comparison table asserting that frameworks have no observability. That table is marketing copy, not a benchmark, and the claim that a custom build takes 6 to 12 months and 500K or more is unsourced. Read the architecture video and the docs rather than the comparison table.

How it differs from LangGraph and from managed agent services

The nearest category neighbours are agent orchestration libraries such as LangGraph, where you compose a graph of nodes and run it inside your own Python process. The difference is the unit of isolation. With a library, agents share an interpreter, a dependency set and a failure domain with your application, and you own the observability layer yourself. Trinity pushes each agent into a container, which gives you process and filesystem separation and a place to attach scheduling, health checks and an audit trail without writing them. The cost is that you now operate a platform rather than import a package, and you cannot call an agent as a function inside a request handler. At the other end, managed agent services remove the operations work entirely but place execution and data outside your perimeter, which is the exact trade the README is arguing against. Trinity's position is only coherent if data residency or infrastructure control is a real constraint for you. If it is not, the container and PostgreSQL overhead buys you little that a managed service does not already provide.

Licence, maintenance and the cost of staying current

Trinity is Apache 2.0, which the README notes is free for any use including commercial, and the project states it deploys anywhere you run it. Apache 2.0 includes an express patent grant and requires attribution and notice retention, but this is a general description of the licence and not legal advice; check the LICENSE file and your own counsel for your situation. On maintenance, the material shows an active cadence: v0.9.0 in mid-August 2026, two release candidates in early September 2026, and a push on September 10, 2026. The project also points to a separate repository, trinity-ops-public, for operational tooling, which means upgrades may involve two codebases rather than one. The README claims independent penetration testing with an UnderDefense Grade A result and states the maintainers run Trinity in production themselves. Those are claims by the project about itself, and the supplied material contains no report to inspect. Budget for the PostgreSQL migration and for reading release notes before each minor bump, because a pre-1.0 project at this release velocity will change things.

Editorial conclusion

Adopt Trinity if you need agents running on infrastructure you control and you are willing to operate Docker plus PostgreSQL, since the README recommends PostgreSQL for production and SQLite only as the local default. Do not adopt it if you want a library to import into an existing Python service, or if a managed SaaS agent product already satisfies your data-residency rules. Before committing, verify the PostgreSQL migration path described in docs/POSTGRESQL_SETUP.md, check the trinity-cli version on PyPI against the v0.9.5 release candidates, and read AGENTS.md for the exact commands the maintainers expect an automated reader to run.

Official sources

1. Abilityai/trinity on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases