Feature Request: Pick and choose Agent functionality

[stephencoffey]

(edit by @threepointone: see #846 (comment))

Problem

Currently, all 5 database tables are created in the Agent constructor on every instantiation:

• cf_agents_state
• cf_agents_schedules
• cf_agents_queues
• cf_agents_mcp_servers
• cf_agents_workflows

Many agents only use a subset of these features (e.g., just state management for a simple stateful agent), but still incur the overhead of creating all tables.

Cost Impact

Cloudflare Durable Objects are billed based on storage and operations. Currently:

• Every Agent instance creates 5 SQLite tables on instantiation
• Many agents only use 1-2 features (e.g., just state management)
• This results in unnecessary storage overhead and write operations

At scale (thousands of agent instances), this can lead to meaningful cost increases for users who don't need all features. Lazy table creation would ensure users only pay for storage they actually use.

Proposed Solution

1. Lazy table creation: Create tables on-demand when features are first used, rather than upfront in the constructor

2. New AgentConfig type: Allow explicitly disabling features via configuration, with helpful error messages if disabled features are accessed

export type AgentConfig = {
disableStatePersistence?: boolean;
disableScheduling?: boolean;
disableQueue?: boolean;
disableMcp?: boolean;
disableWorkflows?: boolean;
};

Example usage:

class MinimalAgent extends Agent<Env> {
  // Only uses state - disable everything else
  config = {
    disableScheduling: true,
    disableQueue: true,
    disableMcp: true,
    disableWorkflows: true
  };
}

Benefits

• Reduced costs: Users only pay for storage they actually use
• Faster initialization: Fewer SQL operations on agent startup

Implementation

I have a working implementation ready if this approach sounds reasonable. All existing tests pass, with one test helper updated to accommodate the lazy creation pattern.

[threepointone]

this seems like a microoptimisation. the entire value prop of agents is their statefulness. if you need something lighter, the plain partyserver class would be a better fit.

[stephencoffey]

Thanks for the quick response. Totally understand the design intent.

Just wanted to flag one thing before closing - the persistence angle might be worth considering separately from the optimization side. Creating tables in the constructor means every DO instance persists in storage indefinitely, even for agents used for short-lived WebSocket sessions. Without those tables, empty DOs would get garbage collected naturally. So for some use cases it can lead to unbounded storage growth unless destroy() is called explicitly.

Also worth noting that Agent has some nice features beyond persistence (RPC, @callable, observability) that make it appealing over plain PartyServer even for lighter use cases.

Anyway, happy to close this - just thought it was worth mentioning.

[threepointone]

Good shout, we should move stuff like callable into PartyServer

Heard about unbounded growth, thinking through that.

[threepointone]

Maybe we should split agents functionality into class mixins so you can pick and choose what you want (within reason)

[threepointone]

I'm going to reopen this and edit your title and leave a comment in your description