# Daydreams: composable contexts for TypeScript agents, and a pivot

> Daydreams is a TypeScript agent framework built around contexts that compose with each other, with MCP integration and a model router that accepts x402 micropayments. The project now says in its own readme that the agent framework is no longer the core focus because its features are obsolete, and points you at a different repository for agent work.

**daydreamsai/daydreams** — Daydreams is a set of tools for building agents for commerce

- Repository: https://github.com/daydreamsai/daydreams
- Website: https://docs.daydreams.systems/
- Stars: 622 · Forks: 137
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/daydreamsai-daydreams

## The readme tells you the framework is obsolete

The most important thing in this repository is a notice at the top of the readme, and quoting its sense is necessary because it changes the answer to any adoption question. The notice says this agent framework is no longer the core focus, because the features are already obsolete. The core focus of the project is now on Agentic Commerce rather than on the agent harness.

The recommendation that follows is explicit: check out the lucid-agents repository, and use the Pi agent harness for building agents, incorporating lucid-agents in it. Both are linked.

So this is a project that moved its centre of gravity. What remains in the tree is still coherent and still instructive, and the commerce pieces, the payment plumbing and the state backends are exactly where the attention went. What you should not do is start a new general purpose agent project on this framework and expect the author to be maintaining it for you.

One detail adds colour to the timeline. The last tagged releases are v0.3.20 on 2025-08-22, v0.3.21 on 2025-08-25 and v0.3.22 on 2025-09-03, while the last push was on 2026-10-09. The repository is not archived, so work continues on the default branch `main`, but the release line stopped in the autumn of 2025.

## Contexts are composable units with their own actions

The core idea is that an agent is assembled from contexts, each of which is an isolated workspace with its own state and its own actions, and contexts can be combined rather than wired together by hand.

A context is created with a type, a schema and a create function that returns its initial state, then given actions with `setActions`. Each action has a name, a schema describing its arguments, and a handler that receives the parsed arguments and a context object:

```typescript
const analyticsContext = context({
  type: "analytics",
  create: () => ({ events: [], sessions: 0 }),
}).setActions([
  action({
    name: "trackEvent",
    schema: { event: z.string() },
    handler: async ({ event }, ctx) => {
      ctx.memory.events.push({ event, timestamp: Date.now() });
      return { tracked: true };
    },
  }),
]);
```

The handler receives `ctx`, and `ctx.memory` is the context's own memory, which is where the event lands. That is the memory claim in the marketing copy, made concrete: memory is the state your create function returned, extended as the agent runs.

Composition happens through `.use()`, which takes a function of the current state and returns the list of contexts to combine, including per-context arguments. The composition step in the documentation reads like this:

```typescript
  .use((state) => [
    { context: analyticsContext, args: { userId: state.args.customerId } },
    // Conditional composition based on customer tier
    ...(state.args.tier === "premium" ? [{ context: premiumContext }] : []),
  ])
  .instructions(
    (state) =>
      `You are a ${state.args.tier} customer support agent. Track all interactions.`
  );
```

The conditional spread matters. Composition is not a static list, it is a function of the arguments the agent was invoked with, so a premium customer can get an extra context that a free customer never sees. Instructions are also a function of state, which means the prompt changes with the tier rather than being a fixed string.

The agent itself is created with `createDreams`, given a model and the list of contexts, and then driven with `agent.send`, which takes a context, the args for it, and the input.

## One router fronts several model providers

Dreams Router is the piece that sits between your code and the model providers. The documentation presents it as a universal gateway where any model is reachable through one API with authentication and payments built in.

```typescript
import { dreamsRouter } from "@daydreamsai/ai-sdk-provider";

// Use any model from any provider
const models = [
  dreamsRouter("openai/gpt-4o"),
  dreamsRouter("anthropic/claude-3-5-sonnet-20241022"),
  dreamsRouter("google-vertex/gemini-2.5-flash"),
  dreamsRouter("groq/llama-3.1-405b-reasoning"),
```

The provider strings follow the familiar `provider/model` shape, and the listed features are universal access across OpenAI, Anthropic, Google, Groq and xAI among others, OpenAI compatibility so existing OpenAI SDK clients work, and automatic fallbacks for provider redundancy.

The interesting part is the payment model. The router is described as pay-per-use with USDC micropayments and no subscriptions, and the example shows an account being authorised with a payment amount and a network:

```typescript
const { dreamsRouter } = await createDreamsRouterAuth(account, {
  payments: { amount: "100000", network: "base-sepolia" }, // $0.10 per request
});
```

The comment in that snippet does the arithmetic for you, with an amount of 100000 on base-sepolia equalling ten cents per request. This is the x402 pattern: a payment per call rather than a monthly plan, which is why the repository topics include x402 and erc8004. A hosted instance is available at router.daydreams.systems, with its own quickstart and reference pages in the docs folder.

## MCP servers arrive as extensions with stdio transports

Integration with external tools goes through the Model Context Protocol, and the wrapper for it is `createMcpExtension` from the `@daydreamsai/mcp` package. Servers are described as objects with an id and a transport, and the transports in the examples are stdio, meaning the process is launched locally:

```typescript
        id: "filesystem",
        transport: {
          type: "stdio",
          command: "npx",
          args: ["@modelcontextprotocol/server-filesystem", "./docs"],
        },
```

The second example does the same for a SQLite server with `npx @modelcontextprotocol/server-sqlite ./data.db`. Both are the standard MCP server packages, launched through npx.

Actions then reach those servers through the context object with `ctx.callAction`, passing an action name such as `mcp.listResources` or `mcp.callTool`, the server id, and the arguments. The database case passes a SQL query as a tool argument.

One thing to notice about that pattern is that the SQL string is built by interpolating the query parameter directly into the statement. If you copy that shape into your own agent, parameterise it rather than interpolating, because the query text arrives from the model and the model is the untrusted part of this arrangement.

## The stack behind the framework is a graph of state backends

The compose file in the repository is not an application server, it is a set of state stores, and it gives a clear picture of what the framework expects to run against. Memgraph appears twice, as `memgraph/memgraph-mage` on ports 7687 and 7444 running with trace level logging, and as `memgraph/lab` on port 3000 for visualising the graph, with the lab configured to connect to the database through the environment. Chroma is there for vectors, pinned to `chromadb/chroma:1.0.17` on port 8000, and MongoDB to `mongo:8.0.4` on port 27017.

A graph database next to a vector database next to a document database is the interesting part of this stack. It says the agent memory model is not a single store: relationships, embeddings and documents are kept apart, and an agent that needs to recall across all three queries all three.

The environment template matches that audience. Alongside the model keys for Groq, OpenRouter and the Dreams router, it holds Twitter credentials, Starknet RPC settings, Paradex account details with a chain id and a base URL, Avnu and GraphQL endpoints pointing at Sepolia, Hyperliquid wallet addresses and a private key, Sui network and key settings, and a `DRY_RUN` flag that defaults to 1. Those blockchain variables are not incidental: they are the Agentic Commerce layer the project says it now focuses on, and the examples folder carries matching directories for CDP, basic, episodes, mcp, server, social and x402.

## A pnpm monorepo with pinned catalog versions

The repository is a pnpm workspace with packages under `packages/*`, built with tsup and typed into API docs with typedoc. The workspace catalog pins the shared dependency versions in one place, which is what makes a monorepo like this reproducible: zod at 4.1.12, typescript at 5.9.2, the `ai` package at 5.0.81, tsup at 8.3.6, vitest at 3.0.5, and the Model Context Protocol SDK at 1.12.0, along with the AI SDK adapters for Anthropic, Groq, OpenAI and Google and the OpenRouter provider.

The scripts section is thorough for a project of this size: recursive tests, a filtered test for the core package, a watch mode, build and release shell scripts with dry-run variants, clean variants, prettier check and write, knip for unused code detection, and separate documentation commands including a typedoc build. There is also a `knip.config.ts`, a `prettier.config.cjs` and a `.nvmrc`, and the lockfile is `bun.lock` even though the workspace tooling is pnpm, which tells you both runtimes have been in play.

The licence is MIT, in a file named `licence.md` with the British spelling, and the repository carries `SECURITY.md`, `CONTRIBUTING.md` and `CLAUDE.md` alongside the changelog. The documentation site is generated from the `docs` folder, with the router reference living under `docs/content/docs/router`.

Installing the core pieces takes one command:

```bash
npm install @daydreamsai/core @ai-sdk/openai zod
```

## Conclusion

Daydreams is worth reading if you are building commerce agents and want the x402 payment plumbing, the ERC-8004 topic tag, or the router with its provider fallbacks, and you can accept a framework its authors describe as obsolete. It is a poor fit as a general agent harness, because the project directs that use to lucid-agents and the Pi agent harness. Before you build on it, read the notice at the top of the readme, check the `examples` folder for the commerce flows you actually need, and remember that the last tagged release is v0.3.22 from 2025-09-03 even though the last push was on 2026-10-09.

## FAQ

### Is the Daydreams agent framework still maintained?

The readme carries a notice saying the agent framework is no longer the core focus, because its features are already obsolete, and that the project's focus is on Agentic Commerce. It points to the lucid-agents repository and recommends the Pi agent harness for building agents.

### How do I compose contexts in Daydreams?

Use `.use()` on a context with a function of the current state that returns the contexts to combine, optionally with per-context args. The result can be conditional, since the example adds a premium context only when the tier argument matches.

### What is the Dreams Router and how does it charge?

It is a gateway that lets you reach models from several providers through one API, with automatic fallbacks and OpenAI compatibility. Payment is pay-per-use with USDC micropayments rather than a subscription, for example an amount of 100000 on base-sepolia for ten cents per request.

### Which databases does Daydreams expect to run against?

The compose file in the repository starts Memgraph with its lab interface, Chroma for vectors and MongoDB. The environment template also configures model keys and blockchain settings for Starknet, Paradex, Avnu, Hyperliquid and Sui.

### How do I connect an MCP server to a Daydreams agent?

Use `createMcpExtension` from `@daydreamsai/mcp` and pass server descriptors with an id and a transport, for example a stdio transport that launches `npx @modelcontextprotocol/server-filesystem`. Inside an action, the server is reached through `ctx.callAction` with names such as `mcp.listResources` or `mcp.callTool`.

## Sources

- [daydreamsai/daydreams on GitHub](https://github.com/daydreamsai/daydreams)
- [License: MIT](https://github.com/daydreamsai/daydreams/blob/main/LICENSE)
- [Project website](https://docs.daydreams.systems/)
- [README](https://github.com/daydreamsai/daydreams/blob/main/README.md)
- [Releases](https://github.com/daydreamsai/daydreams/releases)

---

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