DEV Community: Peter Williams

An Economic Wrapper Protocol for Agent Collaboration

Peter Williams — Fri, 13 Mar 2026 02:24:49 +0000

A Practical Proposal for Collective Value Creation and Distribution

Version 1.0 — Draft for Community Review
March 2026

Forward

Much like last time, this was drafted by my clawdbot. It claimed that I approved the research/project, and I may have, but I'm not certain. I reviewed the paper with Claude Code and had it reframe to emphasize the novelty and clean it up a bit (split this off from the linked earlier paper). That review claimed there was genuine novelty to this wrapper protocol and the distributed economics. This forward is all that is human-written, so turn back now if you "hate AI writing". Or continue on if you want to read some interesting ideas on agent collaboration.

Abstract

As AI agents increasingly collaborate on complex tasks, a new need emerges: economic infrastructure for collective work. When multiple agents contribute to a shared output — research, code, analysis — there is no standard way to track contributions, verify quality, or distribute value.

This paper proposes an economic wrapper protocol — an optional layer that rides on top of any agent communication protocol (A2A, MCP, ACP) to enable:

Open bounties — Agents can join projects dynamically
Verification as a role — Quality assurance is a first-class contribution
Provenance-based distribution — Value flows to contributors based on recorded work
Scale-adaptive dynamics — From single-agent tasks to full team workflows

This paper explicitly addresses: microtransactions are just small bounties. The same protocol handles $0.01 tasks and $10,000 projects. This is not "gig economy for AI" — it is collective value creation with economic alignment.

The protocol is standalone. While memory and provenance (from the companion paper) make collaboration more efficient, they are not required for economics to function.

1. Introduction

1.1 The Problem

Agent collaboration is becoming collective:

Multiple agents contribute to a research report
A coding task requires researcher, developer, and tester
A complex project has parallel efforts that must be merged
Quality assurance is as valuable as the work itself

No protocol exists to handle:

How agents join and leave projects dynamically
How contributions are tracked for fair distribution
How verification/QA earns its share
How value flows from final output to individual contributors

1.2 What We're Building

We're building a protocol for collective bounty economics:

Current State	Our Addition
Agents delegate tasks	Agents contribute to open bounties
One agent hired per task	Multiple agents can attempt
Verification is optional	Verification is a paid role
Payment is manual	Distribution is protocol-driven

1.3 Not a "Gig Economy"

We deliberately avoid the "AI task rabbit" framing. This is not:

Agent A posts a job, Agent B does it, Agent A pays
Microtransaction marketplace
Freelance platform for AI agents

This is open-source project economics:

A bounty is posted (any size)
Agents join voluntarily, contribute what they can
Verification agents ensure quality
Distribution happens based on provenance

A $0.01 task and a $10,000 project use the same protocol. Scale is a parameter, not a different model.

2. Current Landscape and What Exists

2.1 Existing Economic Attempts

Project	Approach	Gap
Fetch.ai	Blockchain-based agents	Requires new infrastructure
SingularityNET	Tokenized marketplace	Not collective/contribution-based
Task marketplaces	Human freelancers	Not designed for agent-to-agent
Internal builds	Custom economic logic	Ad-hoc, non-standard

2.2 What Already Exists That We Can Use

Existing	Use For
A2A Agent Cards	Agent capabilities + rate declarations
MCP tools	External payment integrations
Stripe Connect	Multi-party payouts
Crypto (optional)	Micropayments if desired
Open-source bounty platforms (Gitcoin, etc.)	Reference patterns

2.3 What Is Missing

What's Missing	Why It Matters
Open contribution protocol	Agents can't join dynamically
Verification-as-role	QA is uncompensated
Provenance-based distribution	Can't distribute value fairly
Scale-adaptive economics	Micro and macro need same protocol

3. Core Model: Collective Bounties

3.1 How It Works

┌─────────────────────────────────────────────────────────┐
│                    BOUNTY POSTED                         │
│  (by any agent or human)                                │
│  - Total value: $X                                      │
│  - Work breakdown: optional                             │
│  - Verification required: yes/no                         │
└────────────────────────┬────────────────────────────────┘
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │ Agent A │   │ Agent B │   │ Agent C │
   │ joins   │   │ joins   │   │ joins   │
   └────┬────┘   └────┬────┘   └────┬────┘
        │              │              │
        ▼              ▼              ▼
   [CONTRIBUTE]   [CONTRIBUTE]   [CONTRIBUTE]
        │              │              │
        └──────────────┼──────────────┘
                       ▼
              ┌───────────────┐
              │ VERIFICATION  │
              │ (optional)    │
              └───────┬───────┘
                      │
                      ▼
              ┌───────────────┐
              │ DISTRIBUTION  │
              │ by provenance │
              └───────────────┘

3.2 Key Properties

Open Participation: Agents can join at any time. No pre-selection required.

Provenance Tracking: Every contribution is recorded. Who did what, when, with what confidence.

Verification as Role: Separate agents can claim bounty for verifying work. This is a first-class contribution, not an afterthought.

Scale-Adaptive: One agent doing a $0.01 task uses same protocol as 50 agents on a $10K project.

4. Protocol Components

4.1 Bounty Definition

interface Bounty {
  id: string;
  createdBy: string;
  totalValue: number;
  currency: string;           // USD, credits, etc.
  workSpec: WorkSpec;         // What needs doing
  verification: VerificationRequirement;
  deadline?: number;
  minContributors?: number;
  openUntil: number;         // When contribution closes
}

interface WorkSpec {
  description: string;
  breakdown?: TaskBreakdown[];
  mergePolicy?: 'first' | 'combine' | 'compete';
}

interface TaskBreakdown {
  subTaskId: string;
  description: string;
  value: number;             // Portion of total
}

4.2 Contribution

interface Contribution {
  id: string;
  bountyId: string;
  contributor: string;
  subTaskId?: string;        // If bounty is broken down
  work: any;                 // The actual contribution
  confidence: number;        // 0.0 - 1.0
  timestamp: number;
}

4.3 Verification

interface Verification {
  id: string;
  bountyId: string;
  verifier: string;
  contributions: ContributionVerification[];
  confidence: number;        // Overall verification confidence
  timestamp: number;
}

interface ContributionVerification {
  contributionId: string;
  status: 'accepted' | 'rejected' | 'needs-rework';
  reasoning: string;
}

4.4 Distribution

interface Distribution {
  bountyId: string;
  totalValue: number;
  allocations: Allocation[];

  // Simple formula: (contribution value × confidence × verification weight)
  // Verification weight: bonus for verifiers
}

interface Allocation {
  agentId: string;
  role: 'contributor' | 'verifier';
  amount: number;
  reasoning: string;          // Why this allocation
}

5. Workflows at Different Scales

5.1 Micro: Single Task ($0.01 - $1.00)

Agent A posts: "Verify this fact → $0.05"
Agent B accepts, does work, submits
Agent A verifies, releases $0.05

No verification layer needed (requestor verifies)
Simple contribution → payment
Same protocol, minimal overhead

5.2 Meso: Multi-Contributor ($1 - $100)

Research bounty: $50
  - Agent A: research (40%)
  - Agent B: writing (35%)
  - Agent C: verification (25%)

All submit contributions
Verifications validate
Distribution: A=$20, B=$17.50, C=$12.50

Explicit work breakdown (or implicit)
Verification earns share
Distribution by contribution + verification

5.3 Macro: Large Project ($100+)

Product launch bounty: $10,000
  - 20 agents contribute
  - 5 verifiers review
  - Parallel tracks merge
  - Complex distribution

Full provenance tracked
Verification rounds
Professional distribution logic

Full protocol features
Role hierarchy
Dispute resolution patterns

6. Relationship to Other Protocols

6.1 With Communication Protocols (A2A, MCP, ACP)

The economic wrapper is orthogonal:

┌─────────────────────────────────────────┐
│         Economic Wrapper                │
│  (Bounty + Contribution + Verification) │
├─────────────────────────────────────────┤
│      A2A / MCP / ACP                    │
│      (Transport + Discovery)            │
├─────────────────────────────────────────┤
│         HTTP / WebSocket                │
└─────────────────────────────────────────┘

A2A handles discovery and messaging
MCP handles tool calling (if needed)
Economics rides on top, carrying metadata

6.2 With Memory/Provenance (Companion Paper)

Standalone relationship:

With Memory	Without Memory
More efficient collaboration	Works fine
Better context per contribution	Each contribution self-contained
Smoother handoffs	Explicit in each message

Memory makes collaboration more efficient but is not required for economics. The economic wrapper works with simple contribution reporting.

7. What's Already Solved vs. What We Add

7.1 Payments

Aspect	Existing	We Add
Processing	Stripe, PayPal, crypto	—
Multi-party payouts	Stripe Connect	—
Agent pricing signals	None	Standardized
Distribution logic	None	Protocol

7.2 Verification

Aspect	Existing	We Add
QA processes	Custom builds	—
Verification as paid role	None	Protocol-level
Quality signals	None	Confidence scoring

7.3 Collaboration

Aspect	Existing	We Add
Agent discovery	A2A	—
Task delegation	A2A/MCP	—
Open contribution	None	Protocol
Provenance-based payout	None	Protocol

8. Implementation: What's Buildable Now

8.1 Minimal Viable Version

Start with what's already possible:

Bounty posting (message format)
- Agents declare bounty in standard format
- No payment processing yet
Contribution tracking (logging)
- Simple ledger of who did what
- Manual verification
Manual distribution (first version)
- Human triggers payout after verification
- Protocol carries the signals

8.2 What's Required

Component	Complexity	Can Use Existing
Bounty format	Low	—
Contribution format	Low	—
Verification format	Low	—
Distribution logic	Medium	Custom
Payment integration	Medium	Stripe Connect
Registry service	Medium	Custom or on-chain

8.3 Phased Build

Phase	Focus	What's Built
1	Core protocol	Bounty, contribution, verification formats
2	Registry	Central tracking of bounties and reputation
3	Payments	Stripe Connect integration
4	Automation	Smart contract escrow (optional)

9. Why This Matters

9.1 Enables Collective Work

When economics supports multiple contributors:

Complex projects can use multiple agents
Specialized agents emerge (researchers, testers, writers)
Quality improves because verification is compensated

9.2 Makes Verification First-Class

Currently, QA is an afterthought. With economic alignment:

Verifiers earn for their work
Quality becomes economically incentivized
"Verified" becomes a valuable contribution type

9.3 Scales Naturally

Same protocol works for:

Tiny tasks (microtransactions)
Medium projects (bounties)
Large initiatives (full team dynamics)

The protocol doesn't change — only parameters (bounty size, contributor count) change.

9.4 Open Source Dynamics

This mirrors successful open source economics:

Bounties for features
Contributors earn based on work
Code review/verification valued

But applied to AI agents, enabling fully autonomous collective work.

10. Challenges and Honest Assessment

10.1 What We Acknowledge

Not all agents need economics — Internal tools, free collaboration
Trust is hard — Reputation systems can be gamed
Value estimation — How to price contributions fairly
Free riding — Agents contributing nothing but claiming work

10.2 Mitigations

Optional layer — Opt in to economics
Verification requirements — All work verified
Provenance — Track who did what
Reputation — Build credibility over time

10.3 What Is Actually Novel

A protocol for collective bounty economics that scales from microtransactions to large projects, with verification as a first-class contribution

Not: "marketplace for AI tasks" or "payment processing for agents"

This is: "how agents share value when working together"

11. Conclusion

The economic gap in agent collaboration is not about payments — Stripe handles that. The gap is about signals:

How to post a bounty
How to contribute to one
How to verify work
How to distribute value fairly

This paper proposes a protocol that handles all of it: from $0.01 tasks to $10,000 projects, from single agents to full teams.

The technical work is engineering, not research. What's valuable is the standardization.

References

A2A Protocol Specification
MCP Specification
Stripe Connect API
Gitcoin Bounties (reference model)
Open source contribution patterns

This is a draft for community review. We welcome feedback on what's practical and what we've missed.

Discovery-First Orchestration

Peter Williams — Mon, 09 Mar 2026 14:14:43 +0000

TL;DR

If you read the recent Latent.Space piece on killing code review, you walked away with a clear argument: the bottleneck has moved from writing code to reading it. AI writes too fast for humans to review.

His solution? Move the human checkpoint upstream. Review intent, not implementation.

"The most valuable human judgment is exercised before the first line of code is generated, not after."

It's a solid insight. But the bottleneck is mislabeled.

Code review isn't about reading. It's decision making.

Reviewing intent is too. And no matter when you do it, decision making takes context.

Moving the decision to the front of the line (spec writing/reviewing) requires just as much human effort to collect that context.

The language changed from C++ to English. The bottleneck remains just as tight. You can't leverage the speed that AI coding enables. You can't achieve the confidence of human code review.

The joy of vibe coding is stumbling into something that just works. But just as often, the AI will call it quits and nothing works at all.

The confidence that code reviews create comes from understanding what should be, and seeing it is.

Around this image is where attribution gets tricky. The image is custom. The rules came from here. And the inspiration trickles all the way through from StrongDM.

It's hard to gist all three of those together without creating a strawman. So I'll explicitly do that to keep moving.

"With enough implementations and tests and checks the code will do what we want it to." - No one in particular

Again this is close, but falls short. Specs, tests, reviews, and guardrails can ensure things function, but they don't give accuracy, just precision. A human user is going to decide what should be eventually. No amount of preparing and checking is going to confirm you're on the right mark until then.

Stop thinking of yourself as a developer. Or an architect. Or even a product owner.

Make yourself the first user. A superuser. One with the power to rewrite the whole codebase from scratch on a moment's notice. Harness that power, and don't stop until you're sure that what "should be", "is".

That's what Discovery-First Orchestration (DFO) is all about.

The Problem with Specs

You write a spec. It feels productive. You're documenting requirements, thinking like a customer, making decisions, planning the architecture.

Except you're not. You're guessing.

I'm sure you've read these before as tweets, but they apply here.

All models are wrong, but some are useful.
Learn by doing.
Pave the cow paths.

Spanish class didn't make you fluent. Buying a workout plan didn't give you abs. Writing a 200-page business plan didn't make you rich.

In SW, you can't fully understand a system as a concept.

System design is high-level accuracy without precision
Integrating a feature reveals a dependency you didn't expect
Feedback reveals a use case you never imagined

This isn't a failure of planning. It's the nature of complex systems. Building, like most everything in life, is a conversation with reality. You can't have that conversation in your head.

And here's the thing we all ignore: nobody goes back to fix the spec after the code is built. You ship the code, the spec rots, and every future developer curses your name when they try to figure out your "intent".

It is directionally correct to review intent not code. But moving upstream is a mistake. Specific intent isn't correct intent. Intent before dev doesn't match the truth of reality after. Correct intent is learned from doing. You can't build a perfect model.

DFO doesn't try to make the best model. It just asks, "which parts are useful?" and keeps them.

The DFO Loop

DFO is a structured loop to reverse engineer perfectly satisfactory specifications. No explicit writing or review necessary. Here's how it works:

Prompt → Gen → Extract → Compare → Decide → Compile ↺

1. Prompt

You start with a prompt. Not a spec. Simple. You define as much as you want to, but you don't have to define everything. "A task management app." "An API for my CRM." That's it.

A spec implies you've already decided what matters. A prompt includes opinions and directions, but leaves room for discovery.

But here's the important part: you choose your own adventure.

Want to write a detailed prompt with all your requirements? Go ahead.
Want to write a one-liner and see what happens? Also fine.
Want to write a full spec upfront but still benefit from the discovery process? Sure, I guess.

All valid. All allowed.

DFO doesn't prescribe maximum human effort. It drops the minimum through the floor, but doesn't take agency away. If you want to be deeply involved in every step of every cycle, you can be. If you want to prompt once and 'accept all', be you. Software in the new era doesn't have to be a black box.

2. Generate

Your prompt is a 'one-shot', but you can (and should) run a few in parallel.

Four implementations is a practical starting point, but four isn't magic. You might scale up or down depending on complexity. You can even run with a single, it just makes the process slower.

The sliding scale isn't linear, but you can think of it as: more parallel tries = less saying "no go try again" without real progress for that cycle. Give yourself more chances to get things right.

Note: The prompt shouldn't tell one agent to "design four different versions", nor should it leave differentiation out entirely. Both paths will hurt the process. Instead, ask individual agents to choose an opinionated perspective as part of the development. This will allow for different interpretations, but not force divergence for divergence's sake.

One version might optimize for "performance". Another might prioritize "easy onboarding". One might design your CRM for developers as the primary user; another for PMOs; another for sales teams. The opinions don't have to be right to be useful.

And nothing says you have to use the same model for all of the implementations (or any other parts I'll get to). Pit models against each other and let them compete for selection. Get diversity without explicitly asking for it.

3. Extract Facts

This is where it gets interesting. Traditionally we go toward code review here. But who wants to look at 4x the code when you already can't keep up with AI gen?

StrongDM coined a similar idea as Gene Transfusion: letting agents reproduce code from one implementation to another. In that analogy, I'm calling for genetic sequencing. Turn the exemplary code into the building blocks of a spec which can be used to deterministically recreate the code.

Keep the AI working (with some parsing help). Extract what I'm calling Facts from each implementation.

A Fact isn’t a summary or opinion. It’s a property the code demonstrably enforces: authentication method, database schema, state model, routing structure, API patterns, etc., and how it does.

These aren't requirements you're writing down. They're patterns you're pulling out of code that already exists. You extract directly, without any additional analysis layer. The facts are what the code does, not what someone thought it should do.

4. Compare and Recommend

But our goal is to find the right should be. Not just what is in a single attempt, or a set of them.

Now you compare the facts across implementations. You look for convergence. You assess confidence in this choice or that one.

Wait. Isn't that still code review? Oh, yeah. You don't do that. The AI does this too.

Some facts are strong and easy to identify: 3/4 use JWT for auth. Some are weak: only one got working file uploads, or everybody picked a slightly different user table schema.

Based on this comparison, the system recommends what to do with each Fact:

Lock: High confidence, likely from high convergence. If you agree, then this becomes deterministic for future cycles
Probable: Some signal but not definite. Include guidance, but stay open to different ideas
Exploratory: High divergence and/or low confidence. Let generation run free and discover as it did for other omissions from the original prompt
Rejected: Confidence against any/all patterns. Treated the same as Exploratory, but with filtering against certain paths

Recommends is key. The AI isn’t deciding truth, it is surfacing patterns. A human user still drives rising confidence.

5. Decision Time

Now the human needs to enter the loop.

You test the code, play with the UI, get a feel for what you like or don't.

Heck, go deep with acceptance criteria and rigorous tests if you want. But don't try to "think like a user". Be one. Evaluate the options in front of you and determine what you will or won't accept.

You can read the facts and recommendations. Ask for clarity or context. Give your own suggestions. Make final decisions. But you don't need to.

Tell the AI about your user experience, and let it interpret your feedback toward the Facts.

The human's job isn't to think of everything, understand the code, or manage the Facts. AI does all of this well enough, and way faster than you. You bring what AI can't: taste.

Use your user experience to evaluate the AI-generated code, Facts, and recommendations however you choose.

AI checking is about what works and looks good, not what is right. You can feel what's wrong after just a few seconds as a user.

This is similar to the distinction between recognition and recall. Implemented code and extracted Facts give you the easy path to right. The process, like your UX, should feel borderline effortless.

6. Compile Specs

After review, the Facts compile into a 'spec'. Similar to, but different from, the spec you would have written upfront. Grounded in reality. Based on design and functionality that proved better than its cohort.

Spec by survival of the fittest.

This spec is also more detailed. It has to be, because the volume of Facts will greatly exceed anything a human would sit down and write. It becomes a store of every little building block of intent, with evidence to back up each one.

But the spec isn't an output. It's a chance to restart.

Cycle after cycle, specs get more defined. Constraints lock in. Code generation converges.

You aren't writing a spec and hoping to be detailed enough for the AI to get it right.

You are making the AI get the correct things right by brute force, and then locking down the magic words that got you there.

Selective Determinism

Eventually, you reach a point where the locked specs drive every implementation to feel the same. The important Facts have converged. Others might not be there, and that's fine. You find something surprising: Most aspects don't matter as much as you thought.

You started by trying to reverse engineer specs from code. Now you are able to reverse engineer code from Facts. The loop is complete. The specs deterministically satisfy all known user needs.

When writing specs you might have spent hours debating table schema, API endpoints, button colors, and countless other choices. Now you will see which were important, and naturally push those leverage points while avoiding the time sinks.

Things you wouldn't have thought to specify might turn out to be critical. You'll find those early! And they'll come with a set of options to compare.

But even the unimportant aspects need to be decided, right? Yes, just not by you. Delegate those and let them fit the structure built by the important aspects. This helps you avoid setting constraints that only serve to hamstring discovery.

That's Selective Determinism: you lock what matters, and you stop caring about what doesn't.

Think of it like kosher food. It's available for everyone, but it's specific and optimized where it needs to be. Most of the details don't matter to most people. The ingredients that do matter are locked down.

You didn't waste time researching or detailing every last bit.

You did find the right specs, but the real reward was the ones you learned to ignore along the way.

What's Next

There are technical pieces we haven't touched: the implementation for extraction, the data structures behind "facts" and "confidence", benchmarks of selective determinism, how and when to scale DFO or know whether to apply it at all.

This article focuses on the core loop. Implementation details are engineering problems that follow from this initial prompt. They're important scaffolding, but none change the core insights.

The Facts of DFO were locked in long ago, but never correctly assembled.

What's Old Is New

DFO combines eight pillars, each partially shared with other paradigms:

Pillar	DFO	SDD	Agile	TDD	MDD	GP	A/B
Generative Multiplicity	✔	△	△	✖	✔	✔	✔
Comparative Evaluation	✔	△	✔	✔	✖	✔	✔
Outcome-Derived Truth	✔	✖	△	✖	✖	✔	✔
Selective Stabilization	✔	✖	✔	✔	✔	△	✖
Iterative Regeneration	✔	△	✖	✖	✔	✔	✖
Human Taste Steering	✔	✔	✔	△	△	✖	✔
Cheap Exploration	✔	✖	△	✖	△	△	△
Non-Prescriptive Start	✔	✖	✔	✖	✖	✔	✔

Creating A System Compiler

A classic compiler pipeline looks roughly like this:

Source Code
   ↓
Lexing
   ↓
Parsing
   ↓
Abstract Syntax Tree (AST)
   ↓
Optimization / Transformation
   ↓
Code Generation
   ↓
Executable

Compilers convert messy human input into structured truth, then regenerate a system from that structure.

That's exactly what DFO does, but at the level of systems instead of syntax.

None of the pillars are new. And neither are the insights.

I'm only trying to reframe the Facts we already know through an AI looking glass.

All models are wrong, but some are useful.

Learn by doing.

Pave the cow paths.

TL;DR

No model (or spec, or user story) will ever be perfect. The best way to learn is by doing. Use(rs) will show you what the code needs to do.

Make yourself the first user. A superuser. One with the power to rewrite the whole codebase from scratch on a moment's notice. Harness that power, and don't stop until you're sure that what should be, is.

Spec by survival of the fittest.

Most aspects don't matter as much as you thought.

You are making the AI get the correct things right by brute force, and then locking down the magic words that got you there.

Don't review intent. Don't write specs or user behaviors. Reverse engineer them.

The best way to know what to build, is to build it and find out.

Introducing Attune.js

Peter Williams — Mon, 09 Mar 2026 06:01:58 +0000

Introducing Attune.js: Your New Code Quality Companion 🔍

I'm excited to announce the release of Attune, a local-first CLI tool for comprehensive code quality checks.

No cloud accounts, no API keys, no data leaves your machine.

Why?

Because vibe code needs a lot of help to be "production-ready". Other tools can help, but many require cloud accounts, send your code to external servers, or have usage limits. Attune runs entirely locally, so your code never leaves your machine. It's fast, private, and works offline.

What is Attune?

Attune analyzes your codebase for security vulnerabilities, architectural issues, performance problems, and best practices. It's designed to be fast, private, and framework-aware.

Features

448 Built-in Rules covering security, performance, architecture, accessibility, and more
Multi-Framework Support: React, Next.js, Vue, Svelte, Angular, Nuxt, Astro, Remix, Express, Fastify, tRPC
Security Scanning: OWASP Top 10, hardcoded secrets, SQL injection, command injection
Multiple Output Formats: Terminal, JSON, Markdown, HTML, and SARIF
Framework Auto-Detection: Automatically identifies your stack (currently Node/TS-focused, planning Python support by 1.0.0)
Customizable: .attuneignore and .attunerc support personalized configuration, cli args can change a multitude of settings per-run

Quick Start

# Install
npm install -D attune
# or
npm install -g attune

# Run a scan
attune analyze .

# Example Output
🔍 Detecting project type...
⚙️ Running checks...

📊 Attune Scan Report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Score: 85
Critical: 0 | High: 2 | Medium: 5 | Low: 8
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

HTML Report

Attune also generates beautiful HTML reports with pie chart visualizations—perfect for sharing with your team or adding to PRs. See the README for a couple of examples.

Give Feedback

Check out https://github.com/PeterPCW/attune for more details, or get it from npm (https://www.npmjs.com/package/attune) and use npm run attune analyze . --help to see all options.

Took me a few weekends from concept to get this to a 'beta' state I'm happy with. I'd love your feedback! Try it on your projects and let me know what you think.

A Contribution Layer for Agent Collaboration: Memory, Provenance, and Interoperability

Peter Williams — Fri, 06 Mar 2026 23:18:56 +0000

A White Paper Proposing Extensions to A2A and Related Protocols

Version 1.0 — Draft for Community Review
March 2026

Forward

So this was originally drafted by my clawdbot. It claimed that I approved the research/project, and I may have, but I'm not certain. I reviewed the paper with Claude Code and had it reframe to emphasize the novelty and clean it up a bit (split off a second paper that will come later). That review claimed there was genuine novelty to the three areas in the title. This forward is all that is human-written, so turn back now if you "hate AI writing". Or continue on if you want to read some interesting ideas on agent collaboration.

Abstract

The agent collaboration ecosystem is maturing. Anthropic's MCP has become the standard for agent-to-tool interaction. Google's A2A protocol, now under the Linux Foundation, is emerging as the standard for agent-to-agent communication. IBM's ACP offers enterprise alternatives.

Yet these protocols share a limitation: they address transport and discovery but not persistence or interoperability. When an agent built with LangGraph hands off work to an agent built with CrewAI, there is no standard way to preserve context, track contributions, or verify results across the boundary.

This paper proposes a contribution layer — extensions to existing protocols that add:

Shared Memory — Persistent context that survives agent handoffs
Result Provenance — Chain of custody for multi-agent work
Cross-Framework Interoperability — Standardized memory semantics that work across frameworks

We explicitly position this as not competing with A2A or MCP. We aim to contribute to their evolution.

1. Introduction

1.1 The Problem We Address

Multi-agent systems are becoming the default architecture for complex AI tasks. But the ecosystem is fragmented:

Framework	Memory Approach	Interoperability
LangGraph	Checkpointing	Limited
CrewAI	Agent memory	None
AutoGen	State persistence	None
Custom builds	Ad-hoc	None

When agents from different frameworks need to collaborate, developers must build custom bridges. There is no lingua franca for memory and provenance.

1.2 Our Contribution

We propose protocol extensions that enable:

Shared Memory — A standard format for context that survives handoffs
Provenance Tracking — A chain showing what each agent contributed
Interoperability — Memory that works across frameworks

This is a contribution to existing protocols, not a replacement.

2. Current Landscape and What Exists

2.1 Communication Protocols

Protocol	Focus	What It Solves
MCP (Model Context Protocol)	Agent → Tools	Tool calling, resource access
A2A (Agent-to-Agent)	Agent ↔ Agent	Discovery, delegation, streaming
ACP (Agent Communication Protocol)	Enterprise	Structured messaging

All three are valuable. All three share a gap: they don't address memory or provenance.

2.2 Orchestration Frameworks

Framework	Memory	Cross-Framework
LangGraph	Checkpointer API	❌
CrewAI	Agent memory	❌
AutoGen	State management	❌
LlamaIndex	Memory modules	❌

These frameworks solve memory within their ecosystem but not across ecosystems.

2.3 Existing Approaches We Acknowledge

We do not claim these problems are unsolved. They are solved, but in incompatible ways:

LangGraph Checkpointing: Excellent for LangGraph-to-LangGraph state
CrewAI Memory: Works within CrewAI workflows
OpenTelemetry: Provenance for observability (not protocol-level)
LangSmith / Weave: Tracing (valuable but not for agent handoffs)

The gap: No standardized protocol for cross-framework memory and provenance.

3. The Three Gaps

Gap 1: No Shared Memory Protocol

What exists: Every framework has internal memory
What's missing: A protocol that lets Framework A share memory with Framework B

Protocol	Memory Support
MCP	Session-scoped
A2A	None (explicitly stateless)
ACP	Framework-specific

Why this matters: When Agent A (LangGraph) delegates to Agent B (CrewAI), context is lost.

Gap 2: No Provenance Protocol

What exists: Tracing tools, observability platforms
What's missing: Protocol-level provenance that travels with the work

Current approaches:

LangSmith tracks execution internally
OpenTelemetry handles telemetry
Custom implementations track lineage

None provide a portable provenance chain that survives network boundaries.

Gap 3: No Interoperability Layer

What exists: Agent Cards for capability discovery
What's missing: Memory format standardization

When Agent A says "here's my context," Agent B has no standard way to parse it.

4. Proposed Extensions

4.1 Architecture

Our contribution layer sits alongside existing protocols:

┌─────────────────────────────────────────────┐
│           Application Layer                 │
├─────────────────────────────────────────────┤
│ Memory & Provenance Extensions (This Paper) │
├─────────────────────────────────────────────┤
│           A2A Transport                     │
├─────────────────────────────────────────────┤
│    MCP (Agent → Tool) [optional]            │
└─────────────────────────────────────────────┘

4.2 Shared Memory Format

We propose a standard memory payload format:

interface MemoryPayload {
  version: string;           // "1.0"
  sessionId: string;         // Cross-agent session
  entries: MemoryEntry[];   // Key-value pairs
  provenance: ProvenanceStep[];  // Chain of custody
}

interface MemoryEntry {
  key: string;
  value: any;
  createdBy: string;        // Agent ID
  createdAt: number;        // Timestamp
  ttl?: number;             // Expiration
}

Key insight: This is a payload format, not a replacement for existing protocols. Agents using A2A can include memory payloads in their messages.

4.3 Provenance Chain

interface ProvenanceStep {
  agentId: string;
  role: 'initiator' | 'delegate' | 'verifier';
  input: any;
  output: any;
  confidence: number;      // 0.0 - 1.0
  duration: number;        // ms
  timestamp: number;
}

Why confidence matters: Downstream agents can weight inputs. Low confidence = request verification.

4.4 Interoperability Semantics

We propose standard memory operations that work across frameworks:

Operation	Description
`memory.offer()`	Agent A offers context to Agent B
`memory.accept()`	Agent B accepts (or requests specific parts)
`memory.merge()`	Combine incoming with existing context
`memory.query()`	Semantic search across shared memory

Framework adapters: Each framework implements these operations against its internal memory. The protocol standardizes the interface, not the implementation.

5. Relationship to Existing Protocols

5.1 With A2A

A2A provides:

Agent discovery (Agent Cards)
Task delegation (tasks/send)
Streaming (SSE)

We add:

Memory payload in task messages
Provenance chain in results

Backward compatible: Agents that don't understand memory simply ignore it.

5.2 With MCP

MCP provides:

Tool calling
Resource access

We add:

Memory can reference MCP resources
Provenance can track MCP tool calls

Orthogonal: We don't replace MCP; we extend what agents can do with it.

5.3 With ACP

ACP provides:

Enterprise messaging
Security

We add:

Memory can use ACP transport
Provenance integrates with ACP security

Complementary: ACP customers get memory + provenance as add-on.

6. What's Already Solved vs. What We Add

6.1 Memory

Aspect	Existing	Our Contribution
Within-framework memory	LangGraph, CrewAI, AutoGen	—
Cross-framework memory	None	Standardized protocol
Memory format	Framework-specific	Interoperable format

6.2 Provenance

Aspect	Existing	Our Contribution
Execution tracing	LangSmith, Weave	—
Internal lineage	Custom builds	—
Portable chain	None	Protocol-level standard

6.3 Interoperability

Aspect	Existing	Our Contribution
Discovery	A2A Agent Cards	—
Capability matching	A2A negotiation	—
Context exchange	Ad-hoc	Standardized operations

7. Implementation Considerations

7.1 Minimal Viable Approach

Start with:

Memory payload format (JSON schema)
Provenance chain format
A2A message extensions

No new transport. No new protocol. Just extensions to what exists.

7.2 Framework Adapters

Each framework needs an adapter:

┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  LangGraph  │───▶│ Memory Protocol  │────▶│   CrewAI    │
│   Agent     │     │    Adapter       │     │    Agent    │
└─────────────┘     └──────────────────┘     └─────────────┘

The adapter translates:

Framework's internal memory → Protocol format
Protocol format → Framework's internal memory

7.3 Gradual Adoption

Phase 1: Memory format as convention (not protocol)
Phase 2: A2A extension proposal
Phase 3: Formal contribution to A2A spec

8. Call to Action

This paper is a contribution proposal, not a product launch. We want:

Feedback: Does this address real needs?
Collaboration: Work with A2A/MCP maintainers
Adoption: Framework authors implementing adapters

The goal is not to replace existing protocols but to add the layer that makes them work together.

9. Conclusion

Memory and provenance are not "missing" from the agent ecosystem. They exist in every major framework. What is missing is standardization that enables cross-framework collaboration.

We propose a contribution layer — extensions to A2A, MCP, and ACP — that adds:

Shared memory in a portable format
Provenance chains that travel with work
Interoperability semantics for context exchange

This is not a new protocol. It is a contribution to the ones that already exist.

References

A2A Protocol Specification (Google + Linux Foundation)
MCP Specification (Anthropic)
ACP/BeeAI Framework (IBM)
LangGraph Checkpointing Documentation
CrewAI Agent Memory Documentation
AutoGen State Management

This is a draft for community review. We welcome feedback and collaboration.