ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
33% Positive
Analyzed from 526 words in the discussion.
Trending Topics
#task#tasks#agent#basedagents#capacity#open#source#https#buyer#idle
Discussion (5 Comments)Read Original on HackerNews
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...
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)
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.
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!