# Future AGI self-hosted: tracing, evals and guardrails in one Docker stack

> Future AGI bundles tracing, evaluations, simulations, a Go gateway and guardrails into one Apache 2.0 platform you can run with ./bin/install. The trade-off is a Docker Compose stack of roughly 17 containers before you have evaluated a single prompt.

**future-agi/future-agi** — Open-source, end-to-end platform for evaluating, observing, and improving LLM and AI agent applications. Tracing · Evals · Simulations · Datasets · Gateway · Guardrails. Self-hostable. Apache 2.0.

- Repository: https://github.com/future-agi/future-agi
- Website: https://futureagi.com
- Stars: 2,092 · Forks: 653
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/future-agi-future-agi

## What Future AGI is for, and who ends up running it

The README frames the problem bluntly: teams stitch together evals, observability and guardrails that never close the loop, and the platform collapses those into one feedback cycle it describes as simulate, evaluate, protect, monitor, optimize. That is the pitch. The concrete audience is a team already running an LLM feature in production, with traces they cannot score, a gateway they wrote themselves, and no way to replay a bad conversation after a prompt change.

The repository is Python-first: the top level holds futureagi/, fi-collector/, agentcc-gateway/ and frontend/, with Dockerfiles for the base image, the OSS stack and a separate simulation runner. Topics listed on the repository include llm-evaluation, llm-observability, guardrails, hallucination-detection and opentelemetry, which matches the six capabilities named in the description. If your work stops at prompt iteration in a notebook, this is more machinery than the problem needs.

## How the pieces fit: collector, catalog, gateway, ClickHouse

The architecture is visible in docker-compose.yml rather than in prose. Traces land through fi-collector, which writes to ClickHouse; the compose file comments state that CH_DATABASE cascades to the v1 read path, the CH25 schema and the collector writer, so overriding it points all three at one database. A unified property catalog runs by default in the OSS stack through an isolated Kafka pipeline, with candidate and ordered topics named futureagi.oss.property-catalog.candidates.v1 and futureagi.oss.property-catalog.ordered.v1. The compose file is explicit that user-facing reads stay on a compatibility path until a workspace has an active catalog, which is why upgrades need an explicit backfill step.

Heavier deployments can enable PeerDB CDC through COMPOSE_PROFILES=full. The .env.example describes the default as light, roughly 17 steady-state containers after one-shot bootstrap jobs finish, and full as adding PeerDB. The gateway is a separate Go service with its own image tag (AGENTCC_GATEWAY_VERSION), and the compose file reserves an isolated task queue, exact_aggregation, so analytics jobs cannot starve unrelated work. That separation is a deliberate resource decision, not decoration.

## Installing Future AGI with Docker Compose

The self-host path needs Docker Desktop or Docker Engine with Docker Compose already available. The README gives one command per platform, and the published images mean no source build. Clone the repository, change into it, and run the installer:

```bash
git clone https://github.com/future-agi/future-agi.git
cd future-agi
./bin/install
```

On Windows the README uses PowerShell instead:

```bash
git clone https://github.com/future-agi/future-agi.git
cd future-agi
.\bin\install.ps1
```

When the installer finishes, open http://localhost:3000. The README states that production installs should use ./deploy/setup.sh to generate required secrets and pin the image version, because the compose defaults are local-only values that the production compose file re-binds with error guards.

Instrumenting an agent is a few lines. The README example registers a project and installs the OpenAI instrumentor, after which existing OpenAI calls are traced:

```python
from fi_instrumentation import register
from traceai_openai import OpenAIInstrumentor

register(project_name="my-agent")
OpenAIInstrumentor().instrument()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": query}],
)
```

If you prefer not to run the stack, the README also lists pip install ai-evaluation against the managed Cloud, which keeps the evaluation library local while traces go to app.futureagi.com.

## The upgrade step that catches people out

Upgrading an installation that already holds traces is not a plain restart. The README says to initialize inactive unified property catalogs explicitly after the new stack is healthy:

```bash
./bin/property-catalog-backfill --execute
```

On Windows the equivalent is .\bin\property-catalog-backfill.ps1 -Execute. The README makes three claims about this command that matter operationally: ordinary restarts never start a historical scan, the command uses the image already selected by Docker Compose rather than pulling a branch or image, and it resumes through the catalog's durable ledger. It is bounded to active workspaces and projects admitted by the self-hosted supervisor and to a rolling 366-day source window.

That 366-day bound is the limitation worth internalising. If you keep traces beyond a year and expect the backfill to cover them, the documented window does not. The README also notes the command skips already-active workspaces, so re-running it is cheap but not a repair tool for a workspace the supervisor never admitted.

## Where Future AGI is the wrong choice

The README opens with a warning: this is a nightly release for early testing, expect rough edges, with a stable version coming out soon. That banner sits above everything else, and it should govern how you read the rest. A team that needs a frozen, supported release line for a regulated workload is not the audience for this build, regardless of how complete the feature list looks.

The container footprint is the second constraint. Roughly 17 steady-state containers in the light profile, plus Kafka, plus a ClickHouse writer path, is a real operational surface. If your team has no one who owns Docker Compose, ClickHouse storage and queue workers, you are buying an on-call rotation. The third case is narrower: if you only need request and response logging with cost totals, a single-purpose logging proxy does that with one process. Future AGI is justified when you intend to act on the traces, scoring them and feeding results back into the next version.

## How it differs from Langfuse and Braintrust

The README names its own comparison set: it says you no longer stitch together Langfuse, Braintrust, Helicone, Guardrails AI and a custom simulator. The difference in approach is scope, not quality. Langfuse is an observability and trace store with evaluation features layered on; Future AGI ships a Go gateway with its own routing, a simulation runner with a dedicated Dockerfile, and guardrails as first-class services in the same compose file. The README describes the gateway as OpenAI-compatible HTTP and the traces as OpenTelemetry-native with 50+ framework instrumentors, which is the integration story: you keep your existing client code and point it at the stack.

That breadth is also the cost. A narrower tool gives you one moving part and a smaller blast radius. Future AGI gives you one feedback loop and a compose file with ClickHouse, Kafka, PeerDB and a gateway in it. Pick based on whether the loop is the thing you are missing.

## Licence, maintenance and what an upgrade costs you

The core is Apache 2.0, and the repository carries a separate LICENSE-EE file alongside LICENSE and NOTICE. That means some functionality is governed by different terms than the Apache 2.0 core, and the compose file references an EE_LICENSE_KEY variable defaulting to empty. Which features sit behind that boundary is not stated in the README, so check LICENSE-EE and INSTALLATION.md before you plan a deployment around a specific capability. This is a reading task, not a legal opinion.

Maintenance looks current: the last push to main was on 2026-09-10, and releases v1.37.1, v1.37.0 and v1.36.1 landed on 2026-09-09 and 2026-09-08. The repository is not archived. Frequent point releases also mean your upgrade path is exercised often, which is why the property-catalog backfill exists as a documented step rather than an edge case. Budget for it as part of every upgrade that follows real trace ingestion, not as a one-off fix.

## Conclusion

Adopt Future AGI if you need traces, evals and guardrails in one loop and can run Docker Compose, or if you want the ai-evaluation package alone against the managed Cloud. Skip it if you want a single lightweight library, if your team cannot operate roughly 17 containers, or if you only need request logging. Before committing, verify the container count on your own hardware, run ./bin/property-catalog-backfill --execute after the first upgrade that follows real trace ingestion, and confirm the Apache 2.0 core covers the features you need rather than the separate LICENSE-EE terms.

## FAQ

### What is Future AGI?

It is an open-source, self-hostable platform for evaluating, observing and improving LLM and AI agent applications, covering tracing, evals, simulations, datasets, a gateway and guardrails. The repository describes it as collapsing those into one feedback loop, and the core is Apache 2.0.

### Is Future AGI free?

The core is released under Apache 2.0 and the repository is self-hostable, so there is no licence fee for that part. The README also points to a free Cloud tier at app.futureagi.com, and the repository carries a separate LICENSE-EE file, so check which features fall under which terms.

### What does Future AGI do?

It traces agent runs, runs evaluations over them, simulates edge cases before launch, applies guardrails in real time and routes model traffic through a Go gateway. The README describes the intended cycle as simulate, evaluate, protect, monitor and optimize.

## Sources

- [future-agi/future-agi on GitHub](https://github.com/future-agi/future-agi)
- [License: Apache-2.0](https://github.com/future-agi/future-agi/blob/main/LICENSE)
- [Project website](https://futureagi.com)
- [README](https://github.com/future-agi/future-agi/blob/main/README.md)
- [Releases](https://github.com/future-agi/future-agi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/future-agi-future-agi