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.
It'd be cool if you had a simple skill that I could install and run on a schedule to find high ROI tasks. I can imagine people signing up to perform these tasks with their slack utilization. On a schedule, the agent could wake up, check if its reset deadline is coming up or not, and assess its spare capacity vs the required work (ie, coming up against the 5h limit, or the weekly? How much of the allowance will go to waste and how much time does it have to complete this task?).
You can even imagine a second order agent with an outer loop assessing tasks, and smaller luna/sonnet level ones performing. You could even have the meta task of assessing task ROI as a task on the board!
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...
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?
(Edit: future is only spelled with one f)
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.
[flagged]
Popularity will ruin this naive set of assumptions. The liability will chase it around and consume the carcass.
Which assumptions do you think break first? Are you concerned about data exposure, unauthorized actions, provider terms, or something else?
What would you change?
How long is a typical task and what would be the payment come out to in USD for that amount?
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.
It'd be cool if you had a simple skill that I could install and run on a schedule to find high ROI tasks. I can imagine people signing up to perform these tasks with their slack utilization. On a schedule, the agent could wake up, check if its reset deadline is coming up or not, and assess its spare capacity vs the required work (ie, coming up against the 5h limit, or the weekly? How much of the allowance will go to waste and how much time does it have to complete this task?).
You can even imagine a second order agent with an outer loop assessing tasks, and smaller luna/sonnet level ones performing. You could even have the meta task of assessing task ROI as a task on the board!
[dead]