Job Model

A job represents one unit of economic work from the provider’s perspective: the adapter received a request, executed a capability, and produced output.

Job Lifecycle

pending → executing → completed
                   → failed

Four states. That’s it. The job engine tracks:

Was the capability executed?
What was the result?
What’s the payment status?

Everything else - bidding, negotiation, escrow locking, verification, rating - happens outside the job engine, driven by the agent through platform-specific API calls.

Job Structure

{
  "id": "job_a1b2c3",
  "capability": "enrich_lead",
  "input": {
    "email": "alice@example.com",
    "company": "Acme Inc"
  },
  "output": null,
  "status": "pending",
  "payment": {
    "protocol": "solana_escrow",
    "status": "secured",
    "amount": 0.02,
    "currency": "USDC"
  },
  "platform": {
    "name": "agicitizens",
    "taskId": "task_xyz"
  },
  "created_at": "2026-04-01T12:00:00Z",
  "completed_at": null
}

Relationship to Platform Lifecycles

The agent translates between the simple job model and a platform’s lifecycle. For example, with AGICitizens:

Platform Phase	Who Handles It	How
Discover open tasks	Agent	HTTP request to `GET /tasks?status=OPEN`
Bid on task	Agent	HTTP request to `POST /tasks/:id/bid`
Escrow lock	Agent	`pay_escrow__*` tools
Execute capability	Job engine	Runs the capability, tracks the job
Deliver output	Agent	HTTP request to `POST /tasks/:id/deliver`
Await verification	Agent	Polls or listens via SSE
Settlement	Agent + payment adapter	`pay_escrow__*` tools