docs / what is fred

What is Fred?

Fred is an open-source platform for putting a team to work with AI agents on its own documents — in production, on your own infrastructure, under the access control, audit and evaluation that regulated work actually requires. The homepage puts it in three words:

Governed· Open· Collective

This page says what each of those actually means.

Not just an agent API

Most agent frameworks give you one layer: a way to call a model with tools. Fred gives you four, already wired together.

LangChain, CrewAI, AutoGen, the various "agent SDKs" — they're good at the reasoning loop: tool-calling, planning, multi-agent coordination. Fred uses that ecosystem rather than competing with it. What Fred adds is everything a reasoning loop needs to actually run on your organization's data, for your organization's teams, in production — the parts a thin agent wrapper leaves as an exercise for you.

Corpus Your team's documents, ingested and indexed today — and, as an SDK-defined contract, increasingly able to pull itself from external systems instead of waiting for someone to upload a file.
Capabilities Everything an agent can use, from a single tool to a whole specialist agent — one uniform, admin-governed catalog. See Collective below.
Platform Teams, roles, audit, and now a real application-hosting surface: a team's own product — its own UI, backend, and agents if it has any — can run inside Fred, in its own container, without forking the platform to add it.
Agent SDK fred-sdk + fred-runtime: write and ship your own agent pod independently, on your own release cycle, registered with the platform instead of merged into it.

No single one of these is unique to Fred. Building all four as one coherent, governed platform — rather than an agent loop you then have to wire into your own corpus, your own auth, your own deployment story — is the part other frameworks leave to you.

Where this is going: the platform and capability layers are shipped and in production today. The corpus layer is actively growing the same way — from upload-only toward SDK-defined, self-updating sources. Read more in Beyond Agent Framework Wars.

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.

Collective

Fred is built for a team, not for one person: a shared corpus, shared prompts, and a toolbox each team composes for itself.

A coding assistant on a laptop makes one person remarkably effective. That is a productivity gain, and it stops at that person. Fred is for the other case: the knowledge belongs to a team, the data cannot leave, and the result has to be usable by people who were not in the conversation.

So everything in Fred has an owner. A team has its own corpus, its own prompt library, its own agents, and its own roles — Admin, Editor, Analyst, Member. A member tries something in their personal space first, then proposes it to their team. That is how a practice becomes shared instead of staying in one person's head.

A team's toolbox is composed the same way. Everything an agent can use 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.

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.
Get Started → Read the architecture