Fred Roadmap
Fred today
Fred already covers most of what it takes to bring an agentic system into production. You can build ReAct agents, graph-based agents, and coordinated teams of agents, each backed by a typed SDK and a runtime that handles execution, memory, and streaming. Individual capabilities — tools, models, and agent templates — are independently governed per team, with a full audit trail of every access decision. Deployment is cloud-native by default, evaluation is a first-class citizen rather than an afterthought, and the interface can be extended without touching Fred's core.
Individually, none of this is new. What Fred needs next is to make these pieces work together as one coherent story:
Our vision for the next three months
A coherent developer journey
Much of what a developer needs already exists across Fred and its companion projects for evaluation and deployment. Today, using all of it together takes more effort than it should. Our priority is to make the path from a local build to an evaluated, deployed, operated agentic application coherent and well-documented end to end — with reference examples that actually run, consistent versioning, and documentation that reflects what's genuinely production-ready rather than lagging behind it. This is largely about connecting and clarifying what's already there, not inventing new layers.
Extensible agentic applications
Third-party teams should be able to extend Fred without modifying the platform itself. Agents already work this way: an external team can author one against the SDK and register it with a running Fred deployment. We're extending that same model to processors — the components that transform and ingest data, such as turning a spreadsheet into a knowledge graph. A processor should be a self-contained, independently deliverable unit, the same way an agent already is, rather than code that has to live inside Fred's core ingestion pipeline.
The underlying idea is composability, not a growing list of new frameworks-within-the-framework. A team assembles an agentic application from independent, well-governed building blocks — agents, tools, models, processors, and UI contributions — rather than being handed a single, one-size-fits-all structure to fill in.
That same principle now extends one level further: a team can host an entire independently built product surface — its own UI, and optionally its own API — inside Fred's shell, without forking Fred or rebuilding it alongside their own release cycle. It's governed the same way everything else is, through the platform's existing team and capability model, rather than a separate plugin system bolted on top.
Distributed and durable execution
Fred already pairs a fast synchronous API with Temporal-backed durable workflows for ingestion and evaluation — see Durable execution. The next step is extending that same pattern to agents themselves: letting a graph of agents and teams of agents cross runtime boundaries, with one agent invoking another that's deployed independently, elsewhere.
Two different needs sit behind that, and we're treating them as distinct rather than collapsing them into one mechanism. Some agent-to-agent interactions are conversational — one agent needs an answer from another within the same exchange, and that call should be fast and direct. Others are delegations of longer-running work, where the calling agent hands off a task that may take minutes or hours and needs to survive a restart, be retried, and be tracked to completion. For that second case, we're extending Fred's durable execution model so it becomes a standard option for agents, not just for ingestion and evaluation. The result is a platform where independently deployed components can genuinely collaborate as one system, whichever kind of interaction the task calls for.
Platform-wide guidance, without breaking the platform
Today, the only thing that sits above every agent's own instructions is a fixed, non-editable output contract. An operator running a Fred deployment has no way to add deployment-wide guidance — tone, organizational context, a standing disclaimer — without editing every agent individually. We're building a platform-wide instruction layer that renders ahead of every agent's own system prompt, paired with a second, fixed layer of baseline behavior an admin cannot accidentally break. The split is deliberate: personality and organizational context stay editable; the guarantees the platform depends on for reliable behavior do not.
Alongside this, we're working through how much of what gets sent to a model on every single call is duplicated or redundant — tool descriptions repeated across overlapping specifications, formatting instructions restated where a shorter contract would do — and cutting it down, since every token in a system prompt is paid for on every turn, not just the first.
Our architectural direction
Fred is built on composable building blocks, each independently discoverable, deployable, and governed:
This is a deliberate choice: rather than defining a single, opinionated application structure that every team must fit into, Fred lets teams compose their own applications from primitives the platform already knows how to secure, observe, and operate.
This keeps Fred open at the edges. A team's application can be as simple as one agent with a couple of tools, or as involved as a graph of agents, several processors, and a custom panel in the interface — with no lock-in to a single application shape, and no growing core just to accommodate what teams want to build on top of it.
What success looks like
Success is an external developer who can pick up Fred, build an agent or a small team of agents against the SDK, add a processor to handle their own data source, evaluate the result against real scenarios, deploy it through the standard pipeline, and operate it with the same visibility the platform gives every other team — all without forking Fred or waiting on its core team. Fred stops being a framework you run agents on, and becomes the platform a team builds, ships, and operates its own agentic application with.