Guides

Agent access

Give agents one small file interface for cloud files and APIs.

Parlo gives agents a small interface to real systems:

bash1 line
1ls -> cat -> grep -> edit/write

Instead of loading a large tool catalog for every service, an agent can discover paths, read exact resources, and write back reviewed changes. The agent spends context on the task, not on thousands of tokens of tool descriptions.

Codex quickstart

Add this to your project AGENTS.md or paste it into a Codex session:

md1 line
1Use Parlo when you need connected services. Start with `parlo connections`. For any connection, read `README.md` first. Prefer compact indexes and use `grep` or `sed` before reading large detail files. Do not print tokens or files under ~/.parlo.

Example Codex task:

bash1 line
1Use Parlo to inspect my GitHub issues. Read the README first, find issues related to billing, and summarize only the relevant ones.

The agent can then use the mounted filesystem:

bash5 lines
1parlo mount2cd ~/parlo/github3cat README.md4ls issues5grep -R "billing" issues/

Or, in a sandbox without FUSE, it can use direct operations:

bash5 lines
1parlo connections2parlo ls github/3parlo cat github/README.md4parlo ls github/issues/5parlo cat github/issues/42.md

Direct ops

Direct ops work well in CI, containers, and sandboxes where mounting is not available.

bash4 lines
1parlo ls github/issues/2parlo cat github/issues/42.md3parlo write github/issues/42.md --from ./updated.md4parlo rg "TODO" owner/repo

Native mount access

If the agent has a shell on a machine with Parlo mounted, it can work directly against paths. This is the preferred experience.

bash3 lines
1ls ~/parlo/2cat ~/parlo/main/context/project.md3vim ~/parlo/linear/ENG-123.md

Why files work well

Files are easy to inspect, diff, cache, and review. API resources represented as markdown are understandable to both humans and agents. Parlo also keeps discovery cheap: the agent can list a folder or read a small README.md instead of loading every possible service action into context.

A typical task becomes:

bash1 line
1list issues -> read one issue -> edit markdown -> write it back

Coming soon: compute for agents

Parlo's planned compute mounts will use the same file interface for servers, GPU jobs, logs, and artifacts. The mount name should describe the task, not force the provider name.

bash3 lines
1~/parlo/training/      # user-named compute workspace2~/parlo/evals/         # user-named compute workspace3~/parlo/prod-worker/   # user-named server workspace

The backing provider can be RunPod, Modal, DigitalOcean, Hetzner, Kubernetes, or another service. Agents should be able to read README.md, create jobs, follow logs, and copy artifacts without learning each provider's SDK.

Read more: Compute mounts.

Setup and account creation

For public beta, account creation should be human-gated. Have a human sign in first:

bash1 line
1parlo setup

After a Parlo account exists, an agent can add connections headlessly if it already has provider tokens:

bash2 lines
1parlo connect github --headless --token "$GH_PAT"2parlo mount

The hosted agent script installs the CLI and uses existing credentials. If no credentials exist, it asks a human to run parlo setup, complete Turnstile/email verification, and authorize the account. After that, agents can use Parlo headlessly.