Support custom backend mounts for the default Deep Agent flows

[anselm94]

Is your feature request related to a problem? Please describe.

@cap-js/agents currently does not expose a first-class way to configure the 'backends' when using the default LangChain agent builders:

1. custom filesystem backends
2. overriding existing mounts

The createDeepAgent creates a hard-coded CompositeBackend(new StateBackend(), ...) and only mounts built-in routes like /uploads/, /outputs/, and /skills/

As a result, upstream LangChain/deepagents patterns such as mounting custom backends under /memories/, /docs/, /workspace/, or overriding an existing route are not available unless the application fully overrides buildGraph and constructs the agent manually.

This feels inconsistent with the plugin's otherwise fine-grained event-based extension model (buildTools, buildModel, buildSystemPrompt, buildMiddleware, buildGraph).

Describe the solution you'd like

Expose backend configuration as a first-class extension point in @cap-js/agents, so applications can add or override filesystem backend mounts without replacing the full graph construction.

Proposed extension: buildBackend event

This should apply consistently to both:

• Deep Agents via createDeepAgent({ backend })
• ReAct agents via createFilesystemMiddleware({ backend })

This should allow use cases like:

• mounting long-term memory under /memories/ using StoreBackend (see LangChain memory docs)
• mounting documentation under /docs/ using Wiki-backed custom backend
• mounting project/workspace content under custom paths
• overriding or extending built-in routes like /uploads/ or /outputs/

Describe alternatives you've considered

1. Override buildGraph completely and construct the LangChain/deepagents graph manually
   This works by copying the current createAutoDeepAgent implementation, but it is much heavier than overriding a single concern and bypasses the plugin's ergonomic default wiring.

2. For ReAct agents, push backend concerns into buildMiddleware (for. eg. createFilesystemMiddleware({ backend })) but Deep Agents need a backend directly via createDeepAgent({ backend }), so a dedicated backend extension point seems cleaner.

Additional context

Repository observations:

• lib/agents/markdown/deep-agent.js creates a CompositeBackend(new StateBackend(), additionalBackends) with only the built-in routes:
  • /uploads/
  • /outputs/
  • ./skills/
  • /skills/

Have you already checked existing issues before creating a feature request?

Yes, no existing issues were found.

Customer Info

None. CAP fan who sees a big potential with this plugin :)

[github-actions]

👋 Hello @anselm94, thank you for submitting this issue. Our team is reviewing your report and will follow up with you as soon as possible.

[Akatuoro]

Hi @anselm94 , what is your specific use case for a custom backend? Based on the folder names /memories/, /docs/, /workspace/ it seems like long-term memory.
For coding assistants you typically have a file based backend. For a SaaS app, you have a persistence (s3, hana, ...) depending on what you store (session history, files, ...) and for advanced use cases you may have a full computer like sandbox (cloud coding assistants, ...).
What we've found is that the backend configuration is typically also involved with other parts of the agent... So if you touch it, you typically also modify other parts in which case it makes sense to override the full agent.

[anselm94]

Hi @Akatuoro, One usecase I'm foreseeing is the use of Wiki/ECM/enterprise file-storage system such as SharePoint, Google Drive etc. as a governed "knowledge base" for "Knowledge AI Agents". Since these CMS already provide access-control, retention, versioning etc. out of the box, human <-> AI collaboration 'may be' made simpler, effective and governed.

Moreover, LangChain treating bringing custom backends via a 'Backend Protocol', I see it as a primitive along with tools, middlewares etc. And having buildBackend event yielding BackendProtocolV2 (for filesystem backends) or SandboxBackendProtocolV2 (for advanced backends with shell access like Nvidia OpenShell, etc.) will be beneficial and make it extensible for multiple use cases.