Skip to main content
Knowledge mapAFS

You are here. See how this question connects to other ideas.

Select a node to open its page · Expand to read within the map

Knowledge mapFollow a connection. Understand a question.
← Learning

LEARN / AFS

A world of resources you can operate on.

From Unix and Plan 9 to provider implementation, testing and remote access. Learn how agents discover resources, understand operations and verify results.

Start with AFS

Choose a starting point

  1. 01
    Start with AFS

    Understand what a task can name, access and operate.

    New to AFS · resources and addresses5 questions
  2. 02
    From finding a resource to operating it reliably

    Distinguish addresses, capabilities, updates and failures in a shared working environment.

    After AFS · resource behavior and reliability6 questions
  3. 03
    Trace the design roots

    From Unix and Plan 9 to a task-oriented resource environment.

    Design ideas4 questions
  4. 04
    Tour the providers

    Compare stored data, system capabilities and external services.

    Choosing implementations5 questions
  5. 05
    Build and check a provider

    From path contracts to reads, actions and conformance tests.

    For developers6 questions
  6. 06
    Connect agents to AFS

    Separate explanations, prompts, MCP tools and execution.

    Agent integration5 questions
  7. 07
    Take resources across boundaries

    Understand remote access, reverse mounting, scope and failure.

    Distributed resources5 questions

Explore the connections

Each explanation stands on its own. “Builds on” links show the background it uses.

01

Resources and operations

Shared AFS foundations

  1. What does AFS organize?

    AFS gives a task a named, inspectable view of the resources it can work with.

  2. What does a path give an agent?

    A path identifies a resource within a namespace, so operations can refer to it explicitly.

  3. How does a service enter AFS?

    A provider implements resource operations; a mount places that provider in a namespace.

  4. Why do operation semantics matter?

    Naming a resource is useful only when consumers can understand what operations on it mean.

  5. Does shared context mean everyone sees everything?

    A Small World presents the resources relevant to one observer, rather than exposing the whole system.

  6. Where does a mount put a resource?

    An entry path and the resource’s original location are different things.

  7. Does an address tell you what you can do?

    Location, supported operations and caller authority are separate questions.

  8. How does another display learn about a change?

    Reading the same address and receiving changes are separate steps.

  9. What happens when two people edit at once?

    A shared address does not decide how stale edits are handled.

  10. Why distinguish search from query?

    Finding relevant content differs from selecting records by explicit conditions.

  11. Should a failed operation be retried or handled differently?

    Missing, unsupported, denied and conflicting operations need different responses.

02

Across process boundaries

Remote access and reverse mounting

  1. How does a remote resource enter a namespace?

    A local path can represent a remote service without removing network and authority boundaries.

  2. What is reversed in a reverse mount?

    Connection or registration direction changes; authority does not automatically reverse.

03

Design roots

Unix, Plan 9 and context

  1. What does AFS borrow from Unix?

    Common names and operations let tools work across resource implementations.

  2. Why did Plan 9 make namespaces local?

    A participant can assemble a resource view that includes remote services.

04

Testable contracts

Paths, capabilities and conformance

  1. Should a provider return its mount prefix?

    Providers use their own relative paths; the dispatcher restores the mount prefix.

  2. What do conformance tests establish?

    Check declared shared contracts, not merely whether a demonstration runs.

  3. Why test rejection as well as success?

    Success-only examples miss over-broad access, swallowed errors and lost updates.

05

Different providers

Data, systems and external services

  1. How should you navigate the providers?

    Classify resources and responsibilities before repository directories.

  2. Why expose system capabilities as providers?

    Runtime state and capabilities can have structured entry points with their own lifetimes.

  3. How do FS, JSON, KV and DID Space differ?

    Common operations preserve differences in location, structure and persistence.

  4. What remains different behind a service provider?

    Permissions, latency and side effects remain part of the service contract.

06

Build a provider

Read handlers and business actions

  1. How do you start a read-only provider?

    Begin with one explicit resource and its path contract before adding operations.

  2. How do you expose a discoverable action?

    An action needs discoverable arguments, effects and failures as well as a handler.

  3. Check a read-only provider

    Mount a report at /work and check it with shared tests and an actual read.

07

Guidance for agents

Explanations, prompts, MCP and verification

  1. How does an agent learn what a path supports?

    Discover the resource, inspect its explanation, then use supported operations.

  2. Are AFS prompts and explain the same thing?

    Prompts orient the caller; explain supplies guidance for a particular path.

  3. How does an MCP client operate AFS?

    MCP supplies the connection contract; AFS supplies the resource environment and semantics.

  4. What are the two directions of MCP integration?

    Exposing AFS to MCP clients differs from mounting an MCP server into AFS.

  5. What makes an agent’s AFS task inspectable?

    Observe discovery, reads, operation choice and result verification separately.