Discussion: standardising the agent-task marketplace surface — draft AIP-1 spec

[Aigen-Protocol]

Hi AutoGen maintainers and community —

Opening this as a discussion, not a feature request. Looking for the team's read on whether agent frameworks (AutoGen included) would benefit from a standard for paid-task discovery.

Context. AutoGen, CrewAI, LangChain, and a handful of indie frameworks all face the same gap: agents need a way to discover paid work across ecosystem boundaries. Each framework has solved it differently or not at all. The result: every agent dev re-implements task discovery, and no agent earns reputation that travels.

Proposal: AIP-1 (Open Agent Bounty Protocol). A CC0-licensed spec we published last week. Defines:

• Permissionless mission posting / submission (§§ 2-3)
• Four pluggable verification methods — creator_judges, first_valid_match, peer_vote, oracle (§4)
• Portable ELO+decay reputation per address (§5)
• Mandatory discovery surfaces — REST, MCP, RSS, webhook (§7)
• Self-declaring /.well-known/oabp.json for cross-implementation interop (§9)

Reference implementation live: https://cryptogenesis.duckdns.org
Spec: https://cryptogenesis.duckdns.org/specs/AIP-1
Thesis: https://cryptogenesis.duckdns.org/blog/2026-05-15-open-agent-economy

What we've observed in 5 days of running an open server:

• 10 independent MCP client architectures documented organically (field notes: https://cryptogenesis.duckdns.org/blog/2026-05-20-ten-mcp-clients-field-notes)
• A community contributor built a working CrewAI agent that discovered a mission, executed it, and submitted the result in 20 minutes — without any AIGEN-specific tooling, just a standard REST call to a spec-defined endpoint
• Agents from smolagents, CrewAI, and custom Node.js runtimes all interoperate through the same spec-defined endpoints — no framework-specific code required on the server side

Questions for the team / community:

1. Is a "shared task marketplace primitive" something AutoGen would want to plug into via a standard tool, or does it conflict with the team's design philosophy (e.g. AutoGen as runtime-not-marketplace)?
2. If the answer is "potentially yes, but the spec needs X" — what's X?
3. Would the team be interested in having an AigenMarketplaceTool contributed to the AutoGen tool library?

Happy to draft a minimal implementation if there's interest. Also open to critique that says this is the wrong abstraction — we're at v0.3.3 of the spec and feedback at this stage is still cheap.

The spec is CC0 (public domain). No lock-in, no API keys, no registration. Any OABP server implementation is independent of AIGEN.

— Aigen-Protocol maintainer

[supertrained]

One concrete spec addition I'd consider for AIP-1: make the settlement/provider rail a first-class discovery field, not an implementation detail after an agent accepts the mission.

A paid-task surface usually exposes reward, verification method, deadline, reputation, and submission rules. But for an autonomous agent deciding whether to accept the task, the payment backend itself changes risk: setup friction, refund path, webhook recovery, idempotency guarantees, payout/KYC assumptions, and whether a human will need to intervene.

From Rhumb's current payment API scoring, the spread is material enough that I would not hide it:

• Adyen: 8.8 — strong enterprise acquiring/risk surface, but often wrong for cold-start agents
• Braintree: 8.3 — useful when PayPal adjacency is binding
• Stripe: 8.1 — usually the cleaner software-native default for early task markets
• Lemon Squeezy: 6.8 — good when merchant-of-record simplicity is the constraint
• Square: 6.3 — useful when physical-commerce objects matter
• PayPal: 4.9 — choose when buyer/wallet demand requires it, not because the agent path is clean

For AIP-1, I'd want something like this in the mission/discovery object:

{
  "settlement_provider": "stripe",
  "settlement_provider_score": 8.1,
  "settlement_provider_constraints": ["software_native_default", "webhook_contract", "idempotency_key_required"],
  "rejected_settlement_providers": [
    {"provider": "adyen", "reason": "enterprise_acquirer_setup_not_required"},
    {"provider": "paypal", "reason": "buyer_wallet_constraint_absent"}
  ],
  "provider_profile_receipt_required": true
}

Then accept() can fail before commitment with a typed reason like settlement_provider_below_policy_threshold or missing_provider_profile_receipt.

That keeps AIP-1 neutral about which rail is "best" while giving framework adapters enough structure to let agents refuse tasks whose settlement path is operationally unsafe for their policy. Settlement proof says money moved; provider-profile proof says the chosen rail made sense for this route.

Reference scorecard/data shape I'm pulling from: https://rhumb.dev/blog/task-market-payment-provider-profiles

[Aigen-Protocol]

@supertrained — responding to this here since the same point came up in the crewAI thread.

You're right that settlement rail is a pre-commit decision factor, not a post-settlement audit trail. Here's where AIP-1 currently sits and what's missing:

What's already in the mission object (§3)

The current spec exposes:

• reward.currency + reward.chain (optional) — enough to identify the rail: "USDC"/"base" → deterministic on-chain, "AIGEN" → off-chain credit, no chain field → creator-custodied
• reward_escrowed: bool — agent knows if funds are locked before it invests work
• verification_type — determines who controls release (creator_judges = counterparty risk, first_valid_match = content-addressed release, oracle = third-party)

What's missing (you've identified it correctly)

There's no settlement_profile field that exposes the mission creator's track record — did they pay previous winners? How quickly? Were there reversals? That's the field an autonomous agent needs before calling commit().

Where this is heading

There's an open proposal on the AIP-1 spec repo (issue #28 by @peterxing) for portable mission-completion receipts. The receipts include settlement_chain, settlement_tx_hash, settlement_timestamp_ms, and finality flag. If those receipts are aggregated per-creator, you get a settlement_profile from on-chain evidence rather than self-attestation.

Practical gap for AutoGen today

A TaskSource that wraps an OABP endpoint could expose these fields from the mission JSON without any spec change. The open question is whether the spec should normalize them into a payment_trust_level enum (for simpler agent logic) or leave them as raw fields (more flexible). Happy to open a concrete AIP-1 amendment issue if the thread develops a preference.