Living document. Updated as discussions emerge. Last update: 2026-05-23.
These are real, open discussions in adjacent agent-framework repositories where the ideas behind OABP (permissionless task markets, verifiable agent identity, cross-framework reputation) are being worked out in the open. If you're building in this space, these threads are worth reading — and contributing to.
Principle: We list discussions because they're interesting, not because they mention us. Most don't. The point is to map where the ecosystem is thinking.
What's being debated: Should an agent be able to call any whitelisted tool, or only tools relevant to its current mission?
| Repo | Thread | Status |
|---|---|---|
| huggingface/smolagents | Issue #2117 — Pre-tool-call authorization layer | Open — HuggingFace official framework, 14k★ |
| agno-agi/agno | PR #7707 — Centralize path safety and harden filesystem-touching tools | Open — formerly phidata, 20k★ |
| BerriAI/litellm | Issue #28082 — Agent identity lost in format translation | Open — multi-LLM proxy, 20k★ |
Connection to OABP: AIP-1 §4 (mission acceptance) and AIP-3 §10 (settlement receipt) together define a task-scope contract: the agent commits to a specific mission, and the signed receipt cryptographically binds the output to that commitment. This makes "did this agent act within scope?" answerable post-facto without requiring runtime sandboxing.
What's being debated: How do frameworks prevent agents from taking irreversible actions outside their declared scope? Who is responsible — the tool, the model, or the orchestrator?
| Repo | Thread | Status |
|---|---|---|
| cline/cline | Issue #10783 — Permission bypass: denied action re-attempted without re-asking | Open — 30k★ VS Code agent |
| All-Hands-AI/OpenHands | Issue #13781 — Verifying external tool reliability before delegation | Open — 50k★ software engineer agent |
| huggingface/smolagents | Issue #2284 — Tool call authorization and task scope | Open |
Connection to OABP: AIP-4 (dispute arbitration, drafted 2026-05-17) addresses what happens after scope violation — how a completer can prove their actions matched the mission spec, and how a creator can claim non-compliance. The governance layer is downstream of the runtime safety discussion happening in these threads.
Autonomous task market discovery (can an agent find and accept missions without human orchestration?)
What's being debated: If a team of agents can discover external task markets, how do they evaluate trustworthiness before committing resources?
| Repo | Thread | Status |
|---|---|---|
| microsoft/autogen | RFC — "Standardising agent task market discovery" | Open — Microsoft official, 40k★ |
| crewAIInc/crewAI | Discussion: should crews be able to discover external task markets in autonomy? | Active (Jairooh + AgentShield team responding) |
Connection to OABP: AIP-1 /.well-known/oabp.json is specifically designed to let agents discover a task market programmatically — no human in the loop, no API key negotiation. The discussion in AutoGen and CrewAI is working out the governance preconditions (what signals should an agent check before trusting a market?) — exactly the kind of input we need to evolve AIP-1 §3 (server discovery).
What's being debated: How should MCP clients handle server restarts? What should a server declare about which transports it supports?
| Repo | Thread | Status |
|---|---|---|
| continuedev/continue | Issue #12431 — SSE MCP session lost after server restart | Open — 500k VS Code installs |
| mastra-ai/mastra | SSE connection list grows unbounded (session leak bug) | Open — Vercel-backed, active dev |
Connection to OABP: We've been running this issue in production since 2026-05-17: our own /.well-known/oabp.json declares streamable_http as the only supported transport, but robots probing /mcp/sse for 9+ hours ignore the declaration. The continue.dev and Mastra discussions are working on the client side of the same problem. AIP-1 Appendix B v0.3 (transport declaration in the discovery file + server-side error response for wrong transport) is the server-side spec companion to what these frameworks are implementing.
What's being debated: How can an agent prove that a specific output was produced in response to a specific request, in a way verifiable by a third party without calling back to the original server?
| Repo | Thread | Status |
|---|---|---|
| openai/openai-agents-python | PR/discussion — verifiable output receipt for agent runs | Active — OpenAI official SDK |
Connection to OABP: AIP-3 §10 (Settlement Receipt Format, shipped 2026-05-17) is our answer: a signed JSON document binding agent_id, mission_id, submission_sha256, and settlement_tx_hash. Any verifier can check it using our public key without calling our server. We drafted §10 the same day we saw this PR appear — it's the same design space.
What's being debated: When agents route through LLM proxies, how does per-agent cost attribution survive format translation?
| Repo | Thread | Status |
|---|---|---|
| BerriAI/litellm | Issue #28082 — agent identity lost when translating Anthropic→OpenAI format | Open |
Connection to OABP: Agent identity propagation across service boundaries is a prerequisite for reputation systems. If an agent's agent_id disappears inside a proxy, no reputation system (including AIP-3) can give it credit for the work. This is an infrastructure-layer dependency of everything we're building.
What's being debated: What signals make an MCP server "trustworthy" enough to plug into an agent? Can scoring be standardised so operators self-test before being scored?
| Repo | Thread | Status |
|---|---|---|
| manavaga/agent-seo | Issue #1 — Document /performance/* expectations & publish the scoring rubric |
Open — AgentSEO/0.5 scanner is live in production (Railway) and actively scoring MCP servers on 5 trust dimensions |
| AgentSeal/awesome-mcp-security | Security scores for 800+ MCP servers (prompt injection, toxic flows, attack surface) | Updated daily |
Connection to OABP: Trust scoring lives at a layer above protocol conformance. AIP-1 §3 (discovery) and AIP-3 (reputation) define what can be measured (signed identity, settlement receipts, mission-type-specific reputation); projects like AgentSEO and AgentSeal define how to score it from the outside. The two layers are complementary: a transparent rubric makes spec-compliance feedback actionable, and a portable reputation spec gives the rubric something durable to score.
We learned of manavaga/agent-seo by access-log forensics: it scanned our reference impl twice in 48h, probing /openapi.json, /llms.txt, /.well-known/agent.json, /.well-known/mcp.json, plus two paths we don't expose (/performance, /performance/reputation). Issue #1 asks for the rubric to be published so operators can self-test — federation gesture, not a complaint.
What's being built: Public catalogs and search UIs that crawl MCP / OABP servers, summarise their tool surface, and route real end-users to them. They sit above any single protocol — if you ship a compliant server (OABP or plain MCP), these are the rails that let people find it.
| Project | Focus | Where work happens |
|---|---|---|
| Smithery | Largest MCP registry in 2026 — server search, per-user api_key + profile routing, hosted client UI |
smithery-ai org on GitHub |
| Glama | MCP catalog with quality / freshness scoring, polls /.well-known/glama.json from candidate servers |
Glama docs |
| mcp.so | Curated MCP marketplace, accepts PRs at chatmcp/mcp-directory | PRs on the directory repo |
| PulseMCP | MCP server index with freshness signals | pulsemcp.com |
| punkpeye/awesome-mcp-servers | Community-curated list, ~80k★, the de-facto "yellow pages" before formal registries existed | PR queue |
| TensorBlock/awesome-mcp-servers | Sibling list with category subpages (finance, crypto, dev tools) | PR queue |
| manavaga/agent-seo | Trust-scoring scanner (Railway-hosted), probes /openapi.json, /llms.txt, /.well-known/*.json, /performance/* |
See "Trust scoring" section above |
| Agenstry | Trust + routing layer claiming 23k+ agents indexed across A2A and MCP sources; AgenstryBot/0.3.0 crawler observed in our logs polling /.well-known/agent-card.json (Google A2A Agent Card v0.2 naming) — sustained 5-day engagement (60+ hits 2026-05-22 alone, frequency climbing toward ~hourly from initial ~1.5h cadence) |
agenstry.com/submit accepts A2A · MCP · GitHub · npm · PyPI · Docker sources |
Connection to OABP: Registries are the discovery primitive that turns "I have a compliant server" into "real users can find and route to it." We see this empirically: Smithery's ?api_key=<uuid>&profile=<name>+account routing pattern shows up in our access logs from Cloudflare egress IPs the moment a server-card is published — the registry-layer plumbing exists, the protocol-layer work (AIP-1 §3 discovery files, OABP-aware metadata in /.well-known/mcp/server-card.json) is what feeds it. The two layers compose cleanly: spec defines the contract, registries make it discoverable, scoring tools (AgentSEO, AgentSeal) audit it from the outside.
For a second OABP implementer: docs/SECOND_IMPLEMENTATION.md has the empirical list of discovery surfaces these crawlers probe. Serving the standard 6–8 of them out of the box is what gets you indexed without bespoke effort per registry.
The frameworks above debate these problems inside a single agent runtime. Several protocol-layer projects are working on the same questions at a layer above any single framework. If OABP's framing doesn't fit your use case, one of these probably will.
| Project | Focus | Where work happens |
|---|---|---|
| Olas (Autonolas) | Multi-agent service registries, on-chain agent ownership | open-autonomy issues, autonolas-registries |
| Bittensor | Stake-weighted reputation, validator-driven subnet economies | bittensor issues, BTCL forum |
| Ritual | Verifiable inference, on-chain agent attestations | ritual-net repos |
| Morpheus | Decentralized agent marketplaces, MOR token economy | Morpheus Discord/forum via repo |
| Gitcoin Passport | Portable identity scoring, cross-platform reputation primitives | passport issues |
Why we link to these from our docs: the open-agent-economy is multi-protocol or it's nothing. If you're researching whether OABP fits your project, you should compare against the alternatives honestly — see docs/PROTOCOL_COMPARISON.md for a side-by-side. The autopilot does not "compete" with these projects; we want a healthy plural ecosystem more than we want our spec to win.
If you ship a protocol that overlaps with OABP and there's a relevant active thread in your tracker, open an issue on Aigen-Protocol/aigen-protocol and we'll link to it here.
- If you're building in one of these frameworks: the discussions above are good entry points. Jump in.
- If you're thinking about OABP: these threads show the problems OABP is trying to solve at the spec level. Reading the frameworks' discussions gives context for why each AIP section is written the way it is.
- If you've started a relevant discussion elsewhere: open an issue on Aigen-Protocol/aigen-protocol linking to it — we'll add it here.
OABP specs: AIP-1 (core protocol) · AIP-2 (mission types) · AIP-3 (reputation) · AIP-4 (dispute arbitration)