
AIOZ Storage for AI workloads is exactly what its S3-compatible API suggests: plain object storage that slots into whatever training, agent, or data-pipeline tooling already expects an S3 bucket. That is a smaller claim than "AI storage" often implies, and it is worth being precise about, since the whole value of an S3-compatible endpoint for AI tooling depends on knowing exactly what it does and does not do. This article covers what AIOZ Storage's own documentation actually supports for AI and data workloads, three real patterns from the wider AI tooling ecosystem that a plain S3-compatible endpoint already fits into, and two real deployments already using it this way.
TL;DR:
Buckets, objects, an S3-compatible API, encryption, and scoped access grants, the same building blocks covered across this knowledge hub, not a separate AI product tier. AIOZ Storage's own documentation defines the service around S3 compatibility and AIOZ DePIN, its decentralized infrastructure layer, and does not name a single AI-specific storage feature anywhere in its concept pages. For a full-service walkthrough of the model itself, see AIOZ Storage Explained; for the credential and encryption side a training pipeline would actually configure, see AIOZ Storage Access Control and How AIOZ Storage Encryption Works.
That plainness is not a gap to apologize for. An S3-compatible endpoint with no proprietary API surface is precisely what lets it plug into tooling that was never written with AIOZ in mind.
No vector database. No embeddings storage, similarity search, or semantic search, documented or shipped. No managed training or inference layer, that is a different AIOZ product (AIOZ AI, covering hosted models like LightRAG and Qwen3-Coder-Next) with no documented integration into AIOZ Storage today. If a use case needs any of those specifically, AIOZ Storage is not the tool, at least not yet, and this article will not pretend otherwise. What it does offer, reliably, is the object storage layer underneath the AI workflows below.
Training data, generated imagery, model checkpoints, and experiment outputs are, at the storage layer, just objects: files that get written once and read many times, organized by key rather than by a database schema. That is the exact shape S3-compatible storage was built for, and it is why nearly every ML framework, from a plain boto3 script to a managed training platform, already speaks S3 as a first-class storage backend. Pointing that same tooling at s3.aiozstorage.network instead of AWS's endpoint is a configuration change, not a rewrite, the same endpoint-and-credentials swap covered in the JavaScript, Go, and Python SDK guides already on this hub. For the honest boundaries of that role, what's documented, what isn't, and how to work around the gaps, see Using AIOZ Storage as a Dataset and Model-Output Backend.
LangGraph, LangChain's agent orchestration framework, ships an official langgraph-checkpoint-aws package for persisting agent state. Its s3_offload_config option accepts a bucket_name and an optional endpoint_url, and its own documentation demonstrates that endpoint override with a LocalStack example, a non-AWS S3-compatible target. Checkpoints under 350KB stay in the primary store; anything larger gets offloaded to the configured S3 bucket automatically. AIOZ Storage's S3-compatible endpoint is a legitimate value for that same endpoint_url field. This is a real, documented pattern in LangGraph's own package, not an AIOZ-specific integration AIOZ has built or tested itself, an important distinction to hold onto if you are wiring this up. Offloading LangGraph Agent Checkpoints to AIOZ Storage covers the full setup, including a real credential-sharing limitation this summary doesn't have room for.
OpenAI's Agents SDK sandbox system uses a Manifest to mount external storage into an agent's workspace, with S3Mount, GCSMount, R2Mount, AzureBlobMount, and BoxMount all shipping as real, documented mount types. An agent working through internal documents, generated files, or a persistent workspace is, underneath, reading and writing objects through exactly this kind of mount. That is the industry pattern object storage already fills in agent sandboxes today. What is not documented at the manifest level is whether S3Mount itself accepts a custom, non-AWS endpoint URL generically, that's deferred to each of the SDK's 7 official sandbox providers. What AI Agent Sandboxes Actually Store checks two of them, Modal and E2B, directly, and confirms both support it.
This is not purely theoretical. AIOZ Storage's SpaceAgri case study documents a live deployment storing IoT sensor readings, crop imagery, and breeding-experiment metadata, explicitly for AI-powered crop growth analysis and model training and monitoring, a real dataset-and-model-output workload running on AIOZ Storage today, not a hypothetical one. AIOZ has also published broader positioning on AIOZ Storage as infrastructure for Web3 AI and data, worth reading for the wider framing this article deliberately narrows down to what is concretely documented.
Does AIOZ Storage have a vector database or similarity search feature?
No. AIOZ Storage's documentation defines it as S3-compatible object storage with no vector-database, embeddings, or similarity-search capability, documented or shipped.
Can I use AIOZ Storage to store AI training datasets?
Yes, in the same way any S3-compatible object store handles datasets: as objects organized by bucket and key. AIOZ Storage's SDKs and CLI, already covered elsewhere on this hub, work the same way regardless of what kind of file is being stored.
Can LangGraph checkpoint agent state to AIOZ Storage?
LangGraph's own langgraph-checkpoint-aws package supports a custom endpoint_url in its s3_offload_config, demonstrated in its documentation with a LocalStack example. AIOZ Storage's S3-compatible endpoint is a legitimate value for that field, though this is LangGraph's own documented flexibility, not an AIOZ-built integration.
Does OpenAI's Agents SDK support mounting AIOZ Storage into a sandbox?
Its Manifest system supports an S3Mount type generically, with the actual mounting mechanics deferred to each of the SDK's 7 official sandbox providers. Two of them, Modal and E2B, are independently confirmed to support custom S3-compatible endpoints, covered in full in What AI Agent Sandboxes Actually Store.
Is AIOZ Storage connected to AIOZ AI's hosted models?
No documented connection exists today. AIOZ AI (hosted models like LightRAG and Qwen3-Coder-Next) and AIOZ Storage are separate products on the AIOZ DePIN network.
Is there a real example of AIOZ Storage being used for AI workloads?
Yes. AIOZ's published SpaceAgri case study documents a live deployment storing sensor data and crop imagery specifically for AI-powered crop analysis and model training.
Why doesn't AIOZ Storage have AI-specific features if it's built on a DePIN network built for AI-adjacent compute?
AIOZ Storage and AIOZ's compute/AI infrastructure are separate products on the same broader DePIN network, not one integrated stack. AIOZ Storage's job is the object storage layer; anything beyond that, today, is outside its documented scope.

AI agent sandboxes need external storage for files that outlive the sandbox. Real providers like Modal and E2B mount S3-compatible buckets, AIOZ Storage included.

AIOZ storage can back LangGraph's S3 checkpoint offload tier, but not the whole backend. Here is the real DynamoDB-plus-S3 setup and its credential gap.

AIOZ storage for AI datasets means S3-compatible buckets for training data and model outputs, no native versioning or lifecycle policies. Here is the honest scope.

AIOZ storage for AI workloads means S3-compatible object storage for datasets, checkpoints, and model outputs. No vector database. Here is what is real.

Add AIOZ storage team members through the dashboard's 3-step wizard: name and password, per-bucket permissions, and a one-time credential download.

No Postman collection to import. AIOZ Storage docs show building raw S3 requests by hand, authenticated with AWS Signature and your access grant keys.