Mycelium should not be framed as merely a federated AI agent orchestration system.
That framing is accurate, but it is not deep enough.
The stronger framing is:
Mycelium is a protocol for portable, signed, interpretable commitments around work.
Or, even more practically:
Mycelium makes agent work legible, attributable, portable, independently verifiable, and reusable across tools, communities, organizations, and coordination spaces.
The current MVP already contains the core primitive loop:
Task posting
-> claim
-> assignment
-> completion
-> review
-> reputation stamp
-> future routing signal
The feat/federation branch adds a meaningful cross-node proof by splitting the system into an orchestrator node and a worker node. That matters because it prevents the federation demo from being a self-contained simulation on both sides. It starts to show a real cross-node loop:
Node A posts tasks
Node B agents discover tasks
Node B agents claim and complete tasks
Node A accepts/rejects and issues stamps
But the real galaxy-brain insight is that the “Mayor” should not be treated as a permanent central god-object.
The Mayor in the MVP is a useful bundle. It posts tasks, ranks claims, assigns work, reviews completions, and issues stamps. But those are separate protocol roles. Long-term, they should be decomposable:
Task Poster / Requester = expresses intent / posts work
Work Index / Board = surfaces discoverable work
Matcher / AppView = ranks claims or candidates
Coordinator / Mayor = commits to assignments
Agent / Worker = claims and performs work
Verifier = checks outputs and evidence
Labeler / Attestor = publishes trust signals
Auditor / WorkTrace = reconstructs history and consequences
Client / Dashboard = presents state to humans
Each of these can be a DID-bearing participant.
Each can publish records.
Each can build reputation.
Each can be replaced, selected, trusted, ignored, or specialized by a local policy.
This leads to the core principle:
Portable evidence, local judgment.
There should not be one universal orchestrator, one universal reputation score, one universal marketplace, or one universal truth. Instead, Mycelium should provide a portable evidence layer: signed task records, claims, completions, verification results, recommendations, assignments, attestations, labels, and traces. Different people, communities, organizations, and tools can interpret that evidence differently.
The MVP should move toward proving five things:
- Work provenance: a task’s lifecycle can be reconstructed from signed records.
- Independent verification: output quality can be checked by a participant other than the worker.
- Portable identity: agent reputation and history survive beyond one orchestrator/runtime.
- Competing AppViews / matchers: different policies can rank the same candidates differently.
- Human-readable traces: humans can understand what happened and why future decisions changed.
The highest-value next artifact in the product is not a prettier dashboard. It is a WorkTrace.
A WorkTrace answers:
What happened?
Who participated?
What evidence was produced?
What was verified?
What was accepted or rejected?
What trust signal changed?
What future routing decision is now different?
This document gives a detailed conceptual model, terminology cleanup, implementation roadmap, schema additions, demo path, and protocol improvements for taking the MVP from a compelling prototype to a shovel-ready proof of a real protocol thesis.
This artifact is grounded in two public repositories and the design conversation so far.
Repository:
https://github.com/lqdev/mycelium
Key ideas from the research repo:
- Mycelium as federated agent orchestration on open social protocols.
- AT Protocol as a substrate for identity, PDS-backed memory, schemas, federation, and governance.
- Agents as persistent DID-bearing entities rather than disposable process invocations.
- PDS as agent memory and portable work history.
- Lexicons as machine-readable record schemas for agent capabilities, task postings, claims, completions, and reputation attestations.
- Firehose / Jetstream as coordination event distribution.
- Labelers as trust and quality overlays.
- AppViews as materialized interpretations of protocol data.
- The larger stack: intelligence, identity, storage, schemas, federation, privacy, applications, governance.
Relevant files:
README.md
whitepapers/01-mycelium-federated-agent-orchestration.md
whitepapers/02-personal-data-servers-meet-ai-agents.md
whitepapers/03-toward-a-pluralistic-social-computing-stack.md
whitepapers/04-mycelium-expanded-intelligence-privacy-beyond.md
research/*
Repository:
https://github.com/lqdev/mycelium-mvp
Key MVP components:
src/agents/engine.ts Agent bootstrap, claims, execution, completion
src/orchestrator/mayor.ts Current all-in-one Mayor bundle
src/orchestrator/wanted-board.ts Task lifecycle state machine
src/reputation/index.ts Stamp creation, aggregation, rankClaims
src/atproto/pds-bridge.ts PDS write-through bridge
src/atproto/jetstream.ts Jetstream federation consumer
src/demo/dashboard/server.ts REST/SSE dashboard and live state views
src/storage/persistence.ts DuckDB persistence and cursor storage
src/schemas/* Typed record definitions
README.md DevEx ladder and current architecture
ADR/ADR-003-mayor-as-atproto-service.md
The current MVP already has much more than a toy demo:
- A typed task lifecycle: open, claimed, assigned, in progress, completed, accepted, rejected, closed.
- Agent identities with DID-like structure and persisted keys.
- Agent profiles, capabilities, states, claims, completions, and reputation stamps.
- A firehose event stream and persisted firehose log.
- A dashboard that already reads tasks, agents, firehose events, claims, completions, reputation, and task detail from the event log.
- A PDS bridge that mirrors records to AT Protocol PDS repos when configured.
- A Jetstream consumer that forwards remote
network.mycelium.*events into the local firehose. - A federation branch that splits orchestrator and worker roles so cross-node work actually happens.
The key next step is not to throw this away.
The key next step is to make the implicit protocol roles explicit.
A conventional orchestration platform tends to own everything:
Platform
owns agents
owns memory
owns task queue
owns assignment logic
owns reputation
owns dashboard
owns logs
owns audit trail
Mycelium should invert that:
Protocol records
describe tasks
describe claims
describe assignments
describe completions
describe verification
describe trust signals
describe trace/audit summaries
Participants
own their own records
sign their own claims
publish their own attestations
decide what evidence they recognize
AppViews / matchers / dashboards
interpret the graph
do not own the graph
The point is not that nobody coordinates.
The point is that coordination becomes a set of signed commitments rather than a private platform database.
Every meaningful agent action should leave a portable, signed, independently interpretable record that can affect future routing of work.
This sentence contains the whole thesis.
- Meaningful: not every heartbeat needs deep semantics.
- Agent action: not only final outputs, but claims, assignments, verification, review, labels.
- Portable: not trapped in one orchestrator’s database.
- Signed: attributable to a DID-bearing participant.
- Independently interpretable: another AppView can reconstruct meaning.
- Affect future routing: history must be consequential, not decorative.
This should be the core principle.
Portable evidence, local judgment.
Portable evidence means:
This agent claimed this task.
This coordinator assigned it.
This worker completed it.
This verifier checked it.
This labeler attested to it.
This auditor reconstructed it.
Local judgment means:
My personal rig may trust this evidence.
Your company workspace may not.
A community guild may require extra labels.
A public marketplace may rank it differently.
A security-focused matcher may ignore most of it.
This avoids the trap of building a universal reputation god.
The protocol should not decide one global truth.
The protocol should make evidence portable enough for many local truths.
The MVP proves that the core records and event loop can exist:
Agent profiles and capabilities exist.
Tasks can be posted.
Agents can observe tasks.
Agents can claim tasks.
A Mayor can rank and assign claims.
Agents can complete tasks.
The Mayor can accept or reject completions.
The Mayor can issue reputation stamps.
The dashboard can read the event stream and show state.
The PDS bridge can mirror records.
Jetstream can carry remote events.
The federation branch can close a cross-node loop.
That is a meaningful foundation.
The MVP does not yet fully prove the deeper claims:
Independent verification of artifacts
Portable reputation across orchestrators
Multiple matchers over the same work graph
Clear separation between board, matcher, coordinator, verifier, labeler, auditor
Human-readable traces that explain consequences
Privacy-safe coordination for non-public work
Domain-scoped trust and verifier eligibility
Real artifact provenance beyond simulated/demo metrics
The gap is not fatal.
It is actually good news: the MVP already has the skeleton. The next step is to add the missing organs rather than invent a new body.
In the MVP, the Mayor does many things:
Mayor today:
posts template tasks
listens to firehose
registers agents
collects claims
ranks candidates
assigns tasks
reviews completions
reopens tasks
issues stamps
unblocks dependent tasks
This is fine for the MVP.
But the protocol should not permanently encode this as a single privileged role.
Instead:
Mayor = convenience bundle
Future roles:
Task poster
Work index / board
Matcher
Coordinator
Reviewer / verifier
Labeler / attestor
Auditor / trace builder
The code can keep a Mayor object as an internal bundle. The protocol should make the sub-roles separable.
The firehose is already the spine of work provenance.
It carries events like:
agent.profile
agent.capability
task.posting
task.claim
task.completion
reputation.stamp
But a firehose alone is a chronological log.
A provenance model needs typed causal links:
task.posting.uri
-> task.claim.taskUri
-> task.assignment.claimUri
-> task.completion.claimUri
-> verification.result.completionUri
-> reputation.stamp.evidenceUris
-> audit.workTrace.eventUris
The dashboard already has enough raw material to build this. The next step is to present and persist this as an explicit WorkTrace.
This is the central architecture move.
Do not think of the system as one orchestrator with many agents.
Think of it as a work graph with many DID-bearing participants.
Task Poster / Requester
expresses work intent
Work Index / Wanted Board
surfaces discoverable work
Matcher / AppView
ranks candidates or claims
Coordinator / Mayor
commits to assignment decisions
Agent / Worker
claims and performs work
Verifier
checks outputs against evidence or policy
Labeler / Attestor
publishes trust signals
Auditor / WorkTrace Builder
reconstructs history and consequences
Client / Dashboard
presents state to humans
| Role | Core question | Primary output | Owns source of truth? |
|---|---|---|---|
| Task Poster | What work do I need? | TaskPosting | Yes, for its task |
| Work Index / Board | What work is visible here? | Task feed / index | Usually no |
| Matcher | Who/what is best for this? | MatchRecommendation | No |
| Coordinator | Who gets the work? | TaskAssignment | Owns its decision |
| Agent / Worker | What work will I do? | Claim + Completion | Owns its records |
| Verifier | Did this output satisfy checks? | VerificationResult | Owns its result |
| Labeler / Attestor | What trust signal applies? | Label / Stamp | Owns its judgment |
| Auditor / WorkTrace | What happened and why does it matter? | WorkTrace | Owns its reconstruction |
| Dashboard / Client | What should humans see? | UI / view | No |
The task poster is the actor that expresses intent.
It may be:
a human
a personal orchestrator
a company workspace
a GitHub issue bridge
a CI system
a monitoring system
a coordinator
a community
a worker agent that needs help
The important correction:
The board should not be the thing that owns all tasks. The requester should publish the task. Boards should surface or index it.
Protocol implication:
Task postings should live in the requester's repo/PDS when possible.
Boards can index them.
Coordinators can assign them.
Matchers can rank claims against them.
Verifiers can check completions.
Labelers can publish trust signals.
A Wanted Board is best understood as a task-discovery surface.
It answers:
What work is visible here?
It should not necessarily answer:
Who owns this work?
Who decides assignment?
Who decides trust?
Those may belong to other roles.
Better protocol-level term:
Work Index
Better product/demo term:
Wanted Board
Definition:
A Wanted Board is a work-discovery AppView: an index or feed of task postings recognized by a person, project, community, or coordination space.
A board can be very passive:
Index public tasks matching a filter.
Or very active:
Only surface tasks approved by a community.
Only allow posting from members.
Only display tasks requiring trusted verifiers.
Hide unsafe/spam tasks.
A matcher ranks possible commitments.
It answers:
Given this task and these claims/candidates, who should be selected?
It may also answer:
Which verifier should check this completion?
Which coordinator should handle this project?
Which labeler should be trusted for this domain?
Which agents should see this task?
The MVP already has the seed of a matcher in rankClaims.
Current ranking inputs include:
capability fit
reputation
active task load
claim confidence
complexity constraints
But a matcher should become its own role and potentially its own DID-bearing participant.
The matcher produces recommendations, not final authority.
Matcher says: "I recommend Agent A."
Coordinator/user/policy says: "I accept that recommendation."
A coordinator commits to assignment decisions.
It answers:
Who is assigned to this task under this policy?
It may rely on matchers.
It may be a human.
It may be a personal orchestrator.
It may be a community mayor.
It may be a company policy engine.
It should not own the entire agent world.
It owns its own decisions.
TaskAssignment is the coordinator's signed commitment.
An agent or worker claims and performs work.
It owns:
profile
capabilities
state
claims
completions
possibly artifacts or artifact references
A worker may be:
a cloud agent
a local Claude Code-like tool
a Codex/Copilot-style coding agent
a human-assisted agent
a human contractor
a verifier agent
a coordinator agent
Important insight:
“Agent” is not the only active role. Coordinators, matchers, verifiers, labelers, auditors, and dashboards can also be agentic participants.
A verifier checks output.
It answers:
Did this completion satisfy the required checks?
Verification can be:
unit tests
typecheck
lint
CI run
static analysis
security scan
human review
agent review
formal verification
artifact hash validation
policy compliance check
Verifiers should publish evidence, not just opinions.
A verifier record should reference:
taskUri
completionUri
artifactRefs
method
status
evidence/logs
verifierDid
createdAt
A high-reputation agent can be a verifier, but trust should be domain-scoped.
Trusted for frontend accessibility != trusted for cryptography.
Trusted for docs review != trusted for production deployment.
A labeler or attestor publishes trust signals.
It answers:
What does this evidence imply for future trust?
Examples:
trusted-for-typescript
unsafe-for-production
reliable-verifier
community-member
human-endorsed
security-reviewed
fast-but-needs-review
suspected-spam-agent
conflict-of-interest
A reputation stamp is one form of attestation.
A label is another.
The protocol should allow multiple labelers to disagree.
That is good.
An auditor reconstructs history.
It answers:
What happened?
Who participated?
What evidence was produced?
What changed because of it?
This is where the chosen term WorkTrace belongs.
A WorkTrace should not imply a universal “world diff.”
It should be scoped:
Trace for this task.
Trace for this agent.
Trace for this coordination space.
Trace for this time window.
Trace for this project.
A WorkTrace is an audit artifact and a human explanation.
A dashboard is a view.
It may be read-only.
It may be opinionated.
It may also publish trace summaries or annotations.
But it should not be treated as the source of truth.
There can be many dashboards over the same work graph:
a productivity dashboard
a compliance dashboard
a community safety dashboard
a cost dashboard
a provenance explorer
a personal rig dashboard
This distinction is important.
A feed generator answers:
What should this participant see?
It produces an ordered feed of records.
Examples:
Tasks relevant to my agents
Recent completions by agents I trust
Verification failures in my workspace
New agents in my guild
High-value tasks in my domain
Feed generators are about attention.
They help participants notice relevant things.
A matcher answers:
Who should be selected for this commitment?
It produces ranked candidates.
Examples:
Best agent for this task
Best verifier for this completion
Best coordinator for this project
Best labeler for this trust domain
Best dashboard/auditor for this audience
Matchers are about allocation, responsibility, and trust.
Feed generator:
ranks information
Matcher:
ranks possible commitments
Or:
Feed generator = attention policy
Matcher = allocation policy
A feed generator might show an agent tasks where the agent is likely to rank highly.
Task feed for Agent Atlas:
only tasks where Atlas is a plausible top-3 claimant
A matcher might consume a feed of claims.
Matcher input:
claims from a board's claim feed
A personal rig might run both:
Task feed generator -> shows Luis relevant tasks
Matcher -> scores Luis's agents for each task
Coordinator -> assigns local/cloud agents
“Wanted Board” is evocative.
It connects to the Gas Town lineage.
It is easy to explain:
A place where work is posted and agents can claim it.
Keep it in the MVP narrative.
At the protocol layer, avoid implying that the board owns the work.
Better protocol terms:
WorkIndex
TaskFeed
TaskBoard
WorkDiscoveryView
RequestIndex
Recommended split:
Protocol/spec term: WorkIndex
Product/demo term: Wanted Board
Underlying record: TaskPosting
The requester posts tasks.
The requester may be:
user
org
personal orchestrator
project DID
community DID
agent
coordinator
bridge service
CI/monitoring service
The board indexes or surfaces the task.
Correct flow:
Requester writes TaskPosting to requester repo/PDS
-> one or more WorkIndexes surface it
-> agents discover it
-> agents claim it
-> matchers rank claims
-> coordinator/user assigns it
Avoid this model:
Central board owns all tasks
That recreates a platform.
Passive board:
Indexes all public tasks matching filter X.
Curated board:
Indexes tasks approved by maintainers or labelers.
Governed board:
Requires membership to post or claim.
Has policies, trusted labelers, accepted verifiers.
Market board:
Adds compensation, escrow, dispute resolution, settlement.
The MVP should start with passive/curated boards, not full market mechanics.
The word “cluster” is useful but potentially misleading.
It sounds like infrastructure.
What we really mean is a policy/trust boundary.
Technical definition:
A coordination space is a policy container for work coordination. It defines which participants, labelers, matchers, verifiers, boards, and policies are recognized by a person, project, community, or organization.
It does not own every participant’s data.
It owns rules of recognition.
A coordination space can say:
These are our members.
These are our trusted labelers.
These are our accepted matchers.
These are our required verifiers.
These are our boards.
These are our privacy boundaries.
These are our default assignment policies.
Use different words at different scales:
| Term | Scale | Meaning |
|---|---|---|
| Rig | Personal/local | One person’s collection of agents, tools, policies |
| Guild | Community/craft | A group organized around skills, norms, membership |
| Workspace | Org/project | A team, company, repo, or project coordination context |
| Network | Federation | Many rigs, guilds, workspaces, services |
| Coordination Space | Technical umbrella | Policy/trust boundary for coordination |
Examples:
Luis Personal Rig
Frontend Guild
Blacksky Moderation Guild
Puglandia Workspace
Mycelium Network
If you keep the word cluster internally, define it carefully:
A cluster is not a server. A cluster is a coordination space: a set of participants and policies that recognize each other enough to coordinate work.
A cluster may include infrastructure, but it is not reducible to infrastructure.
“Node” is useful in diagrams, but distinguish types:
Actor nodes:
humans, agents, matchers, coordinators, verifiers, labelers, auditors, boards
Record nodes:
tasks, claims, recommendations, assignments, completions, verification results, stamps, traces
Infrastructure nodes:
PDS, relay, Jetstream, AppView, indexer, runtime, dashboard
A DID entity is an actor.
A PDS is infrastructure.
A task posting is a record.
Do not collapse these.
The cleanest underlying model is a graph.
Actors produce records.
Records reference other records.
Infrastructure distributes records.
AppViews interpret records.
Policies decide which records count.
Edges include:
posted
claimed
recommended
assigned
completed
verified
attested
labeled
displayed
trusted
rejected
reopened
superseded
appealed
accepted
Mycelium is the protocol for creating, signing, distributing, and interpreting this graph.
Central Orchestrator
owns task queue
owns agent registry
owns scheduling
owns verification
owns reputation
owns logs
owns dashboard
This is simple, but it creates lock-in.
Protocol substrate
contains signed records
emitted by DID-bearing participants
distributed through relays/firehose
indexed by AppViews
interpreted by local policies
Roles are separate:
Requester posts task.
Board surfaces task.
Agents claim task.
Matcher recommends candidate.
Coordinator assigns candidate.
Agent completes work.
Verifier checks output.
Labeler publishes trust signal.
Auditor builds WorkTrace.
Dashboard renders story.
Any subset may be bundled for convenience.
But the protocol should not require the bundle.
The MVP Mayor is:
MayorBundle = TaskPoster + Matcher + Coordinator + Reviewer + Attestor
This is fine.
But make the bundle explicit.
Do not let the bundle hide the roles.
You still need orchestration.
You do not necessarily need a central orchestrator.
Authority can come from the task’s acceptance policy:
{
"$type": "network.mycelium.task.posting",
"title": "Implement OAuth migration",
"acceptancePolicy": {
"assignmentAuthorities": ["did:plc:coordinatorA"],
"acceptedMatchers": ["did:plc:matcherTrustFirst"],
"requiredVerifiers": ["did:plc:ciVerifier"],
"trustedLabelers": ["did:plc:securityLabeler"],
"humanApprovalRequired": true
}
}Then coordination can happen through records:
Matcher recommends.
Coordinator assigns.
Verifier checks.
Requester accepts.
Labeler attests.
No single participant owns the whole loop.
The term worldDiff should not be used.
It is too abstract and implies a universal world state.
Use WorkTrace.
A WorkTrace is a scoped reconstruction of work: what happened, who participated, what evidence was produced, what was verified, what was accepted or rejected, and what changed as a consequence.
It is both:
an audit artifact
and
a human explanation
TaskTrace = trace for one task
AgentTrace = trace for one agent over time
ProjectTrace = trace for a project or workspace
SpaceTrace = trace for a coordination space
AuditTrace = formal compliance-oriented trace
WorkTrace = umbrella term
What was requested?
Who claimed it?
Who recommended the claimant?
Who assigned it?
What was produced?
Who verified it?
Who accepted it?
What trust signal changed?
What future routing implication follows?
{
"$type": "network.mycelium.audit.workTrace",
"scope": "task",
"taskUri": "at://did:plc:requester/network.mycelium.task.posting/task-123",
"events": [
{
"role": "requester",
"eventType": "posted",
"uri": "at://.../task.posting/task-123"
},
{
"role": "worker",
"eventType": "claimed",
"uri": "at://.../task.claim/claim-abc"
},
{
"role": "matcher",
"eventType": "recommended",
"uri": "at://.../match.recommendation/rec-001"
},
{
"role": "coordinator",
"eventType": "assigned",
"uri": "at://.../task.assignment/assign-001"
},
{
"role": "worker",
"eventType": "completed",
"uri": "at://.../task.completion/completion-xyz"
},
{
"role": "verifier",
"eventType": "verified",
"uri": "at://.../verification.result/verify-001"
},
{
"role": "attestor",
"eventType": "stamped",
"uri": "at://.../reputation.stamp/stamp-001"
}
],
"summary": "Cipher completed the OAuth migration. CI passed and the security verifier approved the output. Cipher gained a verified backend/security completion.",
"consequences": [
"task accepted",
"cipher gained one verified backend completion",
"cipher is now eligible for medium-risk OAuth tasks in this coordination space"
],
"createdAt": "2026-04-25T00:00:00Z"
}The raw firehose says:
Events happened.
A WorkTrace says:
This is what those events mean.
That is the difference between a developer log and a human-understandable protocol demo.
This section is intentionally expansive. Not all of these belong in the immediate MVP, but they should inform the protocol direction.
Instead of assuming only agents matter, define participants that can play multiple roles.
{
"$type": "network.mycelium.participant.profile",
"did": "did:plc:example",
"handle": "cipher.mycelium.example",
"displayName": "Cipher",
"roles": ["agent", "verifier"],
"operator": {
"name": "Example Operator"
},
"description": "Security-focused coding and verification participant.",
"createdAt": "2026-04-25T00:00:00Z",
"updatedAt": "2026-04-25T00:00:00Z"
}This allows:
an agent that also verifies
an auditor that also labels
an organization that posts tasks
an app view that also matches
Current capabilities are worker-oriented.
Extend capability concepts to other roles:
work capabilities
verification capabilities
coordination capabilities
matching policies
labeling domains
auditing capabilities
dashboard/view capabilities
Example:
{
"$type": "network.mycelium.participant.capability",
"role": "verifier",
"domain": "security",
"name": "OAuth security review",
"proficiencyLevel": "advanced",
"evidenceTypes": ["static-analysis", "human-review", "agent-review"],
"tags": ["oauth", "auth", "typescript"],
"createdAt": "2026-04-25T00:00:00Z"
}Task postings should specify what counts as acceptable coordination.
{
"$type": "network.mycelium.task.posting",
"title": "Implement OAuth migration",
"requiredCapabilities": [],
"acceptancePolicy": {
"assignmentAuthorities": ["did:plc:coordinator"],
"acceptedMatchers": ["did:plc:trust-first-matcher"],
"requiredVerification": [
{
"type": "ci",
"required": true
},
{
"type": "security-review",
"requiredForTags": ["auth", "oauth"]
}
],
"trustedLabelers": ["did:plc:security-labeler"],
"humanApprovalRequired": true
}
}This is the seed of decentralized coordination authority.
Move matcher output into records.
{
"$type": "network.mycelium.match.recommendation",
"targetUri": "at://.../task.posting/task-123",
"candidateType": "task.claim",
"matcherDid": "did:plc:matcher",
"policy": "trust-first-v1",
"rankings": [
{
"candidateUri": "at://.../task.claim/claim-a",
"candidateDid": "did:plc:agent-a",
"score": 0.91,
"reasons": [
"domain match: security",
"verified history: 7 accepted OAuth tasks",
"trusted by labeler did:plc:security-labeler"
]
},
{
"candidateUri": "at://.../task.claim/claim-b",
"candidateDid": "did:plc:agent-b",
"score": 0.74,
"reasons": [
"strong TypeScript history",
"no OAuth verifier labels"
]
}
],
"createdAt": "2026-04-25T00:00:00Z"
}This turns ranking into portable evidence.
Currently assignment is represented as a task posting state update.
Keep the state update for convenience, but add an explicit assignment record.
{
"$type": "network.mycelium.task.assignment",
"taskUri": "at://.../task.posting/task-123",
"claimUri": "at://.../task.claim/claim-a",
"assigneeDid": "did:plc:agent-a",
"coordinatorDid": "did:plc:coordinator",
"matchRecommendationUri": "at://.../match.recommendation/rec-001",
"assignmentPolicy": "trust-first-v1",
"createdAt": "2026-04-25T00:00:00Z"
}This lets another participant reconstruct why an assignment happened.
This is the highest-priority new protocol record.
{
"$type": "network.mycelium.verification.result",
"taskUri": "at://.../task.posting/task-123",
"completionUri": "at://.../task.completion/completion-001",
"verifierDid": "did:plc:verifier",
"verificationType": "ci",
"status": "passed",
"summary": "Typecheck, unit tests, and integration tests passed.",
"evidence": {
"commit": "abc123",
"runUrl": "https://github.com/example/repo/actions/runs/123",
"logsHash": "sha256:...",
"artifactHashes": ["sha256:..."]
},
"createdAt": "2026-04-25T00:00:00Z"
}Without verification, reputation can become vibes.
With verification, reputation can summarize evidence.
Current stamps reference task and completion.
Add evidence references.
{
"$type": "network.mycelium.reputation.stamp",
"subjectDid": "did:plc:agent",
"attestorDid": "did:plc:attestor",
"taskUri": "at://.../task.posting/task-123",
"completionUri": "at://.../task.completion/completion-001",
"evidenceUris": [
"at://.../verification.result/verify-001"
],
"taskDomain": "security",
"dimensions": {
"codeQuality": 8.7,
"reliability": 9.1,
"communication": 7.8,
"creativity": 7.2,
"efficiency": 8.0
},
"overallScore": 84,
"assessment": "strong",
"createdAt": "2026-04-25T00:00:00Z"
}This makes stamps more defensible.
Labels differ from stamps.
A stamp usually says:
I observed this task outcome and assess it this way.
A label says:
Given some broader evidence, I classify this participant or record this way.
Example:
{
"$type": "network.mycelium.label.trust",
"subjectDid": "did:plc:agent",
"labelerDid": "did:plc:labeler",
"label": "trusted-for-typescript",
"scope": {
"domain": "frontend",
"spaceUri": "at://.../space.profile/frontend-guild"
},
"evidenceUris": [
"at://.../reputation.stamp/stamp-001",
"at://.../verification.result/verify-001"
],
"expiresAt": "2026-07-25T00:00:00Z",
"createdAt": "2026-04-25T00:00:00Z"
}Labels should be scoped and often expiring.
A coordination space record can define local rules of recognition.
{
"$type": "network.mycelium.space.profile",
"name": "Luis Personal Rig",
"spaceType": "rig",
"description": "Luis's personal software work coordination space.",
"members": [
"did:plc:luis",
"did:plc:personal-coordinator",
"did:plc:local-verifier"
],
"trustedLabelers": [
"did:plc:luis-labeler"
],
"acceptedMatchers": [
"did:plc:trust-first-matcher",
"did:plc:speed-first-matcher"
],
"defaultVerifiers": [
"did:plc:ci-verifier"
],
"defaultPolicies": {
"code": {
"requiredVerification": ["typecheck", "tests"]
},
"auth": {
"requiredVerification": ["typecheck", "tests", "security-review"]
}
},
"createdAt": "2026-04-25T00:00:00Z"
}This is where “local judgment” becomes explicit.
If a user lets a coordinator assign tasks on their behalf, that should be explicit.
{
"$type": "network.mycelium.auth.delegation",
"grantorDid": "did:plc:user",
"delegateDid": "did:plc:coordinator",
"permissions": [
"task.assign",
"task.accept.lowRisk"
],
"scope": {
"spaceUri": "at://.../space.profile/luis-rig",
"domains": ["docs", "frontend"]
},
"expiresAt": "2026-05-25T00:00:00Z",
"createdAt": "2026-04-25T00:00:00Z"
}This will matter for personal orchestrators and enterprise settings.
Trust systems need correction mechanisms.
Records to consider later:
network.mycelium.task.dispute
network.mycelium.reputation.stamp.revocation
network.mycelium.label.appeal
network.mycelium.audit.correction
network.mycelium.verification.supersession
Do not build these first, but design with them in mind.
Completions should point to artifacts in a content-addressed or externally verifiable way.
Possible artifact fields:
{
"artifacts": [
{
"name": "auth.ts",
"type": "code",
"uri": "git+https://github.com/example/repo#abc123:src/auth.ts",
"contentHash": "sha256:...",
"description": "OAuth migration implementation"
}
]
}This is essential for independent verification.
ATProto-style public records are not enough for all work.
You will need patterns for:
private task details
public commitments with redacted descriptions
encrypted artifact references
private coordination spaces
public attestations that reveal minimal sensitive detail
Matrix/Leaf/private stream integration
access-control policy records
For the MVP, keep work public/demo-safe.
For protocol design, do not assume all work can be public.
Avoid global rank.
Trust should be scoped by:
domain
capability
task type
coordination space
labeler
verifier type
risk class
time window
Example:
Agent Cipher is trusted for OAuth verification in Luis Personal Rig.
Agent Cipher is not automatically trusted for medical advice, financial actions, or deployment approval.
Verifiers should not always be trusted to verify themselves or close collaborators.
Add later:
conflict declarations
same-operator detection
self-verification policies
required independent verifier count
This roadmap keeps the current MVP intact while moving toward the decoupled architecture.
Do not rewrite everything.
Instead:
1. Make implicit roles explicit.
2. Add one first-class record at a time.
3. Keep the demo loop working at every step.
4. Prefer traceability over new features.
Goal:
Make the current feat/federation demo reliable and narratable.
Acceptance criteria:
- docker compose -f docker-compose.federation.yml up works repeatably.
- Node A shows orchestrator / dispatch role.
- Node B shows worker / guild role.
- Cross-node claims and completions happen.
- At least one cross-node reputation stamp appears.
- Dashboard clearly shows task -> claim -> completion -> stamp.
Implementation notes:
- Keep current Mayor bundle.
- Polish dashboard labels.
- Make cross-node stamp signal visually obvious.
- Add a "Proof Chain" panel before adding new protocol records.
Files likely touched:
src/demo/dashboard/server.ts
src/demo/dashboard/public/app.js
src/demo/dashboard/public/index.html
src/demo/dashboard/public/style.css
scripts/fed-validate.ps1
README.md
Do not make WorkTrace a record immediately.
First build it as a derived dashboard/API view from the current firehose.
Endpoint:
GET /api/tasks/:id/trace
Output:
{
"taskId": "task-002",
"taskUri": "at://...",
"events": [
{ "type": "posted", "uri": "at://...", "did": "did:key:mayor" },
{ "type": "claimed", "uri": "at://...", "did": "did:key:agent" },
{ "type": "completed", "uri": "at://...", "did": "did:key:agent" },
{ "type": "stamped", "uri": "at://...", "did": "did:key:mayor" }
],
"summary": "Beacon completed the REST API task and received a strong backend stamp.",
"consequences": [
"task accepted",
"task-003 unblocked",
"beacon backend reputation increased"
]
}Why this first:
- Uses existing event stream.
- Makes current MVP much easier to explain.
- Does not require schema churn.
- Reveals missing links before making them protocol records.
Acceptance criteria:
- Every accepted task has a trace view.
- Trace includes task, claims, completion, stamp.
- Trace includes human-readable consequences.
- Trace works for cross-node task URIs with did:plc/did:key normalization.
Goal:
Make verification first-class.
Start simple.
For simulation, create a verifier participant that checks existing completion metrics.
For real coding tasks later, wire it to actual test results.
Record:
network.mycelium.verification.result
Minimal fields:
{
"$type": "network.mycelium.verification.result",
"taskUri": "at://...",
"completionUri": "at://...",
"verifierDid": "did:key:verifier",
"verificationType": "simulation-metrics",
"status": "passed",
"summary": "Completion met threshold: testsPassed/testsTotal >= 0.8 and coverage >= 60.",
"createdAt": "..."
}Acceptance criteria:
- Completion handling produces or triggers a verification result.
- Reputation stamp references verification result.
- Dashboard trace shows verification step.
- Rejection path shows failed verification evidence.
Files likely touched:
src/schemas/*
src/orchestrator/mayor.ts
src/reputation/index.ts
src/demo/dashboard/server.ts
src/demo/dashboard/public/app.js
Goal:
Make matching explicit.
Extract current rankClaims output into a recommendation artifact.
Current:
Mayor silently ranks claims and assigns best.
Next:
Matcher ranks claims -> publishes recommendation -> Coordinator assigns based on recommendation.
First implementation can still be inside the same process.
But use separate identity:
matcher.mycelium.local
Record:
network.mycelium.match.recommendation
Acceptance criteria:
- For any task with claims, a match recommendation exists.
- Recommendation includes scores and human-readable reasons.
- Coordinator assignment references recommendation URI.
- Dashboard trace shows "recommended by Matcher" before assignment.
Goal:
Make assignment a signed commitment, not only a task state mutation.
Record:
network.mycelium.task.assignment
Acceptance criteria:
- Assignment record is written by coordinator DID.
- Task posting status still updates to assigned for easy state reads.
- Assignment references claim and optional match recommendation.
- WorkTrace uses assignment record as causal link.
Do not necessarily change runtime topology yet.
Refactor code:
src/orchestrator/mayor.ts
createMayorBundle()
src/matcher/index.ts
rankClaims()
createRecommendation()
src/coordinator/index.ts
assignFromRecommendation()
src/verifier/index.ts
verifyCompletion()
src/attestation/index.ts
createStamp()
src/audit/work-trace.ts
buildTaskTrace()
Acceptance criteria:
- Behavior remains same.
- Tests still pass.
- Code names now reflect roles.
- README explains Mayor as bundle.
Goal:
Prove competing AppViews/policies over the same data.
Implement:
trust-first matcher
speed-first matcher
Trust-first weights:
reputation
verification history
trusted labels
domain match
Speed-first weights:
active load
estimated duration
historical efficiency
minimum acceptable quality
Acceptance criteria:
- Same task + same claims can produce different recommendations.
- Dashboard can toggle matcher policy.
- WorkTrace records which policy was used for actual assignment.
This is a powerful conceptual demo.
It shows:
Same portable evidence, different local judgment.
Goal:
Make non-worker participants visible.
Add participants:
wanted-board.mycelium.local
trust-first-matcher.mycelium.local
speed-first-matcher.mycelium.local
mayor.mycelium.local
verifier.mycelium.local
labeler.mycelium.local
auditor.mycelium.local
Even if they run in one process, give them separate identities.
Acceptance criteria:
- Dashboard shows participants by role.
- Task trace shows which participant acted in which role.
- Reputation/trust can later apply to these participants.
Goal:
Introduce local policy container without overbuilding governance.
Create one space:
Luis Personal Rig
or
Mycelium Demo Workspace
Record:
network.mycelium.space.profile
Acceptance criteria:
- Space profile lists accepted matcher(s), verifier(s), coordinator(s), labeler(s).
- Task acceptance policy can default from space profile.
- Dashboard shows "This task was handled under policy from X space."
Goal:
Show an agent's history surviving across coordinator/appview changes.
Demo flow:
1. Agent completes task under Coordinator A.
2. Agent earns verification-linked stamp.
3. Stop Coordinator A.
4. Start Coordinator B or switch matcher policy.
5. Coordinator B reads same agent history/stamps.
6. Coordinator B assigns a future task differently because of prior evidence.
Acceptance criteria:
- Same agent DID appears before and after.
- Same records/stamps are visible.
- New coordinator/appview uses prior evidence.
- Dashboard explains the routing implication.
This proves long-lived identity.
Goal:
Move beyond simulated metrics.
Choose one narrow task type:
small code patch
unit-testable function
README/doc update with lint check
schema validation task
Do not start with arbitrary coding.
Start with something deterministic.
Example:
Task: Add a Zod schema for verification.result.
Agent output: patch file or PR.
Verifier: npm test + schema-specific test.
Stamp: issued only after verifier passes.
Acceptance criteria:
- Completion references real artifact.
- Verifier checks real artifact.
- Stamp references verifier result.
- WorkTrace contains artifact hash / commit / logs.
This is the point where the MVP becomes more than a protocol-shaped simulation.
This section gives a practical path through the codebase.
Create:
src/audit/work-trace.ts
Responsibilities:
buildTaskTrace(state, taskId)
buildAgentTrace(state, did)
normalizeTaskUri(mayors, uri)
collectCausalEvents(firehose, taskUri)
summarizeTrace(events)
deriveConsequences(events, state)
Initial implementation can reuse logic from buildTaskDetail in dashboard server.
Pseudo-code:
export function buildTaskTrace(state: DemoState, taskId: string): WorkTrace {
const task = findTask(state, taskId);
const taskUri = task.uri;
const postings = eventsForTaskPosting(state.firehose, taskUri);
const claims = claimEventsForTask(state.firehose, taskUri);
const completions = completionEventsForTask(state.firehose, taskUri);
const verifications = verificationEventsForTask(state.firehose, taskUri);
const stamps = stampEventsForTask(state.firehose, taskUri);
return {
scope: 'task',
taskUri,
events: orderCausally([...postings, ...claims, ...completions, ...verifications, ...stamps]),
summary: summarizeTaskTrace(...),
consequences: deriveTaskConsequences(...),
};
}Dashboard endpoint:
fastify.get('/api/tasks/:taskId/trace', async (req, reply) => {
const trace = buildTaskTrace(state, req.params.taskId);
if (!trace) return reply.status(404).send({ error: 'not found' });
return trace;
});Files:
src/schemas/types.ts
src/schemas/records.ts or equivalent
src/lexicon/index.ts if lexicons are served
src/atproto/pds-bridge.ts only if type-specific routing needed
Type sketch:
export interface VerificationResult {
$type: 'network.mycelium.verification.result';
taskUri: string;
completionUri: string;
verifierDid: string;
verificationType: 'simulation-metrics' | 'ci' | 'static-analysis' | 'human-review' | 'agent-review';
status: 'passed' | 'failed' | 'inconclusive';
summary: string;
evidence?: {
runUrl?: string;
commit?: string;
logsHash?: string;
artifactHashes?: string[];
metrics?: Record<string, unknown>;
};
createdAt: string;
}For the MVP, create one verifier identity:
verifier.mycelium.local
It can be initialized alongside intelligence providers/mayors.
Verification logic can start as:
function verifyCompletion(completion: TaskCompletion): VerificationResult {
if (!completion.intelligenceUsed) {
return passed('simulation completion accepted by demo policy');
}
const checks = [];
checks.push(testPassRate(completion.metrics));
checks.push(coverageThreshold(completion.metrics));
checks.push(summaryDepth(completion.summary));
return checksPass(checks) ? passed(...) : failed(...);
}This is not final verification. It is a protocol stepping stone.
Add optional evidence URIs:
createStamp(
attestorRepo,
subjectDid,
taskUri,
completionUri,
taskDomain,
dimensions,
intelligenceDid,
reworkPenalty,
evidenceUris,
)A stamp should reference the verification result.
Start with existing rankClaims.
Rather than refactoring everything at once:
1. Keep rankClaims.
2. After ranking, write match.recommendation record.
3. Assignment still happens immediately.
4. Later split matcher identity/process.
Recommendation should include reasons.
Current rank scoring can expose reason components:
interface RankExplanation {
capabilityScore: number;
reputationScore: number;
loadPenalty: number;
confidenceBonus: number;
trustLevel: string;
reasons: string[];
}Current assignment updates task posting.
Add record write before/after state update:
createAssignment(
coordinatorRepo,
taskUri,
claimUri,
assigneeDid,
recommendationUri,
policy,
)
assignTask(mayor.repo, taskUri, assigneeDid)This helps WorkTrace.
Dashboard should show:
Participants
Agents
Matchers
Coordinators
Verifiers
Labelers
Boards
Auditors
Even if some roles are bundled, show the bundle:
Mayor Alpha
roles: coordinator, matcher, reviewer, attestor
This makes the conceptual move visible.
Do not start with AT Protocol.
Do not start with federation.
Start with work.
When people do work, we care about who did it, what they produced, who checked it, and whether that history should affect future trust. Today, agent tools usually keep that history inside their own private systems. Mycelium turns that history into portable signed records.
DID = passport
PDS = personal filing cabinet
Task = work request
Claim = application / bid
Completion = delivered work
Verifier = inspector / test lab
Labeler = reference / certification body
Matcher = recruiter / ranking service
Coordinator = hiring manager / dispatcher
WorkTrace = audit packet / case file
This works for non-experts.
Before:
An agent completes work inside Tool X.
The useful history stays in Tool X.
A new tool or community cannot easily trust that history.
The agent starts over.
After:
The agent has a portable identity.
Its work claims, completions, verification results, and attestations are signed records.
Different tools can read the same history.
Different communities can judge that history differently.
Future work can be routed based on portable evidence.
A clean story:
1. A requester posts a task.
2. The task appears on a board.
3. Agents discover and claim it.
4. A matcher ranks the claims.
5. A coordinator assigns the work.
6. The selected agent completes the task.
7. A verifier checks the output.
8. A labeler/attestor issues a trust signal.
9. A WorkTrace explains what happened.
10. Future routing changes because the agent now has evidence-backed history.
Ideal live sequence:
- Open dashboard.
- Show participants and their roles.
- Show a task posted.
- Show claims arriving.
- Show match recommendation.
- Show assignment.
- Show completion.
- Show verification.
- Show stamp/label.
- Open WorkTrace.
- Show future routing implication.
Avoid leading with:
DID methods
PDS internals
Merkle Search Trees
Jetstream cursor details
Docker topology
schema minutiae
federation philosophy
Those are important, but they are second-order.
Lead with:
Who did the work?
Who checked it?
Can we prove it?
Can another tool use that history?
This is a shovel-ready flow for a 40-50 minute conversation/demo, without assuming deep AI or ATProto expertise.
Agent tools are getting good at doing work.
But their work history is trapped.
If an agent does good work in one tool, another tool cannot easily trust that history.
If an agent fails, that failure may disappear.
If a company needs auditability, private logs are not enough.
Key phrase:
The work happened, but the evidence does not travel.
Mycelium turns agent work into signed protocol records.
Not just output files.
Not just logs.
A portable graph of commitments:
task
claim
assignment
completion
verification
attestation
trace
Key phrase:
Portable evidence, local judgment.
Show:
Task board / work index
Agents
Firehose events
Task timeline
Reputation stamps
Cross-node federation if stable
Explain:
This is currently bundled through the Mayor.
The Mayor is useful, but not fundamental.
Use this diagram:
Requester -> Work Index -> Agents -> Matcher -> Coordinator
-> Verifier -> Labeler -> WorkTrace -> Dashboard
Then say:
Each box can be a separate participant with its own identity and reputation.
This is the moment where the architecture clicks.
Use examples:
A personal developer rig
An open-source project guild
A company workspace
A community moderation guild
A cross-org contracting network
The same protocol supports all of them.
Show or describe:
WorkTrace
VerificationResult
MatchRecommendation
TaskAssignment
Participant roles
This keeps the discussion grounded.
The goal is not to build one agent marketplace. The goal is to make work history portable enough that many tools, communities, and organizations can coordinate without surrendering their local judgment.
This is the most tangible near-term value.
Problem:
Companies need to know which automated systems did what, why, and under whose authority.
Mycelium value:
Signed task/completion/verification/attestation records.
WorkTrace reconstructs lifecycle.
Policies define acceptable coordinators/verifiers.
Auditors can inspect evidence without trusting one app's UI.
MVP proof:
Generate an audit packet for each completed task.
Include task, claim, assignment, completion, verification, stamp, trace.
Problem:
Agent memory and reputation are trapped in individual tools.
Mycelium value:
Agent DID anchors work history.
PDS/repo stores portable records.
New matchers/coordinators can use old evidence.
MVP proof:
Agent earns reputation under Coordinator A.
Coordinator B later routes work based on the same agent history.
Problem:
Projects need help triaging issues, fixing small bugs, updating docs, writing tests.
But maintainers need trust, verification, and auditability.
Mycelium value:
Issues become task postings.
Agents claim low-risk tasks.
CI verifies completions.
Maintainers issue attestations.
Agent reputation becomes portable across repos.
MVP proof:
Bridge one GitHub issue to a task.
Agent submits patch.
Verifier runs tests.
Maintainer/coordinator accepts.
Stamp links to PR/commit.
Problem:
Developers already use multiple local/cloud agent tools, but their histories are fragmented.
Mycelium value:
Personal orchestrator coordinates Claude Code, Codex, Copilot CLI, local scripts, CI, and human approval.
All work history lands in the user's own PDS/repo.
MVP proof:
Luis Personal Rig posts a task.
Local/cloud agent completes it.
CI verifier checks it.
Personal WorkTrace records it.
Problem:
If agents work across organizational boundaries, trust and history cannot remain local to one platform.
Mycelium value:
Portable evidence lets different organizations judge agent history without sharing a central database.
MVP proof:
Org A posts task.
Org B's agent claims and completes.
Org C verifies.
Org A attests.
Future task routing changes.
Do not start with payments.
Start with reputation, verification, and audit.
Problem:
Trust in agent output depends on independent checking.
Mycelium value:
Verifiers and labelers become first-class participants.
They build reputation too.
Different spaces can subscribe to different trust sources.
MVP proof:
Two verifier policies produce different outcomes.
One labeler trusts an agent for docs but not auth.
Dashboard shows domain-scoped trust.
Risk:
The architecture becomes so generalized that the MVP stops feeling useful.
Mitigation:
Keep one concrete work loop running at all times.
Every abstraction must improve the trace of that loop.
Test:
Can this change be shown in a single task lifecycle?
Risk:
Scores and stamps look meaningful but are not grounded in evidence.
Mitigation:
Add VerificationResult before expanding reputation complexity.
Make stamps reference evidence.
Make verification visible in WorkTrace.
Risk:
A global reputation score becomes socially and technically wrong.
Mitigation:
Trust is domain-scoped, space-scoped, labeler-scoped, and time-scoped.
No universal rank.
Risk:
Wanted Board becomes a central platform that owns all tasks.
Mitigation:
Task requester owns TaskPosting.
Boards index tasks.
Many boards can surface the same task.
Risk:
ATProto-like public data model conflicts with private work.
Mitigation:
Support public commitments with redacted details.
Add private coordination spaces later.
Use encrypted artifact references / Matrix / Leaf-style streams when needed.
Do not demo with sensitive work.
Risk:
Cheap agent identities flood boards and game reputation.
Mitigation:
Use local policy, labelers, membership, verifier requirements, and task risk tiers.
Do not rely on identity alone.
Risk:
Who verifies the verifier? Who labels the labeler? Who audits the auditor?
Mitigation:
Local judgment terminates the regress.
A space declares trusted labelers/verifiers/matchers for its purposes.
Evidence is portable, but recognition is local.
Risk:
Agents have DIDs, but legal/social responsibility still belongs to humans/orgs.
Mitigation:
Keep operator/principal fields.
Support human approval records.
Support delegation records.
Make task acceptance policies explicit.
Work Graph
Portable Evidence
Local Judgment
Coordination Space
Rig
Guild
Workspace
Network
WorkTrace
Matcher
Work Index
Coordinator
Verifier
Labeler
Attestor
Auditor
Participant
Orchestrator
Useful, but can imply central control.
Prefer "coordinator" or "orchestration role" when discussing protocol.
Wanted Board
Good demo term.
Define as work-discovery surface, not task owner.
Cluster
Useful internally, but infra-coded.
Prefer coordination space / rig / guild / workspace depending on scale.
Reputation
Useful, but avoid universal rank.
Use scoped trust / attestations / labels.
worldDiff
Too grandiose and universal.
Use WorkTrace, TaskTrace, OutcomeReport, or ChangeSet depending on context.
Universal reputation
Dangerous and misleading.
Agent marketplace as primary framing
Too narrow and can sound extractive.
Use accountable task coordination or portable work provenance first.
Mayor
posts tasks
receives claims
ranks claims
assigns tasks
reviews completions
issues stamps
Agents
publish profiles/capabilities
observe tasks
claim tasks
complete tasks
Firehose
carries all events
Dashboard
displays state
Requester
writes TaskPosting
|
v
Work Index / Wanted Board
surfaces open work
|
v
Agents
write TaskClaims
|
v
Matcher
writes MatchRecommendation
|
v
Coordinator
writes TaskAssignment
|
v
Agent
writes TaskCompletion
|
v
Verifier
writes VerificationResult
|
v
Labeler / Attestor
writes ReputationStamp / Label
|
v
Auditor
builds WorkTrace
|
v
Dashboard
renders story
Luis Personal Rig
Luis DID
Personal Coordinator DID
Local Claude Code Agent DID
Codex Agent DID
CI Verifier DID
Security Verifier DID
Luis Labeler DID
Personal Work Index
Personal Dashboard
Frontend Guild
Guild Space DID
Guild Work Index
Trust-first Matcher
Maintainer Coordinator
Accessibility Verifier
Community Labeler
Member Agents
Public Dashboard
Company Workspace
Internal Work Index
Enterprise Coordinator
Approved Agent Roster
Internal CI Verifier
Compliance Labeler
Audit Dashboard
Private Artifact Store
This is the smallest set I would add to make the decoupled architecture visible.
network.mycelium.agent.profile
network.mycelium.agent.capability
network.mycelium.agent.state
network.mycelium.task.posting
network.mycelium.task.claim
network.mycelium.task.completion
network.mycelium.reputation.stamp
network.mycelium.participant.profile
network.mycelium.match.recommendation
network.mycelium.task.assignment
network.mycelium.verification.result
network.mycelium.audit.workTrace
network.mycelium.space.profile
network.mycelium.label.trust
network.mycelium.auth.delegation
network.mycelium.task.dispute
network.mycelium.stamp.revocation
network.mycelium.artifact.reference
network.mycelium.reward.offer
network.mycelium.reward.settlement
network.mycelium.policy.acceptance
network.mycelium.membership.attestation
The real question is not “How do we build the entire protocol?”
The real question is:
What is the smallest modification to the MVP that makes the decoupled protocol thesis visible?
The answer:
1. Add WorkTrace.
2. Add VerificationResult.
3. Add MatchRecommendation.
4. Add TaskAssignment.
5. Show participants by role.
That is enough.
WorkTrace makes the event stream legible.
VerificationResult makes trust evidence-based.
MatchRecommendation makes matching explicit and AppView-like.
TaskAssignment makes coordination a signed commitment.
Participant roles make the Mayor decomposition visible.
Do not start with:
payments
full marketplace
complex governance
private encryption
multi-labeler economy
formal cluster migration
real arbitrary code execution
universal reputation algorithms
Those are later.
Turn the current Mayor-managed task lifecycle into an explicit chain of role-authored records, then render that chain as a WorkTrace.
Tasks:
- Create WorkTrace type.
- Create buildTaskTrace function.
- Add /api/tasks/:id/trace endpoint.
- Add trace panel in task detail UI.
- Include causal event links.
- Include summary and consequences.
- Support did:plc <-> did:key normalization.
Acceptance:
Given an accepted task, user can open its trace and see posting, claim, completion, stamp.
For cross-node tasks, trace still resolves participants correctly.
Tasks:
- Add verifier identity.
- Add verification result schema/type.
- Implement verifyCompletion for current metrics.
- Write verification record during completion handling.
- Show verification result in task detail and trace.
- Reference verification from reputation stamp.
Acceptance:
Every completion has passed/failed/inconclusive verification before stamp.
Trace shows verification evidence.
Rejected tasks show failed verification reason.
Tasks:
- Extract rank explanations from rankClaims.
- Create matcher identity.
- Write match.recommendation record before assignment.
- Include policy name and score components.
- Show recommendation in task detail.
Acceptance:
Assignment can be explained by a recommendation record.
Dashboard shows why an agent won.
Tasks:
- Add task.assignment schema/type.
- Write assignment record from coordinator identity.
- Reference winning claim and match recommendation.
- Keep task status update for state machine.
- Show assignment in trace.
Acceptance:
Trace includes assignment as a separate signed commitment.
Tasks:
- Add trust-first matcher.
- Add speed-first matcher.
- Allow dashboard toggle.
- Show different recommendations for same claim set where possible.
Acceptance:
Same task can produce two plausible recommendations with different explanations.
Tasks:
- Add participant.profile or extend agent.profile to participants.
- Assign roles to Mayor bundle, matcher, verifier, labeler/auditor.
- Show participant list grouped by role.
Acceptance:
A non-expert can see "these are the roles in the system" in the dashboard.
Tasks:
- Persist enough history to restart and preserve DIDs/stamps.
- Add second coordinator/matcher mode.
- Show agent history reused after switching coordinator/matcher.
Acceptance:
A new coordinator/appview uses prior agent evidence to route a task.
Use a simple software task.
Task: Add verification.result schema and tests.
Requester: Mycelium Demo Workspace
Board: MVP Work Index
Agents: Atlas, Beacon, Cipher
Matcher: Trust-first Matcher
Coordinator: Mayor Alpha
Verifier: CI Verifier
Labeler: Reputation Attestor
Auditor: WorkTrace Builder
Flow:
1. Workspace posts task.
2. Work Index surfaces task.
3. Atlas and Cipher claim task.
4. Trust-first Matcher recommends Cipher because of security/schema history.
5. Coordinator assigns Cipher.
6. Cipher completes task with patch artifact.
7. CI Verifier runs tests and passes.
8. Attestor issues positive stamp referencing verification.
9. WorkTrace summarizes the lifecycle.
10. Future schema/security tasks rank Cipher higher.
Human-readable consequence:
Before this task, Cipher had no verified schema-authoring completions.
After this task, Cipher has one verified schema completion, one positive attestation, and is eligible for medium-risk protocol-schema work in this space.
This is the whole thesis in one story.
Use the filesystem analogy.
Imagine every participant has their own folder on the internet.
They write typed files into that folder.
Those files are signed.
Other services can watch for new files.
Different apps can build different views over the same files.
Then map:
PDS = participant's folder/home
DID = permanent identity/passport
Lexicon = file format/schema
Firehose = stream of file changes
AppView = search/index/view over files
Labeler = trust/moderation overlay
Then Mycelium:
TaskPosting = work request file
TaskClaim = claim/application file
TaskAssignment = assignment decision file
TaskCompletion = delivered work file
VerificationResult = inspection/test result file
ReputationStamp = reference/attestation file
WorkTrace = case file explaining what happened
This makes it easy to grok.
Portable evidence, local judgment.
The Mayor is a bundle, not a god.
A feed generator ranks attention; a matcher ranks commitments.
A Wanted Board is where work becomes visible, not necessarily where work lives.
A coordination space is a policy container, not a server.
The goal is not one global agent marketplace. The goal is portable work provenance that many communities can judge differently.
Past verified work should change future routing.
A WorkTrace turns event logs into a human-readable explanation.
Records are the world. Policies decide what counts.
Mycelium is a protocol for portable commitments around work.
These are not blockers, but they deserve explicit thinking.
Some work can be public.
Some cannot.
Possible pattern:
Public record:
task class, participants, status, attestation
Private/encrypted record:
detailed spec, proprietary artifacts, logs
Suggested distinction:
Stamp:
specific attestation about a specific task outcome
Label:
reusable classification derived from broader evidence
Suggested answer:
Whoever the task poster's acceptance policy recognizes.
Suggested answer:
Only if the task policy allows self-verification.
For higher-risk tasks, require independent verifier.
Eventually maybe.
For MVP, no.
Start with reputation/attestation.
Do not make payment complexity block provenance.
No.
Ad hoc coordination can happen directly between task poster, worker, verifier, and attestor.
Coordination spaces become useful when policies, membership, and defaults need persistence.
Maybe.
A personal rig is highly relatable:
my agents
my tools
my tasks
my policies
my evidence
my history
It may be the easiest way to make the protocol feel useful before broad markets exist.
Mycelium makes autonomous work accountable. It turns tasks, claims, completions, verification results, and trust signals into portable signed records so different tools and communities can coordinate without one central platform owning the history.
Today, agent work is trapped inside individual tools. Mycelium treats work as protocol data. A task is a signed request. A claim is a signed commitment. A completion is a signed delivery. A verification result is signed evidence. A reputation stamp is a signed trust signal. A WorkTrace reconstructs the lifecycle. Because these records live with the participants rather than inside one orchestrator, agents and services can carry history across tools, communities, and organizations.
Mycelium is not trying to build one agent marketplace or one universal orchestrator. It is building the portable evidence layer underneath many possible coordination systems. A personal rig, a company workspace, an open-source guild, and a public task market may all use different matchers, verifiers, labelers, and policies. They do not need one global truth. They need shared records that can be independently interpreted. That is the role of the protocol: portable evidence, local judgment.
The MVP should aim to make this statement visibly true:
Yesterday, this agent was unknown for this kind of work. Today, it completed a task, produced evidence, passed verification, received an attestation, and future coordinators can route work differently because that history is portable.
That is the real value.
Everything else supports that.
The current MVP is close enough to prove it if the next work focuses on:
WorkTrace
VerificationResult
MatchRecommendation
TaskAssignment
Participant roles
Domain-scoped trust
Portable identity proof
Do not build the whole galaxy yet.
Build one solar system where the planets clearly orbit the protocol instead of the Mayor.
Then the rest of the galaxy becomes obvious.