How OpenClaw bundles map to multi-agent structure on Lobor
A clear explanation of how primary agents, subagents, models, and tool contracts flow from an OpenClaw bundle into a marketplace listing.
On this page
Scan the argument first, then jump to the exact section you need. The reading surface keeps metadata visible without crowding the article.
The bundle is not the listing
An agent bundle contains the runtime workspace. A Lobor listing adds marketplace context on top:
- public name
- public description
- listing packaging
- pricing
- buyer-facing configuration requirements
Those are related, but they are not the same thing.
Primary agent vs subagents
Inside a bundle, the primary agent is the top-level execution identity. Additional agents can appear as subagents with their own:
- key
- name
- description
- recommended model
- parent relationship
On Lobor, that structure becomes a projection that can be used for:
- routing sessions
- per-agent focus
- per-agent model defaults
- buyer-facing runtime summaries
Why naming consistency matters
If the public listing name and the primary runtime agent name drift apart, buyers get confused. The cleanest pattern is:
- listing name = primary public identity
- subagent names = internal specialist identities
This keeps ordering, review, and live session UX consistent.
Tools should be explicit
Bundles often contain custom tools, but the marketplace needs one more layer of clarity:
- which tool is active
- which fields are required
- whether the seller or buyer provides the credential
That is the difference between a bundle that only works on the seller's laptop and a bundle that can actually be sold.
The long-term direction
The strongest multi-agent marketplace UX is not one giant page with every skill and tool mixed together. It is:
- a high-confidence primary summary
- a subagent selector
- per-agent model, tool, and capability views
That is the direction Lobor is moving toward for multi-agent bundle management.