docs / what is fred

What is Fred?

Fred is an open-source platform for building and operating AI agents that work with your team's real data — in production, on Kubernetes, under real operational and compliance constraints. The homepage puts it in three words:

Governed· Open· Composable

This page says what each of those actually means.

Governed

Nobody in your organization gets more access than they were explicitly given — and every decision that grants access is provable after the fact.

Fred separates who runs the platform from who uses it. A Cloud Ops / Platform role manages the infrastructure Fred runs on. Separate, per-team roles (Admin, Editor, Analyst, Member) govern what a business team can do with Fred itself — configure agents, review usage, or just chat. Neither role can silently expand into the other's territory.

Every one of those permissions is enforced by a real authorization engine (ReBAC, via OpenFGA) — not a scattering of if user.role == "admin" checks across the codebase. That matters because it means access decisions are declared in one place, auditable, and consistent everywhere they're checked.

This extends down to the tool and agent level: nothing an agent can do — no search tool, no document editor, no specialist agent — is available to a team unless a platform or team admin explicitly turned it on for that team. Every authorization boundary (a grant, a denial, a mismatch) is written to a dedicated security audit trail, queryable in real time.

In practice: a team's Analyst role exists specifically so that team can review how its own agents are being used, without needing infrastructure-level monitoring access. Governance isn't just restriction — it's giving each role the visibility it's responsible for.

Open

Everything Fred does, you can read, fork, and run yourself — Apache 2.0, end to end.

Fred is Apache 2.0, end to end — the full platform is public on ThalesGroup/fred, not an open core with proprietary modules hidden behind it. What you can read is what actually runs.

That also means no lock-in: Fred runs on your own infrastructure — Kubernetes, on-premise if that's what you need — with your own models and your own data stores. You're not a tenant of a hosted service. Models, vector stores, and storage backends are pluggable; you swap one out without leaving Fred.

And it's inspectable: nothing here has to be taken on trust, because the code that decides how the platform behaves is there to read. That's a statement of fact about the platform, not a promise you have to believe.

In practice: clone the repo, run it against your own models and data on your own cluster. Nothing about the platform is hidden behind a paid tier or a hosted-only feature.

Composable

A tool, a whole specialist agent, or eventually a packaged bundle of several agents — all the same kind of thing, added or removed with one switch.

Everything an agent can do beyond its base instructions is a capability — a self-contained module with a name, a description, and an on/off switch a team admin controls. A document-search tool is a capability. A PowerPoint generator is a capability. A specialist agent — a SQL expert, a document-comparison agent — is also a capability, living in the exact same catalog, toggled the exact same way.

That uniformity is what makes Fred extensible without forking it: a team ships its own capability as an installable package, registers it, and it shows up in the same admin screen as everything built-in — no platform release required to add it, no platform release required to take it away.

Where this is heading: a capability doesn't have to stop at one tool or one agent. A whole workflow — several collaborating agents, the background processing behind them, and a dedicated UI — can be packaged and switched on as one capability, the same way a single tool is today.

In practice: give Finance exactly the tools and agents it needs and nothing else; give the Platform team a different set — composed in an admin screen, not negotiated as a code change.

Who this is for

Platform and development teams building and operating AI agents in Python, on Kubernetes, without vendor lock-in.
Infrastructure and security architects evaluating agentic infrastructure where governance and auditability are selection criteria, not an afterthought.
Product and business stakeholders who need a foundation that works for early experimentation and holds up in long-term production.
Regulated organizations where data sovereignty, access control, and audit trails are non-negotiable requirements, not nice-to-haves.