Agent-Oriented Cloud Drive: From a File Cabinet to a Context Foundation

1. Background: Agents Need a Computable Data Plane, Not a Folder

A traditional cloud drive is built for people: upload, sync, preview, share, trash, and version restore. Its entry point is a graphical interface, and its value is keeping files in one place so they can be opened later. When an agent becomes the primary caller, the requirements change. An agent does not care whether thumbnails look polished. It cares whether it can quickly find relevant passages within its permissions, understand file structure, cite sources, read and write safely, and trace and reproduce a task after a failure.

An agent-oriented drive therefore cannot be a conventional drive with a conversation entry bolted on. It should be redefined as three layers: persistent file storage and metadata at the bottom; machine-oriented parsing, indexing, and retrieval in the middle; and context construction, tool invocation, delegated authorization, and audit governance for agents at the top. For developers, it is closer to a data plane plus a context service than to a page-centric application.

This kind of infrastructure can be assembled from general cloud capabilities: object storage for original files, vector and keyword search for a hybrid index, a message queue to drive asynchronous parsing, logging and monitoring for observability, and a container platform for isolated runtimes. Object storage, vector search, message queues, logging and monitoring, and container platforms from Baidu AI Cloud are examples of general building blocks for such a foundation. The concrete design should still follow how agents access data.

2. Six Capability Layers

2.1 Storage: A Unified File Abstraction and Traceable Metadata

When an agent uses files, the worst case is knowing a file exists but not knowing what it is, where it came from, or whether it is current. Each file needs a stable identifier, a version chain, a content hash, provenance, a lifecycle state, and an access-control list. Metadata should not be display-only fields. It should drive retrieval, authorization decisions, and audit.

At a minimum, record: file ID, space ID, parent directory or logical collection, MIME type, size, creator, created time, updated time, version, content hash, parse status, index status, tags, sensitivity level, and retention policy. For files written by an agent, also record which agent session created them, which task they belong to, and which authorization scope was used. That is what makes later tracing, rollback, and audit possible.

2.2 Indexing: Multimodal Parsing and Hybrid Retrieval

An agent can “go find the material” only if the material is machine-readable. The drive should extract content asynchronously: split plain text; extract paragraphs and tables from structured documents; run OCR on images; transcribe audio and video; and, for archives, either expand them by policy or index only the manifest. Parse results should keep locators such as page, paragraph, and table cell so citations can point back to a source.

Retrieval should combine keywords, vectors, and metadata filters. Keywords support exact match, vectors improve semantic recall, and metadata filters enforce constraints such as permission, time, type, and tags. The index must support incremental updates. Create, modify, delete, and permission-change events should update the index so an agent does not retrieve stale or unauthorized content.

An illustrative index policy:

index_policy:
  scope: workspace
  extractors: [text, pdf, office, image_ocr, audio_transcript]
  chunking:
    max_tokens: 512
    overlap: 64
  retrieval:
    mode: hybrid
    filters: [acl, mime_type, updated_at, sensitivity]
  acl: inherit_from_parent

2.3 Authorization: Agent Identity, Delegation, and Least Privilege

Agent access should not simply reuse a user’s username and password. A sounder model is delegation: the user grants a specific scope, time window, and set of operations to an agent session. The agent then accesses the drive under its own identity, carrying a scoped token. Permissions should be fine-grained across space, directory, file, operation type, and sensitivity level, with distinct grants such as read, write, create, delete, and share.

High-risk operations should require approval or a second confirmation—for example bulk delete, external sharing, or access to highly sensitive files. The runtime should be isolated as far as practical. The agent obtains short-lived credentials inside a sandbox, and those credentials expire when the task ends. Every read, write, search, download, and share should be written to an audit log with subject, object, action, time, result, and task context.

2.4 Interfaces: Declarative Access for Agents

Traditional drive APIs lean toward “list a directory, download a file, upload a file.” Agent-facing interfaces should be more declarative: given a query, a permission scope, a time range, and a context budget, return relevant passages, citation locations, and summaries; given a task, return an actionable change set; given a file change, offer event subscriptions. The API should support idempotent writes, ranged reads, streaming reads, batch operations, and retry on failure.

Context construction can be sketched as follows:

def build_context(agent_session, query, token_budget):
    candidates = search_files(
        query=query,
        scope=agent_session.scope,
        acl=agent_session.agent_id,
        filters={"sensitivity": "allowed"}
    )
    chunks = retrieve_chunks(candidates, query, top_k=20)
    ranked = rerank(chunks, query, agent_session.task_profile)
    return pack_context(
        ranked,
        token_budget=token_budget,
        require_citation=True,
        deduplicate=True
    )

The point of this flow is not a particular API name. It is three principles: filter by permission before ranking; always return citations with the content; and keep context inside a budget instead of dumping an entire file into the conversation.

2.5 Runtime: Events, Sandboxed Execution, and Task Orchestration

Agents often work in several steps: search, read, generate a new file, then archive it. The drive should emit events such as upload complete, parse complete, index complete, permission changed, and version updated, and use those events to drive follow-on work. Tasks should run in an isolated environment. File access should go through a controlled mount or temporary credentials so the agent never holds long-lived secrets.

Task-level idempotency and compensation matter as well. Re-running the same task should not create duplicate files. After a failure, audit records should support rollback or retry. Long tasks should be split into stages with intermediate state recorded. That is how a drive moves from passive storage to an orchestratable node in a data workflow.

2.6 Governance: Observability, Cost, and Compliance

An agent-oriented drive must be observable. Retrieval latency, index backlog, parse failure rate, permission denials, context hit rate, write conflicts, storage growth, and call cost should all be monitored. Logs should distinguish user actions from agent actions and support tracing by task, session, and file. Retention, delete propagation, sensitive-data redaction, and cross-space isolation should be designed in from the start, not patched on later.

3. Design Principles and a Path to Production

First, prefer machine-readable content. After upload, files should enter the parse-and-index pipeline quickly, and parse status should be visible to the agent. Second, authorize before you retrieve. Every search, summary, and context build must trim results by permission first. Recalling first and filtering later can leak information. Third, make citations traceable. Agent output should be able to point back to a file, version, page, or paragraph. Fourth, separate reads from writes and keep versions. Content generated by an agent should be written as a new version or a new file, preserving the change chain. Fifth, keep cost under control. Context construction should deduplicate, rerank, and trim to a budget. Indexing should support hot and cold tiers and parse on demand.

A practical rollout is staged: start with unified metadata, an authorization model, and basic retrieval; then add multimodal parsing, hybrid retrieval, and citation tracing; then add events, sandboxed execution, and task orchestration; and finally complete audit, quotas, cost control, and compliance. Evaluation should cover retrieval relevance, authorization correctness, citation completeness, task success rate, average context cost, and audit coverage.

4. Conclusion

An agent-oriented cloud drive may still look like a file space on the surface. Underneath, it has to move from “a person looks for a file” to “an agent builds context and executes a task inside an authorization boundary.” That requires stable storage and metadata, a machine-readable index, fine-grained delegated authorization, declarative interfaces, an event-driven runtime, and full governance. Only when those capabilities form one data and context foundation can the drive become reliable infrastructure for agents, rather than another chat attachment that still depends on someone dragging files by hand.