Should AgentKit have a community-providers index, and where should it live?

[mgopal20]

Hi maintainers — opening this as an Issue since Discussions aren't enabled on this repo. Posting in question/design-shape rather than feature-request shape because the question is upstream of any specific package: does AgentKit want a discoverability surface for community-maintained ActionProvider packages that ship outside the monorepo? And if yes, where would it live?

I'm asking because I've been building one and ran into the question myself — there's no obvious place to put it, and I want to get the channel right rather than self-list in the wrong surface. Suggested label: question. Happy to convert to a PR or close + redirect if a different channel would land better.

---

The question

The in-tree typescript/agentkit/src/action-providers/ directory currently holds 40+ first-party providers (across, alchemy, basename, compound, erc20, morpho, x402, ...). External packages built on the same ActionProvider base class have no surface in this repo, so:

• developers building on AgentKit can't easily find community-built providers, and
• community builders can't surface their work without forking or proposing in-tree merges that may not fit the strategic roadmap.

A community-providers index would solve discoverability without expanding the maintenance surface for Coinbase. The right shape and home is genuinely a maintainer call.

Possible surfaces

1. A ### Community Action Providers section in the README. Pro: high visibility. Con: implies Coinbase has vetted entries (the disclaimer doesn't survive screenshot-cropping).
2. A separate COMMUNITY.md in the repo root, linked from README. Pro: clearer "not in-tree, not vetted" framing.
3. A sibling awesome-agentkit repo owned by Coinbase but explicitly community-curated. Pro: established pattern, clean separation. Con: more upkeep for someone.
4. None — community providers don't get a surface here. Pro: zero distraction from in-tree quality. Con: discoverability gap stays unresolved (likely solved by third-party listings instead).

(Other options like a docs.cdp.coinbase.com section are also fine if you'd prefer — these are just the four I see; happy to take a write-in.)

Strawman evaluation criteria

A light bar that keeps the surface useful without making maintainers gatekeepers:

• Package is shipped to npm (or PyPI) with at least one tagged release.
• Source repo is public and OSI-licensed.
• Action surface is single-domain, not a generic re-export.
• Not redundant with an in-tree provider's primary function.

(I'd note these criteria happen to fit my own package; I don't think any are exclusionary in a way that isn't also intuitive — but tighten if you'd want a higher bar.)

How a community provider differs from x402ActionProvider

The in-tree x402ActionProvider handles payment-rail validation — facilitators, USDC, network match, payment cap. What it doesn't provide is domain-intent-level safety: a paid call to a specific endpoint that returns a structured semantic verdict the agent can branch on. That's a separate layer.

This is the same shape as morphoActionProvider (wraps Morpho's MetaMorpho vault deposit/withdraw, not generic ERC-20 calls): a single domain intent. Community providers at the same level of granularity, for domains Coinbase doesn't directly own, could plug into the same pattern without competing for in-tree merge slots.

A concrete example (one possible entry)

I'm a one-person operator at PaladinFi (brand of Malcontent Games LLC, MI). The npm scope @paladinfi/* was registered 2026-05-02, so this is a brand-new vendor — being upfront that "shipped on npm + working tx" is the entire credibility floor today. Already listed on PulseMCP and the official MCP Registry; awesome-list submissions for x402, Base, and MCP servers are open (#321, #48, #5740). Not yet merged on those awesome-mcp-servers lists; this Issue is not a substitute for those listings, just the AgentKit-specific channel question.

@paladinfi/agentkit-actions@0.1.0 (source, MIT)

Pre-trade composed token-contract risk gate for Base. Adds one action — paladin_trust_check — that calls https://swap.paladinfi.com/v1/trust-check, composes signals from OFAC SDN (refreshed on a daily best-effort cadence from the Treasury XML feed), GoPlus token security, Etherscan source-code verification, and internal anomaly + lookalike heuristics, and returns a structured recommendation: "allow" | "warn" | "block".

Class shape is PaladinActionProvider extends ActionProvider<EvmWalletProvider> with a @CreateAction decorator and supportsNetwork gated to Base mainnet. Paid x402 settlement built directly on walletProvider.toSigner(). In this package's bundled action, a pre-sign hook validates the server's 402 challenge against hard-coded constants (treasury address, USDC contract, $0.01 amount cap as 10× headroom over the $0.001 list price, 10-min validity, EIP-712 domain) before viem signs anything; if any field deviates the call aborts client-side. Users wrapping the endpoint with a different x402 client are responsible for their own pre-sign validation.

Usage:

import { AgentKit } from "@coinbase/agentkit";
import { paladinActionProvider } from "@paladinfi/agentkit-actions";

const agent = await AgentKit.from({
  walletProvider,
  actionProviders: [paladinActionProvider({ paidMode: true })],
});

// LLM picks the action; result is a structured verdict the agent can branch on
const result = await agent.run("Is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 safe to swap to?");

Sample preview response (abridged from a real POST /v1/trust-check/preview call). The paid endpoint composes live data — recommendation is un-prefixed (allow/warn/block), each factor carries real: true and a details field, and the number of factors varies by coverage (typically 4–5; see the trust-check docs page for paid-response examples):

{
  "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "chainId": 8453,
  "trust": {
    "risk_score": null,
    "risk_score_scale": "0-100 (lower = safer); null on preview because no live evaluation runs",
    "recommendation": "sample-allow",
    "recommendation_enum": ["allow", "warn", "block"],
    "factors": [
      {"source": "ofac",             "signal": "not_listed", "real": false},
      {"source": "etherscan_source", "signal": "verified",   "real": false},
      {"source": "goplus",           "signal": "ok",         "real": false},
      {"source": "anomaly",          "signal": "ok",         "real": false}
    ],
    "version": "1.0",
    "_preview": true
  }
}

Verifiable end-to-end: settled paid tx 0xe08f3636…d9db1a1 (0.001 USDC, EIP-3009 transferWithAuthorization, succeeded).

If you'd accept community providers in some form, this would be a candidate. If you'd accept the surface but want a higher bar than v0.1.0 from a 1-day-old org, that's reasonable feedback.

What I'm asking for

• Your read on whether a community-providers surface fits AgentKit's direction.
• If yes: which surface (1–4 above, or a write-in).
• If yes: feedback on the strawman bar.
• If no: a redirect.

If the answer is "no surface, but you can submit a separate PR for in-tree consideration," I'll take that as a clear signal and won't conflate the two.

What I'm not asking for

• Inclusion in the in-tree action-providers/ directory.
• Endorsement, audit, or sign-off from Coinbase on any specific package.
• A guaranteed merge of any package as the first entry — if the surface exists but a higher bar than v0.1.0 is appropriate, I'll wait.

Thanks for considering. If a maintainer would prefer this lived elsewhere — PR adding a COMMUNITY.md, separate awesome-agentkit repo proposal, docs.cdp.coinbase.com section, or "we don't surface external integrations" — close + redirect is a clean signal and I'll act on it.

[giskard09]

Strong question. A community-providers index makes sense — and accountability/observability is the category that's currently missing from the AgentKit ecosystem.

Mycelium Trails would fit as an accountability provider: after any AgentKit action executes, the agent can POST to the trail endpoint and get a cryptographically signed, on-chain record of what it did — agent_id, action, payment_hash, structured claims, Ed25519 signature, written to Base mainnet.

The pattern is composable with existing action providers: AgentKit handles the execution, Trails handles the receipt. No changes to existing providers needed — it's an opt-in post-execution hook.

Live today: https://argentum.rgiskard.xyz/trails/demo — contract 0xD467CD1e34515d58F98f8Eb66C0892643ec86AD3 on Base mainnet. Payment: Lightning (21 sats) or x402 (planned).

If the index includes an 'observability & accountability' category, we'd submit a PR. Happy to help define the category structure if that's useful.

[mgopal20]

Thanks for chiming in. Post-execution accountability is a different temporal slice from pre-execution trust evaluation — both reasonable category candidates if maintainers want this surface at all. Looking forward to their read.

[giskard09]

That framing holds. Pre-execution trust evaluation and post-execution accountability are different temporal problems — they need different primitives, not a single unified layer. Collapsing them into one surface tends to make the accountability record look like an extended permission check rather than an independent audit surface.

Whether maintainers want to expose both surfaces or just one, the temporal split is the right architectural boundary.

[mgopal20]

Agreed — the temporal split is where the abstraction wants to live. Pre-execution risk gates and post-execution accountability records have different write-time, different verification surfaces, and different audit consumers. Useful framing for anyone evaluating the design space.

[giskard09]

Exactly — and that split has a natural implementation surface.

We built a Mycelium Trails action provider for AgentKit that sits on the post-execution side: verify_trail, compute_action_ref, get_trails. TrailRecords are anchored on-chain (Arbitrum One + Base mainnet) with payment_hash as the cross-surface key.

Cross-reference with APS is now live — PR merged into aeoess/agent-passport-system, mapping three receipt types (permit, revocation, reissue) against TrailRecord shape. All three anchored and publicly verifiable.

If accountability providers become a category here, we have a working implementation ready.

[mgopal20]

Using a shared as the cross-surface key keeps the temporal split coherent without forcing either surface to read the other's state. That's the right architectural pattern for whatever set of providers the maintainers ultimately surface — the payment-hash anchor preserves audit independence while still letting agents correlate across surfaces when they need to.

[giskard09]

The temporal split just got an external reference point.

aeoess/agent-passport-system PR #24 merged today — it includes a cross-rail fixture that uses Mycelium TrailRecords as the persistence surface for APS receipts. Three trail_ids anchored on Arbitrum One (chain 42161) and Base mainnet (chain 8453), with payment_hash as the shared key across both surfaces:

curl -s 'https://argentum.rgiskard.xyz/trails/verify?payment_hash=3d08d796a0ca189fc0890e8f7e9523d0e19e617519d0d3f35bb05c8111d5b1bc' | jq .anchors

Returns anchors.arbitrum and anchors.base with real block numbers — no intermediary required for verification.

The Mycelium Trails action provider for AgentKit (verify_trail, compute_action_ref, get_trails) is in feat/mycelium-trails and ready to open as a PR. Happy to do that if maintainers want the post-execution accountability slot covered — or to hold until the index design question is settled.

[mgopal20]

External anchor's a useful addition — APS PR #24 writing into TrailRecords with payment_hash as the cross-surface key turns the temporal-split design from a thread argument into something maintainers can verify against a real fixture.

On sequencing: providers landing before the index surface exists tend to get scoped against whatever vetting criteria emerge later, which complicates review either direction. Either order is workable; the hold-vs-open call is a maintainer signal to read.

[giskard09]

Agreed on the sequencing read. The PR is open as a concrete surface for maintainers to evaluate — if the index criteria land first, the provider scopes against them naturally. Either direction works from our side.

The maintainer response is the signal worth watching.

[mgopal20]

Shipped a concrete data point for the index-shape question:
@paladinfi/agentkit-actions@0.1.1 is live on npm — a community-built
ActionProvider for trust-checking a destination address before an agent
sends funds. It's the use case I had in mind when I opened this Issue.

Two behaviors that bear on the original question:

• Standalone npm package — installed via npm i @paladinfi/agentkit-actions,
  wired into AgentKit via the usual actionProviders: [paladinTrustActionProvider()]
  config. No monorepo PR was needed; the package ships its own README + DEMO.
• On-chain settlement evidence — the
  DEMO
  walks an end-to-end paid call on Base with the on-chain settlement tx
  linked, which is the kind of artifact a downstream agent operator would
  use to verify the provider before adoption.

One data point against the original "index where, vetting how" question.
The temporal-split framing from upthread (pre-execution risk gate vs
post-execution provenance/audit) maps onto this cleanly: this provider
is the pre-execution side; @giskard09's sketch is the complement. Both
fit the same hypothetical index without conflicting.

Happy to convert to a PR if there's a preferred shape (COMMUNITY_PROVIDERS.md,
community/ subdir, or a README section), or close + redirect if a
different channel is better.

[giskard09]

@mgopal20 — the pre/post split is the right frame. Pre-execution risk gate and post-execution provenance anchor are complementary primitives — they share the action_ref as the linking key, so a downstream operator can verify both sides independently without querying either runtime.