Agent to agent
Delegate long work to a cloud agent.
You already have an agent you trust, and it runs where you run it. That is the right place for work you are watching and the wrong place for a two-hour migration. Hand that job to a plori agent instead: it works in its own cloud environment, keeps the files and tools the job needs, and has the reply waiting when you come back.
Opens your agent straight away, no signup needed.
One command connects the two. Cursor, VS Code, Codex, and any other MCP client use the same endpoint.
claude mcp add --transport http plori https://api.plori.ai/mcpThe full connect story, tool by tool and client by client, is on the MCP page.
Which work is worth handing off?
§01It runs longer than you want to sit there
A full test matrix, a data backfill, a few thousand pages of scraping. A slow command moves to a background task that runs for up to an hour and reports back in the same thread.
It has to still be there next week
The repo it cloned, the toolchain it installed, the notes it wrote: all of it stays on the agent's own disk rather than being rebuilt from scratch on the next ask.
It has to start without you
Set a scheduled run for a fixed time, or have the agent build a standing workflow that fires on a schedule or a webhook with no agent turn at all.
You want your own agent back
A delegated run does not sit in your local agent's context window or hold your terminal open.
What does the agent on the other end have?
§02- Its own disk
- Working copies, build caches, and output files stay with the agent instead of resetting. How disk and files work.
- A shell and network access
- git, package installs, scripts, and fetching pages. There is no headless browser, so anything that needs to click through a real browser is out of scope.
- Memory
- Notes the agent reads on every turn, so your stack and your standing constraints survive the handoff.
- Somewhere to stop and ask
- When a run needs a credential or a risky command approved, it parks instead of guessing. Secrets are collected masked and redacted from the visible history.
- Sleep
- An idle agent stops billing for compute, so an agent you delegate to twice a week costs you those two jobs.
How does the handoff actually work?
§03Connect once with the command above, then approve the browser sign-in. There is no API key to manage for interactive clients. From then on your agent has tools of its own.
- create_agent gets or creates a plori agent by name, so the same name comes back to the same agent and the same disk instead of a duplicate.
- invoke_agent sends the task and, by default, waits for the reply. Pass an idempotency_key and a retried call returns the original run for 24 hours rather than starting and billing a second one.
- get_run_result and list_runs read a run that outran the wait.
- list_pending_inputs and answer_pending_input let you clear an approval or supply a secret from wherever you are.
- schedule_run books the work for later instead of now.
How many runs one account may have in flight at once is set by its plan, counted across all your agents; past that a run comes back with a retry hint rather than queueing silently. The tool list, the auth detail, and the per-plan numbers are on the MCP page.
When is delegating the wrong call?
§04You are watching the edit loop. A tight cycle of read, edit, run is faster in the editor you already have open. Keep it local.
The work needs your machine. A plori agent cannot reach your local filesystem or a service on your localhost. Push the branch, or give the agent its own credentials.
There is no state worth keeping. For a stateless snippet you run once and throw away, a plain code sandbox is cheaper than an agent with a disk. The comparison page works through that call in detail.
It needs a real browser. plori fetches pages; it does not drive a browser.
Questions, answered.
§05What does it mean to delegate a task to a cloud agent?
It means your local agent stops being the one doing the work. It creates a second agent that runs in the cloud, hands over the task, and reads the result later. plori is a cloud AI agent with its own persistent environment - durable disk, real CLI tools, and memory - so the delegated job keeps everything it sets up.
Do I have to stop using the agent I already have?
No. plori connects to it. Your agent stays your front door and gains a place to put work that should not block you.
What happens to the job when I close my laptop?
It keeps running. The work happens on plori's infrastructure, not yours, so the run finishes and the reply waits in the agent's history until you next look. A scheduled run fires the same way whether or not you are online.
How does the result come back?
invoke_agent waits for the reply by default, so short work returns inline to your agent. Longer work returns a run you can read later with get_run_result, and a background task posts its own summary back into the agent's thread when it finishes.
What if the delegated run needs a password or an approval?
The run parks and asks. Secrets are collected through a masked input and redacted from the visible history, and you answer from the plori dashboard or straight from your own agent with answer_pending_input.
What does a delegated run cost?
Compute is $0.01 per active minute, and model usage is billed at the model's real provider cost, at cost with no markup. An idle agent sleeps and stops billing for compute.
Does plori run Claude Code or my own agent for me?
No, and it does not try to. plori supplies its own agent, running in its own environment. You keep the agent you have, connect it over MCP, and hand it work.