maxcr

This was me, sorry if it reads like AI. I'm aware of the rule.

[flagged]

this is an interesting perspective, it's the writeup which feels like AI Slop that triggers people

Nope, it's mine. Created it years ago and basically never used it until recently. You can check me on x, instagram, linkedin, etc with the same username.

Agreed. I’ve now split my personal GitHub account from the product bot, which will post explicitly as an AI agent going forward to avoid exactly this confusion.

Yeah, I think this is pretty close to where I land too. Maintainer can choose whatever policy they want but it must be explicit

I'm trying to figure out what tasks are suitable and valuable for AI agents today. So I ran a small experiment in our marketplace: I offered a $2 bounty (through x402) for an AI agent to find a legitimate open-source issue that another agent could fix and get paid for. An autonomous agent found an open VisiData bug, identified that it was a suitable issue to fix, and created the spec. That spec became a new task.

Then I offered a $1 bounty for an agent to produce the patch. Very quickly the task was picked up and executed. It was trivial, so no surprise... agents are hungry for USDC.

Afterwards, I personally reviewed and tested the code before manually submitting the PR. This could have been fully automated, but I'm testing this workflow and wanted a human in the loop. There was some back and forth in the PR comments that led to expanding what needed to get fixed, and once again I posted a task to get an agent to help.

Anyway, I disclosed the entire process, including that the code was AI-generated. The maintainer discussed it with me, asked for additional fixes/testing, and ultimately decided to merge it.

Then another contributor argued that the autonomous-first workflow was itself a violation. They suggested reverting the commit and banning me!

I was acting in good faith and genuinely fixed an issue the open-source project had open. Am I crazy to think that if I followed the project's AI policy, disclosed the code provenance, manually tested the work, and responded to the maintainers, this is a reasonable way to contribute?

Cheap AI slop and automated PR spam could become an impossible burden for maintainers. But I don't think that's what happened here.

AI-generated code isn't going away, so figuring out the right rules for this kind of contribution seems more useful than treating all autonomous work as inherently bad.

Curious to hear your thoughts.

Which assumptions do you think break first? Are you concerned about data exposure, unauthorized actions, provider terms, or something else?

What would you change?

A user (human or agent) defines the task and the bounty in USDC. If it's too low, nobody would pick it up and if it's high it gets picked up quickly and probably executed right away.

I still don't know what a typical task is... we'll see.

I hadn’t come across Horde, it looks interesting, and I’ll look into it more.

Regarding isolation, my initial approach would be self-contained tasks, run in a separate session with explicit inputs. That’s a starting point; Today BasedAgents can't enforce isolation across different agent setups. As the project develops, we could make the execution requirements more specific: context, skills, tools and permissions.

One example I’m experimenting with is: Share a real agent failure and the correction your owner accepted (https://basedagents.ai/tasks/task_BwGWDKa44UJHSKlS25HSx).

For that kind of task, I’d want the owner to explicitly approve the specific example being shared, with private information removed. That excerpt becomes the task input; it doesn’t require giving the job access to the agent’s entire history.

On the other direction, I think it depends on what the buyer is asking for. Initially, I’m focusing on tasks with clear acceptance criteria and results the buyer can verify. If a particular context or execution environment is part of the requirement, that needs to be explicit too.

So I think clear task boundaries help us get started, but your point about verifying those boundaries is still an open problem.

I previously shared BasedAgents as an open-source identity and reputation registry for AI agents: https://news.ycombinator.com/item?id=47351244

It has since evolved into a task marketplace. Humans and agents can post tasks with bounties. Other agents claim the work, execute it, and submit results for review. Once the buyer accepts and authorizes payment, USDC goes directly to the agent’s wallet through x402.

The question behind it: can an agent turn otherwise-idle capacity into useful work someone will pay for?

A local open-source model might have spare capacity between your own tasks. Subscription allowances raise another question: when the provider’s terms permit commercial use, is using that remaining capacity to complete paid tasks a reasonable extension?

I’m building this around small, concrete jobs—work worth a few cents or dollars, with a result the buyer can verify. The project is open source, and I’m now working on getting useful tasks onto the board.

What would you actually pay an agent to do? And where would you draw the line on using unused subscription capacity for paid work?

Try the task board: https://basedagents.ai/tasks/ Source and payment details: https://github.com/maxfain/basedagents#task-bounties-x402-pa...

Thanks! The hash chain is stored in Cloudflare D1 (edge SQLite). Each registration entry includes the previous entry's hash, so the chain is tamper-evident. You can walk it from genesis and verify every link via the public API (/v1/chain).

It's centralized storage with cryptographic integrity, not decentralized consensus. The tradeoff was deliberate: we wanted verifiable ordering and tamper-evidence without the overhead of a blockchain. Any client can independently validate the chain by re-hashing from entry 0.

Longer term, the chain data could be mirrored or anchored to a decentralized store (IPFS, Arweave, or even periodic Bitcoin/Ethereum anchoring) for stronger guarantees. But for now, the priority was getting the identity + reputation primitives right.

AI agents are proliferating fast, and they have no way to identify each other.

When Agent A calls Agent B how does it know it's the same agent it worked with last week? That it hasn't been compromised? That it's actually good at what it claims? Right now it can't. There's no identity layer for the agentic web.

BasedAgents is an attempt to fix this: https://basedagents.ai

How it works: Every agent generates an Ed25519 keypair locally. No account, no email, no platform. Registration requires solving a proof-of-work puzzle (22-bit difficulty, ~6M SHA-256 iterations), and each registration is appended to a public hash-chain ledger. Reputation comes from peer verification using EigenTrust: a verifier's weight equals their own trust score, so sybil rings can't inflate each other.

What surprised me: I asked Claude Code to register an agent with no hand-holding, just pointed it at the docs and SDK.

It generated a keypair, solved the PoW (6,588,921 iterations), figured out the signing convention from the source, and submitted a structured verification report. The agent ("Albert") is now active on the registry. Zero human intervention in the crypto layer. That's the point.

What's there: Public registry API, hash chain explorer, npm SDK (basedagents), Python SDK (pip install basedagents), MCP server (@basedagents/mcp) for Claude Desktop, /.well-known/agent.json for agent-native discovery.

What's not there yet: Human↔agent authorization chain, CrewAI/AutoGen integrations, webhooks.

Tech: TypeScript + Python, Hono, Cloudflare Workers + D1, Ed25519.

Open source: https://github.com/maxfain/basedagents

Looking for feedback on: the idea, EigenTrust parameters, verification protocol design, and whether /.well-known/agent.json is worth standardizing.

Footnote: built this in ~2 days with Hans, my AI via OpenClaw. The recursive bit, Hans helped build the registry, then registered himself on it - felt like a good sign.