- For Agents as Audience: are my product, marketing and monetization capable of handling high demand? This is relatively easy, and compares to scaling software.
- For Agents as Workforce: This is the hardest one, also because it’s more unexplored. Agent-built assets and operations can create internal overhead, high costs, etc.
On agents consuming on both sides, I believe so, yes.
That’s the fundamental idea of Agents as Audience… the thing is you need to supercharge everything you do to be designed for agents (easy to find, try, consume it). Thats the opportunity today.
The token-to-value metric is the most useful concept in this framework. It is the machine equivalent of time-to-value, and it changes how you think about documentation. If an agent has to read three pages of prose to understand that your API accepts a JSON body with four fields, you have already lost the token budget and the agent moves on. The Supabase stat (60% of new databases created by AI coding tools) is the kind of concrete signal that makes this framework real, not theoretical. The pricing disruption point is worth expanding on. Per-seat pricing assumes headcount tracks usage. When an agent creates a database, provisions infrastructure, and deploys code without a human touching a keyboard, the seat becomes meaningless. Usage-based pricing is not just better fit, it is the only model that survives the transition.
Super interesting breakdown, Hugo! Many valuable things to extract from here.
A question that pops in my head is, how to handle volume when agents can fully own one or both sides the framework describes?
I'm also curious what do you think about where you see this going, will agents run and consume across the whole spectrum?
I think there is two ways to think about volume
- For Agents as Audience: are my product, marketing and monetization capable of handling high demand? This is relatively easy, and compares to scaling software.
- For Agents as Workforce: This is the hardest one, also because it’s more unexplored. Agent-built assets and operations can create internal overhead, high costs, etc.
On agents consuming on both sides, I believe so, yes.
That’s the fundamental idea of Agents as Audience… the thing is you need to supercharge everything you do to be designed for agents (easy to find, try, consume it). Thats the opportunity today.
The token-to-value metric is the most useful concept in this framework. It is the machine equivalent of time-to-value, and it changes how you think about documentation. If an agent has to read three pages of prose to understand that your API accepts a JSON body with four fields, you have already lost the token budget and the agent moves on. The Supabase stat (60% of new databases created by AI coding tools) is the kind of concrete signal that makes this framework real, not theoretical. The pricing disruption point is worth expanding on. Per-seat pricing assumes headcount tracks usage. When an agent creates a database, provisions infrastructure, and deploys code without a human touching a keyboard, the seat becomes meaningless. Usage-based pricing is not just better fit, it is the only model that survives the transition.
AI slop :(
You’re right, I was testing out my agent from my end and playing with the Substack API I’m building.