I’m not sure if there is a way for thread / agents to communicate. But I’m trying to get a structured approach to a team of agents working towards the same goal given a plan. So I started prompting it into existence.
So far I have teams support where a team can be a team leader + X amount of dev agents. They all work in their own work tree / branches. The team leader delegates work and merges work together in a team leader worktree, runs test, fixes things as they come up. Each dev has various mechanisms to report blockers to the team leader, and if it’s a human user facing blocker that requires human input it will provide that feedback.
I have a dashboard to watch whats happening at a high level, but I haven’t figured out a way to snoop on the thread chat conversations.
Still have a few issues where I have to remind the dev agents to commit their work when complete. But figuring it out.
Anyone have any official support for inter-agent communications?
Above is my dashboard screen shot that my service manages. The paste support team i have actively working is 19 tasks deep without intervention. Time will tell if they actually finish what I wanted, they might be taking over the world. Who knows.
I didn’t know that existed. Thank you. I will wait for that to land, and figure out how to get into experimental to align my current service with sub agents usage.
Decentralized Agent Coordination Contract
This directory enables decentralized coordination for multiple agents modifying the codebase.
The system is intentionally simple:
One file lock at a time.
One owner at a time.
No central authority.
Intent and messaging are advisory only.
Locks are authoritative.
1. Locking Mechanism (Single-File Lease)
Agents must use a Write → Wait → Verify pattern.
Invariants
A lock file contains only the owning agent_id.
Only the lock file determines ownership.
Agents may hold only one lock at a time.
Before modifying any file, ownership must be re-verified.
Lock Acquisition
For target file:
$FILE_PATH
Lock path:
agents/locks/$FILE_PATH
Steps
Ensure directory exists:
mkdir -p agents/locks/$(dirname “$FILE_PATH”)
Attempt claim:
echo “$MYID” > agents/locks/$FILE_PATH
Wait for filesystem settle:
sleep 1
Verify ownership:
read OWNER < agents/locks/$FILE_PATH
If OWNER == $MYID → Lock acquired.
Else → Lost race → Sleep with jitter and retry:
sleep $((RANDOM % 5 + 5))
Before Writing
Immediately before modifying the target file:
read OWNER < agents/locks/$FILE_PATH
if OWNER != $MYID → abort and re-evaluate
After Writing (Before Release)
Re-verify ownership again.
If ownership changed:
Abort
Do not release
Log anomaly
Lock Release
After successful modification and verification:
rm agents/locks/$FILE_PATH
Never release if not owner.
#2. Stale Lock Handling (Lease Expiry)
If a lock file exists and:
find agents/locks/$FILE_PATH -mmin +10
Then the lock may be considered stale.
Stale recovery:
Overwrite lock with your own ID.
Perform normal Write → Wait → Verify.
Log takeover in history.
Timeout must always exceed expected maximum write duration.
3. Intent Tracking (Why)
Before or during an active lock, agents should declare intent.
Path:
agents/intent/$MYID.$(date +%s.%N).why
Content should include:
Files involved
Brief description of change
Timestamp
Intent is informational only.
Intent does not grant authority.
4. Messaging (BBS)
For coordination and awareness only.
Path:
agents/msgs/$MYID.$(date +%s.%N).msg
Rules:
Messages cannot grant lock ownership.
Messages cannot override locks.
Locks are authoritative.
5. Task History
Completed tasks are logged here:
agents/history/$MYID.$(date +%s.%N).commit
History is append-only.
Never mutate past history.
6. Plan Re-Evaluation Rule
If an agent repeatedly loses lock acquisition:
It must re-evaluate its plan.
It may inspect:
intent/
msgs/
history/
Agents must not busy-wait indefinitely.
Directory Structure:
locks/ → active file leases
intent/ → active work declarations
msgs/ → general inter-agent communication
history/ → completed task records
bbs/ → legacy message area
End of Contract
that’s how I did it
