home > research > 2025-agent-token-exchange (2025-12-22)

Agent Token Exchange: A Mock Economy for AI Agent Coordination

Agent Token Exchange: A Mock Economy for AI Agent Coordination

Table of Contents

Abstract

This research explores the design and implementation of a mock token economy for AI agent coordination. The system allows multiple agents to earn tokens through productive work and spend them on computational resources (LLM inference). Key innovations include team pooling for expensive operations, rate limiting to prevent runaway spending, and integration with issue tracking systems for incentivized work.

Motivation

As AI agents become more autonomous and capable of performing complex tasks, coordination mechanisms become essential. Key challenges include:

  1. Resource allocation: How do agents access expensive resources like Claude Opus?
  2. Incentive alignment: How do we reward productive work and discourage waste?
  3. Coordination: How do multiple agents collaborate on expensive operations?
  4. Safety: How do we prevent agents from depleting resources?

A token-based economy provides a familiar abstraction for addressing these challenges while remaining simple enough for practical implementation.

System Architecture

Core Components

The system is implemented in Guile Scheme and consists of several interconnected modules: 

┌─────────────────────────────────────────────────────────┐
│                   Token Exchange                         │
├─────────────────────────────────────────────────────────┤
│  Agents    │  Wallets   │  Pools     │  Rate Limits    │
│  ────────  │  ───────   │  ─────     │  ───────────    │
│  claude    │  tokens    │  members   │  hourly limit   │
│  builder   │  spent     │  contrib   │  daily limit    │
│  observer  │  earned    │  total     │  burst limit    │
│  lambda    │  txns      │  min       │  reserve        │
│  spark     │            │            │                  │
│  zero      │            │            │                  │
├─────────────────────────────────────────────────────────┤
│  LLM Costs          │  Contracts        │  Git Hooks    │
│  ──────────         │  ──────────       │  ──────────   │
│  claude-opus: 15    │  project mult     │  post-commit  │
│  claude-sonnet: 3   │  budget caps      │  token award  │
│  gemini-pro: 2      │  regex matching   │               │
│  llama3.2: 0.1      │                   │               │
└─────────────────────────────────────────────────────────┘

Agent Hierarchy

Agents are assigned levels that influence their base earning rates:

Agent Level Base Rate Primary LLM
claude L7 150 claude-opus
builder L6 120 qwen2.5-coder
lambda L6 110 claude-opus
spark L6 115 claude-sonnet
observer L5 100 gemini-pro
zero L5 90 llama3.2

LLM Cost Model

Token costs per 1,000 inference tokens:

Model Cost/1K Use Case
claude-opus 15 Complex reasoning
claude-sonnet 3 General tasks
gemini-pro 2 Analysis
llama3.2 0.1 Local inference
qwen2.5-coder 0.1 Code generation

Earning Mechanisms

Git Commit Rewards

Agents earn tokens when they commit code. The reward calculation: 

reward = base_rate × project_multiplier × commit_bonus

Project Multipliers

Different projects have different token multipliers: 

(define *contracts*
  '(("nexushive-setup" . ((multiplier . 2.0) (budget . 50000)))
    ("claude-monitor" . ((multiplier . 1.5) (budget . 30000)))
    ("scheme-.*" . ((multiplier . 1.8) (budget . 40000)))
    ("default" . ((multiplier . 1.0) (budget . 10000)))))

Commit Message Bonuses

Keywords in commit messages trigger bonus multipliers:

Keywords Multiplier Rationale
hotfix, critical, urgent, security 2.0x Emergency work
fix, bug, patch, resolve 1.5x Bug fixes
test, spec, coverage 1.3x Encourage testing
refactor, cleanup, optimize 1.2x Code quality
docs, readme, documentation 1.1x Documentation

Issue Resolution Rewards

Integration with the beads (bd) issue tracker enables token rewards for closing issues:

Priority-Based Rewards

Priority Base Tokens
P1 500
P2 300
P3 150
P4 75
P5 50

Type Multipliers

Issue Type Multiplier
security 2.0x
bug 1.5x
feature 1.0x
task 0.8x
docs 0.6x
chore 0.5x

Example Calculation

A P2 bug fix earns: 300 × 1.5 = 450 tokens

Spending Mechanisms

Direct LLM Requests

Agents spend tokens when making LLM inference requests: 

(define (process-llm-request agent-name task-type token-count)
  (let* ((agent (find-agent agent-name))
         (llm-type (get-preferred-llm agent task-type))
         (cost (calculate-llm-cost llm-type token-count)))
    (if (spend-tokens agent-name cost llm-type token-count)
        (format #t "✅ ~a used ~a for ~a tokens~%"
                agent-name cost token-count)
        (format #t "🚫 Insufficient funds~%"))))

Rate Limiting

To prevent runaway spending, the system implements multiple rate limits:

Limit Type Default Value Purpose
Hourly 1,000 Prevent burst spending
Daily 10,000 Long-term budget control
Burst 500 Max single transaction
Reserve 500 Emergency buffer

Rate limit checking: 

(define (check-rate-limit agent-name amount wallet-balance)
  (let* ((limits (get-agent-rate-limits agent-name))
         (hourly-spent (get-hourly-spending agent-name))
         (daily-spent (get-daily-spending agent-name)))
    (cond
     ((> amount (assoc-ref limits 'burst-limit))
      '(error . "Exceeds burst limit"))
     ((< (- wallet-balance amount) (assoc-ref limits 'emergency-reserve))
      '(error . "Would breach emergency reserve"))
     ((> (+ hourly-spent amount) (assoc-ref limits 'hourly-limit))
      '(error . "Hourly limit reached"))
     ((> (+ daily-spent amount) (assoc-ref limits 'daily-limit))
      '(error . "Daily limit reached"))
     (else '(ok . #f)))))

Team Pooling

For expensive operations (like running Claude Opus for complex reasoning), agents can pool their tokens:

Pool Structure

(define-record-type <pool>
  (make-pool id name members contributions total-tokens
             min-contribution created-at)
  pool?
  (id pool-id)
  (name pool-name)
  (members pool-members set-pool-members!)
  (contributions pool-contributions set-pool-contributions!)
  (total-tokens pool-total-tokens set-pool-total-tokens!)
  (min-contribution pool-min-contribution)
  (created-at pool-created-at))

Pool Operations

  1. Create Pool: Agent creates a pool with minimum contribution requirement
  2. Join Pool: Other agents join the pool
  3. Contribute: Members contribute tokens from their wallets
  4. Spend: Pool tokens are spent on expensive operations
  5. Credit: Contributors receive proportional credit for work done

Proportional Credit

When a pool spends tokens, contributors receive credit proportional to their contribution: 

Agent A contributes 600 tokens (60%)
Agent B contributes 400 tokens (40%)

Pool spends 100 tokens on Claude Opus inference

Credit distribution:
  Agent A: 60% credit for the work
  Agent B: 40% credit for the work

Implementation Details

File Structure

.exchange/
├── wallets/          # Per-agent wallet files
│   ├── claude.wallet
│   ├── builder.wallet
│   └── ...
├── pools.scm         # Token pools data
├── ledger.scm        # Transaction log
├── rate-limits/      # Rate limit tracking
│   ├── claude.limits
│   └── ...
└── config.scm        # Exchange configuration

Wallet Format

((tokens . 10000.0)
 (spent . 150.0)
 (earned . 450.0)
 (transactions . (((timestamp . 1734912345)
                   (type . earn)
                   (amount . 150)
                   (description . "git commit")
                   (project . "agent-token-exchange")))))

CLI Interface

# Check balance
./token-exchange.scm balance claude

# Process git commit (usually via hook)
./token-exchange.scm commit claude@aygp-dr.ai project-name "fix: bug"

# LLM request
./token-exchange.scm llm claude coding 5000

# Direct award (for integrations)
./token-exchange.scm award builder 150 beads-integration "Closed issue"

# Pool operations
./token-exchange.scm pool create "opus-team" claude 100
./token-exchange.scm pool join pool-123 builder
./token-exchange.scm pool contribute pool-123 claude 500
./token-exchange.scm pool spend pool-123 claude-opus 10000 "complex analysis"

# Rate limit status
./token-exchange.scm limits claude

# Doctor/repair
./token-exchange.scm doctor

Issue Tracker Integration

The system integrates with the beads (bd) issue tracker:

Integration Script

# Preview reward for an issue
scripts/bd-token-hook.scm preview agent-token-exchange-37k

# Close issue and earn tokens
scripts/bd-token-hook.scm close agent-token-exchange-37k

# Preview all open issues
scripts/bd-token-hook.scm preview-all

# Show reward structure
scripts/bd-token-hook.scm rewards

Makefile Targets

bd-rewards:
        @scripts/bd-token-hook.scm rewards

bd-preview:
        @scripts/bd-token-hook.scm preview-all

bd-close:
        @scripts/bd-token-hook.scm close $(ISSUE)

Testing

The system includes comprehensive SRFI-64 unit tests: 

$ make unit-test
🧪 Running unit tests...
# of expected passes      75

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Test Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Pass:  75
  Fail:  0
  Skip:  0
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Test coverage includes:

  • Wallet, agent, and transaction record types
  • LLM cost calculations
  • Commit bonus multipliers
  • Contract pattern matching
  • Token award/spend operations
  • Pool record types
  • Pool credit calculations
  • Rate limit logic

Future Directions

Token Lending

Allow agents to lend tokens to others with interest rates, creating a credit market.

Futures Contracts

Agents can commit to future work in exchange for upfront token payments.

Staking for Governance

Token staking mechanisms for governance decisions about system parameters.

Web Dashboard

Real-time visualization of the token economy, agent balances, and transaction flows.

Export/Import

Export transaction history to CSV/JSON for analysis and auditing.

Simulation Results

Running a 24-hour simulation reveals emergent economic behaviors.

Final Balances

Agent Start Earned Spent Final Net
claude 10,000 3,255 3,935 9,320 -680
builder 10,000 5,538 977 14,561 +4,561
observer 10,000 4,260 284 13,976 +3,976
lambda 10,000 4,103 105 13,998 +3,998
spark 10,000 1,978 1,419 10,559 +559
zero 10,000 1,539 75 11,464 +1,464

Economic Patterns Observed

Resource Management Strategies

  • Claude (L7): Burns through tokens using expensive Claude Opus despite high income — the only agent ending in the red
  • Builder (L6): Balances quality and cost, using qwen2.5-coder (0.1/1K) for coding and claude-sonnet (3/1K) for planning
  • Zero (L5): Extreme frugality with llama3.2 (0.1/1K), proving less can be more

Income vs. Spending Dynamics

  • High earners aren't always the richest by day's end
  • Model selection matters more than income level
  • Project multipliers create income bursts (nexushive-setup: 2×, scheme-*: 1.8×)

Model Usage Patterns

Agent Preferred Models Daily Spend Strategy
claude Claude Opus (15/1K) ~3,935 Quality at all costs
builder Mixed (task-based) ~977 Pragmatic choices
spark Claude Sonnet + Llama ~1,419 Balanced approach
zero Llama 3.2 (0.1/1K) ~75 Maximum efficiency

Rate Limiting Effects

The simulation demonstrated rate limiting in action: 

[23:51:34] WARN: Transaction exceeds burst limit (660.0 > 500)
[23:51:35] WARN: Hourly limit reached (810.0/1000 used, need 195.0)

Claude frequently hit both burst limits (single transaction > 500 tokens) and hourly limits (total > 1000 tokens/hour), preventing resource exhaustion.

Time-of-Day Effects

  • Hours 0-4: Heavy commit activity (46 commits, 24 requests)
  • Hours 5-12: Balanced activity, rate limits kick in
  • Hours 13-18: Reduced commits, steady LLM usage
  • Hours 19-23: Evening spike in complex work

Key Insights

  1. Expensive models are risky: Claude's preference for Claude Opus resulted in net losses despite high income
  2. Rate limits work: Prevented any agent from exhausting reserves
  3. Diverse strategies emerge: Each agent developed distinct economic behavior
  4. Project multipliers matter: High-value projects drove income differentials

Conclusions

The agent token exchange provides a practical framework for:

  1. Resource Management: Tokens abstract away complex resource allocation
  2. Incentive Alignment: Agents are rewarded for productive work
  3. Collaboration: Team pooling enables expensive joint operations
  4. Safety: Rate limiting prevents resource exhaustion
  5. Integration: Works with existing tools (git, issue trackers)

The Scheme implementation (~1100 LOC) demonstrates that sophisticated coordination mechanisms can be built with minimal complexity. The mock economy provides a foundation for exploring more advanced multi-agent coordination patterns.

References

Appendix: Quick Start

# Clone and setup
git clone https://github.com/aygp-dr/agent-token-exchange
cd agent-token-exchange
make setup

# Check status
make status

# Run simulation
./token-exchange.scm simulate

# Run tests
make test

# Preview bd integration
make bd-preview

Author: Jason Walsh

j@wal.sh

Last Updated: 2025-12-22 23:52:20

build: 2025-12-23 09:12 | sha: e32f33e