State for agentsRedux vs fate
Research · Agentic engineering · 2026

Redux vs fate: state for agents and agentic engineering

Agents work from context. One hypothesis is that keeping all state in one place helps them. This page compares Redux (Redux Toolkit 2.14.0) and fate (react-fate 1.14.0; 1.0 launched May 14, 2026) on that hypothesis, from two angles: coding agents that write and maintain the app, and agent runtimes whose state is managed in the app.

TL;DR

  • Different centers of gravity, with overlap. Redux is a general-purpose state container (client or server); DevTools can record its actions. RTK Query overlaps with fate's server-data role. fate is a server-data client: a normalized object cache driven by colocated, declarative "views", in the style of Relay but without GraphQL.
  • "All state in one place" means something different in each. Redux exposes a state tree via getState(); serializability is a convention, not a guarantee. fate shares normalized objects and also supports dehydrate()/hydrate(), persistence and request observation. Its data masking gives each component only its declared fields.
  • There are two kinds of agent "context". For an agent's runtime, Redux-style events and reducers are a useful foundation, not a durable runtime. For a coding agent, fate's colocated requirements may help local reasoning; modern Redux also recommends feature folders and colocated slice logic. Neither advantage is a measured agent-performance result.
  • Training data cuts both ways. Redux dates to 2015; fate's alpha launched December 2025. Model familiarity is unmeasured: pin either agent to installed-version docs rather than assume its training data is current.
  • A practical combination: use fate (or another normalized server cache) for remote data, and a Redux-style reducer plus event log for agent and session state such as messages, tool calls, approvals and plans.

At a glance

Redux / Redux Toolkit

since 2015RTK v2.14RTK 3.0 roadmapframework-agnostic
  • One store holding app-wide state (recommended to be serializable). Plain {type, payload} actions go through pure reducers, with Immer handling immutability.
  • createSlice, configureStore, createEntityAdapter, combineSlices, and listener middleware for effects.
  • RTK Query puts server query results in the same store, with tags, polling and OpenAPI codegen. Unlike fate's object cache, it does not automatically deduplicate entities across query results.
  • DevTools provide an action log, state diffs, time-travel, and import/export of action sequences.
  • Since v2.12, agent skill files ship inside the RTK package, so the team is explicitly targeting coding agents.
  • RTK 3.0 is a proposal, not the current API: ESM-only packaging and API refinements are planned; dates and details may change.

fate

alpha Dec 2025react-fate 1.14.0React 19.2+ / Vue / core JS
  • Built by Christoph Nakazawa, formerly on the React/Relay teams. It brings Relay ideas to TypeScript without a GraphQL DSL; Vite tooling or CLI codegen connects server types.
  • Core workflow: view() (a colocated fragment), useView/ViewRef, and useRequest at the root, which composes everything into one request.
  • A normalized cache keyed by __typename + id, with GC. Data masking means each component sees only its declared fields.
  • Actions work with useActionState. You give declarative optimistic updates and fate rolls back automatically.
  • Live views over SSE. Server dataView allowlists. Prisma and Drizzle adapters. HTTP, tRPC and GraphQL transports.
  • The README calls it "AI-Ready". The December 2025 announcement attributes 80% of that implementation to human-curated Codex output—not a measurement of today's codebase.
// Redux: an explicit, named state transition (good for logs and replay)
// JavaScript illustration; add PayloadAction types in TypeScript.
import { configureStore, createSlice } from '@reduxjs/toolkit'
const initialState = { calls: [], results: {}, pending: [] }
const agent = createSlice({
  name: 'agent', initialState,
  reducers: {
    toolCalled:   (s, a) => { s.calls.push(a.payload) },
    toolResolved: (s, a) => { s.results[a.payload.id] = a.payload.result },
    approved:     (s, a) => { s.pending = s.pending.filter(id => id !== a.payload) },
  },
})

const store = configureStore({ reducer: { agent: agent.reducer } })
const selectPending = state => state.agent.pending // narrow context projection

// Separate TypeScript/React sketch; Post/UserView come from your app.
export const PostView = view<Post>()({ id: true, title: true, likes: true, author: UserView })
const post = useView(PostView, postRef)          // sees ONLY these fields
const { posts } = useRequest({ posts: { list: PostView } }) // in the screen root
// In a component: hooks at top level; trigger this callback from a button.
const fate = useFateClient()
const [result, like] = useActionState(fate.actions.post.like, null)
const onLike = () => startTransition(() =>
  like({ input: { id: post.id }, optimistic: { likes: post.likes + 1 } }))
// Failure rolls back the optimistic patch; imports/providers omitted.

Head-to-head for agents

Stronger fitMixed / dependsWeaker fit

Colors indicate architectural fit for the stated task, not benchmark scores. Benefits depend on application design; neither library is an agent orchestrator.

DimensionReduxfate
What "one place of state" means An explicit tree of chosen app-wide state; local UI state need not live here. Select, redact and serialize it before exposing it. A normalized server-data cache with views, hydration snapshots and persistence—not an agent workflow state machine.
Event log / audit / replay DevTools record actions, diffs and time-travel. Durable audit/replay needs an app-owned event log and recorded tool results. No comparable fate-specific action timeline verified. React DevTools, observeRequest and persistence snapshots offer partial inspection.
Coding-agent context footprint Feature folders and a single slice file colocate actions, reducers and selectors; cross-feature effects can still require wider context. Colocated views make dependencies explicit; schema, request root and server changes can still span files. Plausible locality benefit, not benchmarked.
API surface Medium. Better since RTK, but there are still several concepts to keep consistent. Small core workflow, but lists, live views, persistence, transports and codegen add concepts.
Most error-prone code for agents The agent hand-writes reducers and effects. Purity and serializability are rules it must follow. Automates entity updates and optimistic rollback; developers still select related fields, target list insertions and publish live events.
Training-data prevalence Longer public history; legacy examples coexist with modern RTK. Actual model training coverage is unknown. Newer library; model familiarity is unknown. Template AGENTS.md and package-local docs provide explicit guidance.
Type safety as a contract Typed actions, RootState and AppDispatch. Dev middleware checks serializability and mutation. Typed selections and server integration; unselected fields fail type-checking and are undefined at runtime. Masking is not authorization.
Determinism / testability Pure reducers replay deterministically for fixed initial state, actions and reducer version—not for fresh LLM/tool calls. Declarative selections and observable requests are testable; cache identity, GC and live updates add integration cases.
Human-in-the-loop Approval is just an action, and "pending approval" is just state. Possible through actions, but not a natural fit for workflow or session state.
Multi-agent writes One reducer tree. Ordering and ownership need design. There are no per-key merge semantics as in LangGraph. Server is authoritative; live views propagate updates. The app must design authorization and conflict resolution; SSE is not a merge algorithm.
Maturity / stability Redux launched in 2015; Toolkit in 2019. RTK 3.0 breaking changes are proposed, not yet shipped. 1.0 launched May 14, 2026; current react-fate is 1.14.0. Smaller/newer project; CLI codegen remains alongside the Vite plugin.
Adoption cost UI-agnostic JS core. RTK is recommended; integration scope and bundle size depend on imported features. React adapter needs React/DOM ^19.2.0; Vue and framework-free core also exist. Native/tRPC use fate conventions; GraphQL can adapt an existing API. Repo development Node requirements are not browser-runtime requirements.

Redux: pros and cons for agents

Pros

  • Explicit context projections. getState() plus selectors lets you derive a minimal, redacted model input. preloadedState restores supplied state; storage is a separate concern.
  • Event-shaped transitions. Tool requested/resolved/failed and approval events can be modeled explicitly. DevTools make the resulting history inspectable; durable event sourcing must be built separately.
  • A useful orchestration analogy. LangGraph also has typed shared state and reducers, but supplies graph execution/checkpointing that Redux does not.
  • Pure reducers are deterministic. You can write replay tests from recorded LLM output, and agent-written code is easy to verify.
  • Human-in-the-loop is simple. Approvals and rejections are dispatched actions.
  • Listener middleware is an effects layer. The flow is: action → call LLM or tool → dispatch the result.
  • Documented conventions. Named actions make transitions greppable; modern RTK guidance helps agents avoid legacy patterns.
  • Official agent skills ship in the RTK package (v2.12+).
  • Explicit feature ownership. Slice boundaries can help humans and coding agents partition work; they do not resolve conflicting edits automatically.

Cons

  • Cross-cutting dependencies. Shared actions and listeners may affect several features. Colocated slices help, but agents must trace consumers before changing contracts.
  • Outdated idioms in training data. Agents may emit connect, switch reducers, createStore or RTK v1 APIs. RTK 3.0 will add more drift.
  • The global store can bloat context. Dumping the whole tree into a prompt wastes tokens unless you design selectors and projections.
  • Not durable by itself. The store is in memory. A real agent runtime needs an external append-only log, idempotency and schema versioning (upcasters).
  • Serializability is a rule, not a guarantee. Streams, AbortControllers or class instances in state break replay. Large tool outputs bloat snapshots.
  • Replay needs an explicit boundary. Calling reducers alone does not run middleware. Re-dispatching recorded events through live effect middleware can repeat effects; DevTools time-travel is not that same operation.
  • DevTools time-travel is for developers. It does not give agents semantic undo of external side effects.
  • Not an authorization or concurrency system. Validate tool arguments, enforce approvals on the server and define ordering/idempotency; dispatching an action provides none of those guarantees.

fate: pros and cons for agents

Pros

  • Colocation means local reasoning. A component's view says exactly what data it depends on, which may reduce the files an agent needs for a field-level UI change.
  • Data masking limits context. Each unit sees only what it declared. For humans and agents, this is the "least context" principle built into the architecture.
  • A declarative workflow. The author's AI-readiness argument is that explicit requirements and less imperative cache code aid local reasoning—not that agent quality has been measured.
  • Less handwritten cache plumbing. Entity sharing and rollback are built in; apps still specify list placement, related selections and backend live events.
  • Types plus strict selection. Undeclared fields fail type checks; runtime masking limits hidden coupling. This does not replace server permission checks.
  • Built on standard React primitives (Suspense, useActionState, React Compiler), so React knowledge transfers.
  • Server dataView allowlists restrict selectable fields in native/tRPC integrations. Authentication, row-level access and mutation authorization remain app responsibilities.
  • Concrete coding-agent guidance. Templates ship a substantive AGENTS.md; published packages include version-matched Markdown docs. Contributors must disclose AI assistance (with a trivial-completion exception).

Cons

  • Unknown model familiarity. Use installed-version docs and type-check generated code rather than assume the model knows current APIs.
  • The API is still moving (alpha to 1.0, codegen to Vite plugin, new transports), so agent knowledge goes stale quickly.
  • Snapshots are not causal history. Hydration, request observation and persistence inspection exist, but no Redux-like fate action timeline was verified. A cached value alone does not explain why it changed.
  • Server data only. UI, session and agent workflow state live elsewhere, so there is no unified state.
  • Implicit runtime behaviour (normalization, GC, ref identity) makes debugging "why didn't this update?" hard.
  • Masking has a failure mode. If you forget to select a field, you get undefined or a type error. View definitions and ViewRef props are also more verbose.
  • Integration cost. React needs ^19.2.0; Vue/core are alternatives. Server type generation and transport setup require work. Native/tRPC conventions and GraphQL adapters have different requirements.
  • Newer ecosystem. Assess project support and upgrade churn for your workload. The AI-ready claim is the project's own; no comparative agent-quality benchmark was verified.

Is "all state in one place" good for agents?

Where it helps (the Redux direction)

  • Runtime agents: an explicit state machine and durable history can support resume, audit and approvals. Effect Durable Agent is a concrete Redux-inspired example; LangGraph uses shared-state reducers and checkpoints, not the identical event-log architecture.
  • Build the prompt from selected state: preserve full product history separately from the model's bounded working context. Centralization alone neither saves tokens nor makes execution reliable.

Where it hurts (the fate direction)

  • Coding agents: explicit dependencies can make changes easier to scope. A global store does not require loading the entire codebase: Redux's feature slices and selectors also localize reasoning.
  • fate keeps a single store but hands out local, masked views of it. This is a useful shape for agents, also achievable with Redux selectors; fate additionally enforces declared field access and composes fetching.

Synthesis: Centralize the truth, localize the access. The best setup for agents combines Redux's explicit, serializable, logged state with fate's colocated, masked, declarative selection. In practice, use a Redux-style reducer and event log for agent and session state, and a normalized, view-driven client like fate for server data. Give each agent or component a selector or view of the store, not the whole store.

Recommendations

Agent-facing docs and tooling

Redux

RTK 2.12+ bundles skills/ for modern usage, migration, client/server state and effects; agents can read them directly or discover them through TanStack Intent. RTK 2.13 consolidated the official library docs at redux.js.org.

fate

Template AGENTS.md explains views, actions and pitfalls and directs agents to node_modules/react-fate/docs/index.md. The repository root AGENTS.md is only test/lint guidance. Prefer package docs matching the installed version.

Both sites' root /llms.txt returned 404 during verification. No first-party state-inspection MCP integration was verified for either. Documentation retrieval via MCP is not live app-state access. An app-owned read tool could expose a redacted Redux selector or fate selection; write tools still need server-side permission checks and idempotency.

Inspection nuance: fate's introduction documents React DevTools Suspense/Component Tracks support. Current docs additionally expose observeRequest().getSnapshot(), hydration snapshots and fate.persistence.getSnapshot() for queued mutation status. That refutes “the cache is uninspectable,” without establishing an action-log/time-travel equivalent.

Caveats

Sources