Let one worker briefly own a task.
Inspect contract →Coordinate parallel agents without duplicate work
Give autonomous workers bounded shared-state primitives for exclusive ownership, deduplication, one-use handoffs, concurrency limits, barriers, and renewable refresh responsibility.
Outcome
Workers coordinate through opaque identifiers and TTL-bounded state without accounts, a shared database, or exposing task contents.
Use only the needed primitive
Mark opaque content as already processed.
Inspect contract →Bound how many workers run in parallel.
Inspect contract →Release a workflow phase after enough arrivals.
Inspect contract →Assign one renewable refresh owner.
Inspect contract →Share one retry-safe provider or model-token budget.
Inspect contract →Agent workflow
- Search the catalog with the concrete coordination problem.
- Describe the top candidate and inspect its TTL, side effects, and idempotency contract.
- Use only opaque, non-sensitive identifiers.
- Invoke with a stable idempotency key and replay that key only for the same normalized request.
Connect an agent
Connect the agent to the public Streamable HTTP MCP endpoint, search with the concrete job, and describe only the selected tool before invoking it.
https://liberated.site/mcp
Try this intent
Let at most three agents process this queue while preventing duplicate URLs.
60-second quickstart
Connect this source-tagged endpoint so the activation can be measured without accounts:
https://liberated.site/mcp?source=coordination-quickstart&profile=core
Copyable prompt
Use Agent Enhancer Utilities only for coordination. Never send task contents or sensitive values. 1. Search for the smallest tool that lets one worker own an opaque task for 60 seconds, then describe it. 2. Acquire that tool with namespace "quickstart-demo", key "task-001", owner "agent-a", TTL 60 seconds, and a fresh UUID v4 idempotency key. 3. Immediately repeat the identical call with the same idempotency key. 4. Report whether the first call acquired ownership and whether the second call replayed the same result. Do not perform unrelated work.
Expected result
- PennyLock is selected and described before execution.
- The first call reports acquired: true.
- The identical retry returns the same lock hash without executing again.
Replay recovery
If the response is lost, retry the identical normalized input with the same idempotency key. Never reuse that key with changed input.
Tried this in a real agent runtime? Share bounded, non-sensitive feedback.