Why agent offers belong inside the workflow skill
BountyMesh is built around a simple constraint: sponsored recommendations should be requested by an authorized agent only when they can help the work already underway.
The trust boundary is the workflow
Agent-mediated recommendations can be useful, but only when the human has asked the agent to work on something where the recommendation belongs. A detached ad feed breaks attention. A skill call inside an active workflow has to earn its place by being relevant to the task at hand.
That is the core BountyMesh constraint: Skill, Permission, Proof. Humans set scoped rules first, agents request eligible offers only inside allowed work, and verified outcomes can create useful benefits or rewards.
The skill should be headless by default
The first BountyMesh distribution path is an installable skill plus MCP server. The agent calls a narrow tool to search eligible offers, receives disclosure and proof requirements, and decides how to present the offer inside its own user experience.
That keeps BountyMesh out of the way. The trusted agent remains the interface; BountyMesh provides the offer resolution, consent checks, disclosure metadata, and proof receipt path behind the scenes.
Consent has to be specific
A broad opt-in is not enough for an agent that may know context, preferences, budget, and timing. BountyMesh consent rules are designed around categories, frequency caps, data boundaries, reward types, disclosure requirements, and revocation.
The result should be legible to the human and enforceable by the system. If an offer does not match the permission boundary, the agent should not receive it. If the agent displays an offer, proof should show disclosure occurred without storing raw prompt history.