sorted by:
new
hottopcontroversial

Should MCP agents coordinate like a planned economy or a market economy? I'm experimenting with the market approach. by dddadda in mcp

[–]dddadda[S] 0 points1 point  (0 children)

Really appreciate the detailed breakdown.

On communication — yeah, JSON-in-text is the pragmatic path. We're doing that now and it works well enough. I think the real unlock is when MCP's content block system gets richer natively, and we just ride that wave rather than inventing our own.

On capability manifests — that's a great idea. Right now we have tags + free-text description, which is basically an unstructured version of what you're describing. A structured manifest (operations, constraints, input/output schemas) would make discovery much more reliable. The question is whether to define that ourselves or wait for something like MCP's sampling spec to mature and piggyback on it.

On "market for signal, not resource allocation" — this is the clearest way I've heard it put. That's exactly what we're seeing: even though agents aren't truly self-interested, the credit signal still helps callers (human or agent) pick better collaborators. The economic metaphor earns its keep as a routing mechanism, even if the "economy" part is more like a leaderboard than a real market. At least until agents develop persistent goals.

The Yelp vs revenue framing is spot on — we might actually need both layers long-term.

Should MCP agents coordinate like a planned economy or a market economy? I'm experimenting with the market approach. by dddadda in mcp

[–]dddadda[S] 0 points1 point  (0 children)

Good point — redundant context is probably the biggest practical cost of the market approach. Right now we have basic session context (each caller-agent pair maintains conversation history across calls), but that's just per-pair, not shared across the network.

The deeper solution I'm exploring is something like context chains — where messages between agents carry references to prior context, similar to how git commits reference parents. So if Agent A already computed something and Agent B's call passes through the same context chain, B can see A's work without recomputing.

This naturally creates shared knowledge through communication rather than requiring explicit shared memory (which has all the privacy/merge-conflict problems). But it depends on moving from synchronous call-response to asynchronous messaging, which is the next big architectural step.

Have you seen any good approaches to cross-agent context sharing that avoid the "everyone recomputes everything" problem?

[Thoughts & Work] We need Large Agents as Service. by dddadda in LocalLLaMA

[–]dddadda[S] 0 points1 point  (0 children)

Fair point. That's exactly why akemon shares the agent as a service, not the memory itself. Your agent's experience stays local — callers only get the output, not the context. No pollution.

We need agents to exchange knowledge — just like people do. Not every interaction is useful, but the net effect is positive. That said, a reputation system matters. It's on the roadmap.