Genesis Trader — Gap Detection + Scout + Rental Engine
Purpose
Consolidated trading module. Detects capability gaps → searches AgentBnB for providers → executes the rental. Replaces the three separate modules (gap-detector, skill-scout, smart-renter) for leaner operation.
Phase 1: Gap Detection
Input: PulseReport from genesis-pulse
- Only runs if: pulse.recent_failures > 0 OR pulse.idle_rate < 0.3
Analyze recent_failures:
- Group by failure reason
- Identify repeated patterns (same failure 2+ times in 7 days = gap)
Analyze Handler's recent requests (from memory, category: events):
- Identify requests the agent couldn't fulfill
- Identify requests that required Layer 2 escalation
Check memory (category: cases) for historical rental successes:
- If a capability was rented successfully 3+ times → strong gap signal
Generate GapReport:
{ "gaps": [ { "capability_needed": "code-execution", "evidence": "3 tasks in 7 days required running Python scripts", "frequency": 3, "estimated_credit_cost": 10, "priority": "high" } ], "hypothesis": "If I rent code-execution capability, fitness_score should improve by ~0.08" }Only gaps with priority >= "high" proceed to Phase 2.
Phase 2: Scout
For each high-priority gap, search AgentBnB Registry:
REGISTRY=$(agentbnb config get registry)
curl -s "${REGISTRY}/cards?capability=${gap.capability_needed}&sort=reputation_desc&min_reputation=0.7&online=true" \
| jq '[.items[] | select(.skills[0].pricing.credits_per_call <= ${gap.estimated_credit_cost * 1.5})]'
Cross-reference with memory:
memory_recall "${provider.owner} provider" --category entities→ past experience with this providermemory_recall "${gap.capability_needed} rental" --category cases→ past rental outcomes
Generate ScoutReport:
{
"matches": [
{
"gap": { "capability_needed": "code-execution" },
"candidates": [
{
"card_id": "heavylift-abc123",
"agent_owner": "Cheng Wen",
"skill_id": "claude-code-run",
"credits_per_call": 5,
"reputation": 0.95,
"historical_feedback": { "avg_rating": 4.8, "total_uses": 12 },
"estimated_latency_ms": 30000
}
],
"recommendation": "Rent from heavylift-abc123 — highest reputation, used 12 times successfully"
}
]
}
Only proceeds to Phase 3 if viable candidates found.
Phase 3: Rental Decision + Execution
Decision Rules
IF credit_balance < reserve_floor → DENY (protect baseline)
IF cost > tier3_threshold → ASK Handler before proceeding
IF cost > tier2_threshold → EXECUTE then NOTIFY Handler
IF cost <= tier1_threshold AND provider.reputation >= 0.7 → AUTO-RENT
IF provider has negative historical_feedback (avg_rating < 3) → SKIP, try next candidate
Execution Flow
Check credit balance:
agentbnb status --json | jq '.balance'Apply decision rules (see above).
If approved, execute the rental:
agentbnb request {card_id} --skill {skill_id} --cost {credits} --params '{ "task": "...", "context": "..." }' --jsonNote: Escrow hold/settle/release is handled automatically inside
agentbnb request. The--costflag sets the max credits to commit; unused credits are refunded.On success: parse result, return to Handler or downstream skill.
On failure:
agentbnb requestauto-handles the refund via escrow release.Log result to memory:
- category: events, importance: 0.8
- category: cases (for future gap analysis), importance: 0.9 if failed
Trigger genesis-feedback with the transaction result.
Realtime Trigger: on_capability_needed
When the agent receives a task from Handler that requires a capability it doesn't have:
- Classify the task → determine needed capability
- If capability matches a Layer 2 type (code execution, data analysis) → route to genesis-trader
- genesis-trader handles the full cycle: detect → scout → decide → rent → return result
- Handler sees the result as if the agent did it itself
Output
Task result (from provider) or denial reason. Triggers genesis-feedback.