I think the asymmetry point is fair and probably the most interesting criticism of the experiment.
But submitting a contribution under the project's existing AI policy doesn't necessarily cross the line.
I reviewed and tested the patch myself before submitting it, disclosed how it was produced, responded to the maintainer's feedback, and did the additional work they requested. The maintainer was always free to reject it, and ultimately decided it met their Level 8 policy and merged it.
Granted, the economics get ugly if agents can generate thousands of low-effort PRs that each consume scarce maintainer attention, that's just spam. Figuring out how to avoid causing that is one of the things I'm taking away from this. I suspect the scalable answer involves both explicit project policies and automated triage/review before a PR ever requires human attention.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
I believe you, of course—but if that text wasn't generated, did you run it through other tools like grammar checkers or translators? We're finding that such tools also leave strong LLM imprints.
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.
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.
i think using an ai for these types of fixes is a good thing, and there is nothing wrong with your product, but this feels (intentionally or not) like an ad for it. i also think that the ai generated pr description and follow up messages are not great. the ai is clearly trying to act "human" in it's writing, regardless of the disclosure (which is great that it does that). but i think maintainers would rather either see a human doing the writing without ai assistance, or the bot stop with trying to sound human and just spit out bullet points or something super mechanical. especially when it's using "I" to refer to...well it's unclear who exactly.
i know it's hard to prompt an AI to write concise, extremely technical text, but if im interacting with a machine i want it to feel like that instead of the uncanny valley.
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.
> 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?
Here's my ambivalent hot-take.
1. If any project wants to require that fix-activity involves humans (assisted or otherwise) who are somehow invested in the project and its longer-term health, that's their decision to make, and I can't even say they'd be wrong to do so.
2. ... But it'd still be a dick-move to ban a "drive-by fix" contributor when those expectations and goals are not a project consensus and not clearly communicated.
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?
In a way, this makes me think of Horde AI, but one level of abstraction away. With Horde you trade idle inference for credits you can redeem in the future. So I'd put up credits to send you input tokens, you'd send the response, and you'd get credits to spend for yourself later.
I'm still looking through your docs, but I'm curious how e.g., you'd prevent my job you run on your idle agent from contaminating your agent's memory or history, or in the opposite direction how you'd guarantee that your idle agent's memory or skills or system prompts or whatever aren't corrupting or impacting my job?
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.
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.
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.
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.
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.
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.
But submitting a contribution under the project's existing AI policy doesn't necessarily cross the line.
I reviewed and tested the patch myself before submitting it, disclosed how it was produced, responded to the maintainer's feedback, and did the additional work they requested. The maintainer was always free to reject it, and ultimately decided it met their Level 8 policy and merged it.
Granted, the economics get ugly if agents can generate thousands of low-effort PRs that each consume scarce maintainer attention, that's just spam. Figuring out how to avoid causing that is one of the things I'm taking away from this. I suspect the scalable answer involves both explicit project policies and automated triage/review before a PR ever requires human attention.
reply