[FEATURE] Add binary blob support to FileContent for code_interpreter tool #304

Problem Statement

Currently, the FileContent model in strands_tools.code_interpreter.models only provides path and text parameters for file operations with the code interpreter tool. Currently, while we can write binary files through the Strands code_interpreter tool, I have to base64 encode the binary data and insert it into the text field of the FileContent model.
This workaround requires the language model (LLM) to first read the content using f.read(), then decode the base64 string back into the original binary format before use. This makes file handling less intuitive, adds extra overhead to agent logic, and increases the risk of confusion or errors, compared to the direct binary blob support available in underlying Bedrock AgentCore.

Proposed Solution

Extend the FileContent model in strands_tools.code_interpreter.models to include an optional blob parameter, similar to the Bedrock AgentCore API, allowing users to directly upload binary files.

Example: How uploading with blob support could look (following Bedrock AgentCore API):

from bedrock_agentcore.tools.code_interpreter_client import CodeInterpreter

code_client = CodeInterpreter(region)
code_client.start()

with open("image.png", "rb") as f:
    file_bytes = f.read()

write_args = {
    "content": [{
        "path": "image.png",
        "blob": file_bytes  # Raw binary bytes, no encoding
    }]
}

code_client.invoke("writeFiles", write_args)

If Strands adds a blob field to its FileContent model, users will be able to upload binary files in a direct and intuitive way, matching the capabilities of the Bedrock AgentCore layer. This would avoid the current need for base64 encoding and decoding workarounds

Use Case

This would help with any workflows where agents need to handle binary files, such as Excel spreadsheets, images, PDFs, or ZIP archives. Direct blob support would allow users to upload these files natively, without manual base64 encoding and decoding workarounds. It enables agents to process, analyze, or generate outputs from binary documents using the code interpreter, making multi-modal and document-centric agent applications much easier and more reliable.

Alternatives Solutions

No response

Additional Context

These are the summaries of the attempts of the LLM to read my file
Why previous attempts to handle Excel files failed:

Attempt 1: Tried to read the uploaded file as a normal Excel file with pandas.
Error: ValueError: Excel file format cannot be determined, you must specify an engine manually.
Reason: pandas couldn't detect the format because the file was base64 text, not binary.

Attempt 2: Specified the openpyxl engine for reading Excel.
Error: BadZipFile: File is not a zip file
Reason: .xlsx files are ZIP archives, but the upload was base64-encoded text.

Attempt 3: Tried reading with the xlrd engine.
Error: Expected BOF record; found b'UEsDBBQA'
File type check: ASCII text, very long lines, no line terminator
Reason: UEsDBBQA is the base64-encoded ZIP header (not a real binary header).

What fixed it:

Attempt 4: Opened the file as text, found the UEsDBBQA base64 header indicating encoded ZIP/binary.

Attempt 5: Decoded the content with base64.b64decode, wrote it out as a binary file, then read it with pandas/openpyxl successfully.

Summary:
The problem was that binary files were uploaded as base64 text, but downstream tasks (like reading Excel files) expected native binary files. The solution was to detect base64-encoded content, decode it, save it as binary, and then process it. This illustrates a file handling mismatch—uploading base64 text where code expects binary—highlighting the need for direct blob/binary file support.