langchain-ai/deepagents
1
0
Fork 0
mirror of https://github.com/langchain-ai/deepagents.git synced 2026-07-23 02:05:44 -04:00
Code Issues 169 Packages Projects Releases 16 Wiki Activity

A Better Approach for Handling Files on Disk? #89

New Issue
Closed
opened 2026-02-16 08:19:49 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 08:19:49 -05:00
Owner
Copy Link
Copy Source

Originally created by @mjrs33 on GitHub (Oct 27, 2025).

Hi deepagents team, thanks for the awesome work!

I'd like to ask about a good way to handle files on disk.
Many scientific computing software applications generate massive output files stored on disk. When creating a langchain tool to execute these software, the tool's output should ideally return only the path to the artifact along with a summary of the results. However, this presents a problem in deepagents' system. The ls tool cannot recognize these artifacts, creating communication issues between agents. While using a middleware that registers artifacts with a /memories/ prefix allows ls to detect them, this now prevents tools that accept actual disk file paths from correctly selecting the appropriate path.

For example;

├── run_0001
│   ├── input
│   └── large_output
└── run_0002
    └── make_input_from_prev_run.py

We can register /memories/run_0001/large_output to deepagents filesystem using a custom middleware. However, agents will use /memories/run_0001/large_output as an input of make_input_from_prev_run.py although the correct path is run_0001/large_output.
Additionally, when artifacts are extremely large, loading them into memory becomes inefficient, so it's preferable to be able to register dummy objects instead.

What would be a good solution to these challenges?

Originally created by @mjrs33 on GitHub (Oct 27, 2025). Hi deepagents team, thanks for the awesome work! I'd like to ask about a good way to handle files on disk. Many scientific computing software applications generate massive output files stored on disk. When creating a langchain tool to execute these software, the tool's output should ideally return only the path to the artifact along with a summary of the results. However, this presents a problem in deepagents' system. The `ls` tool cannot recognize these artifacts, creating communication issues between agents. While using a middleware that registers artifacts with a `/memories/` prefix allows `ls` to detect them, this now prevents tools that accept actual disk file paths from correctly selecting the appropriate path. For example; ``` ├── run_0001 │   ├── input │   └── large_output └── run_0002 └── make_input_from_prev_run.py ``` We can register `/memories/run_0001/large_output` to deepagents filesystem using a custom middleware. However, agents will use `/memories/run_0001/large_output` as an input of `make_input_from_prev_run.py` although the correct path is `run_0001/large_output`. Additionally, when artifacts are extremely large, loading them into memory becomes inefficient, so it's preferable to be able to register dummy objects instead. What would be a good solution to these challenges?
yindo closed this issue 2026-02-16 08:19:49 -05:00
yindo commented 2026-02-16 08:19:49 -05:00
Author
Owner
Copy Link
Copy Source

@nhuang-lc commented on GitHub (Oct 28, 2025):

Hey @mjrs33, thanks for flagging! We just merged a change in >=0.2.0 that allows for pluggable filesystem backends. This means you can have a backend point at your local machine and read files from disk.

An overview of this and examples are in this doc. You can make this local filesystem the "default" pluggable backend and thus not have any routes prepended. Let me know if you have any questions.

It sounds like code execution is also important for your use case! We're thinking about a code sandbox as well - would love to hear what your requirements are for this specifically

@nhuang-lc commented on GitHub (Oct 28, 2025): Hey @mjrs33, thanks for flagging! We just merged a change in >=0.2.0 that allows for pluggable filesystem backends. This means you can have a backend point at your local machine and read files from disk. An overview of this and examples are [in this doc](https://docs.langchain.com/oss/python/deepagents/backends). You can make this local filesystem the "default" pluggable backend and thus not have any routes prepended. Let me know if you have any questions. It sounds like code execution is also important for your use case! We're thinking about a code sandbox as well - would love to hear what your requirements are for this specifically
yindo commented 2026-02-16 08:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@mjrs33 commented on GitHub (Oct 28, 2025):

@nhuang-lc
Thank you - this is exactly what I was looking for. I appreciate the great feature enhancement. However, I'm a bit confused and have a few questions:
FilesystemMiddleware, even after the changes, registers files in LangGraph's State when the tool output is large. But when using the FilesystemBackend, ls_info and read cannot retrieve information from "/large_tool_results/*" within the State. Is this the expected behavior?

I also appreciate your consideration of sandbox functionality. While this may differ slightly from a sandbox, I'm developing a custom middleware that submits jobs to Slurm. This middleware intercepts specified tools using wrap_tool_call and submits corresponding Python scripts to execute the tools in Slurm. Scientific computations can be extremely time-consuming, which is why I've created this middleware. I'd be delighted if there were an official implementation for this functionality.

@mjrs33 commented on GitHub (Oct 28, 2025): @nhuang-lc Thank you - this is exactly what I was looking for. I appreciate the great feature enhancement. However, I'm a bit confused and have a few questions: `FilesystemMiddleware`, even after the changes, registers files in LangGraph's `State` when the tool output is large. But when using the `FilesystemBackend`, `ls_info` and `read` cannot retrieve information from `"/large_tool_results/*"` within the `State`. Is this the expected behavior? I also appreciate your consideration of sandbox functionality. While this may differ slightly from a sandbox, I'm developing a custom middleware that submits jobs to Slurm. This middleware intercepts specified tools using `wrap_tool_call` and submits corresponding Python scripts to execute the tools in Slurm. Scientific computations can be extremely time-consuming, which is why I've created this middleware. I'd be delighted if there were an official implementation for this functionality.
yindo commented 2026-02-16 08:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@nhuang-lc commented on GitHub (Oct 28, 2025):

Ah great flag, thanks for raising this. I need to update this to use the default backend! (default backend used to be state)

Sounds good re: code execution, thanks for sharing, I'll tal at Slurm (haven't used it before)

@nhuang-lc commented on GitHub (Oct 28, 2025): Ah great flag, thanks for raising this. I need to update this to use the default backend! (default backend used to be state) Sounds good re: code execution, thanks for sharing, I'll tal at Slurm (haven't used it before)
yindo commented 2026-02-16 08:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@nhuang-lc commented on GitHub (Oct 30, 2025):

Thanks again for flagging this! This is addressed in patch 0.2.1. large tool results are offloaded to whichever backend is provided to the deep agent.

Closing this issue, lmk if you run into any problems

@nhuang-lc commented on GitHub (Oct 30, 2025): Thanks again for flagging this! This is addressed in patch 0.2.1. large tool results are offloaded to whichever backend is provided to the deep agent. Closing this issue, lmk if you run into any problems
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
MCP
backends
bug
cli
config
customization
deepagents
documentation
external
feature
fix
good first issue
help wanted
integration
internal
invalid
middleware
model
needs investigation
p0
p1
p2
p3
performance
pull-request
Mirrored from GitHub Pull Request
 question
sdk
subagents
unable to reproduce
windows
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/deepagents#89
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?