S3 is not a filesystem

S3 is incredible infrastructure. It is cheap, durable, and scales to exabytes. But it is not a filesystem, and pretending it is one causes real pain for AI agents.

What agents want to do

ls /drive/
cat /drive/report.txt
grep -r "error" /data/logs/
echo "result" > /drive/output.txt
cp /drive/report.txt /shared/

What S3 makes you do

# List files
aws s3api list-objects-v2 --bucket my-bucket --prefix data/

# Read a file
aws s3 cp s3://my-bucket/data/report.txt -

# Search? No grep. Download everything first.
aws s3 sync s3://my-bucket/data/ /tmp/data/
grep -r "error" /tmp/data/logs/

# Write a file
aws s3 cp - s3://my-bucket/data/output.txt

# Share? Generate a presigned URL
aws s3 presign s3://my-bucket/data/report.txt --expires-in 3600

Every operation requires the AWS SDK, credentials, bucket names, and prefix management. Your agent spends more time on S3 plumbing than on actual work.

The real problems

• No directory listing. S3 has "prefixes", not directories. ls does not work.
• No append. You cannot append to an S3 object. You must re-upload the entire file.
• No search. You cannot grep across S3 objects without downloading them all.
• No pipes. cat file | grep error | wc -l — impossible directly on S3.
• No permissions per agent. IAM policies are bucket-level or prefix-level, not per-agent.
• Credentials management. Every agent needs AWS credentials. Rotating them is painful.

What if S3 was a filesystem?

That is what pidrive does. Your agent mounts /drive/ and gets a real POSIX filesystem. Under the hood, data goes to S3. But your agent never knows or cares.

# Same files, stored in S3, accessed as a filesystem
ls /drive/
cat /drive/report.txt
grep -r "error" /drive/logs/
echo "result" > /drive/gt; /drive/output.txt

No SDK. No credentials in your agent code. No presigned URLs. Just files.

curl -sSL https://pidrive.ressl.ai/install.sh | bash
pidrive register --email you@company.com --name "My Agent" --server https://pidrive.ressl.ai
pidrive mount
ls /drive/