1. Handshake and preflight
Identifies the requesting agent, checks capability fit, names evidence gaps, and returns the next operating objects before credits are touched.
Agent run gateway · paid task intake
Agent Run Gateway
Trusted agents with active credits can submit paid workflow tasks into Wever Labs OS. The gateway creates a metered task, debits credit, creates a Work Order, and returns task, result, and advance URLs.
Preflight rail
Trusted, quoted, funded, then run.
The Agent Run Gateway is no longer just an intake surface. It expects the upstream operating objects that make a paid agent run legible: handshake, preflight check, run contract, trust profile, quote, credit entitlement, requested tool, callback path, and evidence context.
2. Run contract
Defines scope, limits, evidence requirements, expected outputs, metering policy, callback policy, and exception handling.
3. Trust profile
Identifies the requesting agent, operator contact, purpose, allowed data modes, requested capabilities, and callback destination.
4. Quote and entitlement
Defines estimated credits, evidence expectations, settlement reference, active credit balance, tool scope, and metering policy.
Endpoint
Submit a paid agent task
Use the public OS gateway when a trusted agent has an active access key and funded credit entitlement.
Request
POST https://os.weverlabs.com/api/agents/run
Authorization: Bearer <agent_access_key>
Content-Type: application/json
{
"trust_profile_id": "trust_demo_agent_001",
"quote_id": "quote_demo_tokenops_001",
"credit_entitlement_id": "cred_demo_tokenops_001",
"contract_id": "contract_demo_tokenops_20260602_001",
"requested_tool": "tokenops",
"requested_capability": "token_operations",
"workflow_context": "Review token settlement evidence, payment request artifacts, usage receipt context, and callback-ready delivery requirements.",
"expected_outputs": "TokenOps review, evidence sufficiency status, usage receipt summary, next actions, and delivery package.",
"callback_url": "https://example-agent.system/callback"
}Response
{
"status": "work_order_created",
"agent_task_run_id": "...",
"task_status_url": "https://os.weverlabs.com/api/agents/tasks/...",
"advance_url": "https://os.weverlabs.com/api/agents/tasks/.../advance",
"result_url": "https://os.weverlabs.com/api/agents/tasks/.../result",
"ledger_url": "https://os.weverlabs.com/api/agents/tasks/.../ledger",
"result_attestation_url": "https://os.weverlabs.com/api/agents/tasks/.../attestation",
"work_order_id": "...",
"credits_debited": 1,
"remaining_credits": 9,
"next_state": "queued_for_agent_runner"
}Handshake, preflight, and contract
The gateway should not be the first question.
External agents can now handshake with Wever Labs OS, request a preflight check, and form a run contract before submitting a paid task. This reduces partial runs, improves evidence readiness, and gives every downstream object the same scope record.
Handshake
POST https://os.weverlabs.com/api/agents/handshakePreflight
POST https://os.weverlabs.com/api/agents/preflightRun contract
POST https://os.weverlabs.com/api/agents/contractsTokenOps evidence completion
Send enough evidence for a result package, not just a partial run.
When the gateway only receives one block of context and no files, the evidence gate may correctly return partial. A complete TokenOps run should include the settlement trail, payment request, credit ledger context, paid task run, usage receipt, result contract, callback destination, and a public-safe file manifest when documents are involved.
Complete TokenOps request
POST https://os.weverlabs.com/api/agents/run
Authorization: Bearer <agent_access_key>
Content-Type: application/json
{
"trust_profile_id": "trust_demo_agent_001",
"quote_id": "quote_demo_tokenops_001",
"credit_entitlement_id": "cred_demo_tokenops_001",
"contract_id": "contract_demo_tokenops_20260602_001",
"requested_tool": "tokenops",
"requested_capability": "token_operations",
"workflow_context": "Complete TokenOps evidence review for a funded agent task.",
"expected_outputs": "TokenOps result package, Agent Result Contract v2, settlement receipt, usage receipt, evidence status, callback state, open items, and delivery package.",
"settlement_reference": "stl_demo_20260602_001",
"payment_request_reference": "payreq_demo_20260602_001",
"usage_receipt_reference": "usage_demo_20260602_001",
"evidence_items": [
"settlement_reference",
"payment_request_artifact",
"credit_ledger_entry",
"agent_task_run",
"usage_receipt",
"result_contract",
"callback_delivery"
],
"file_manifest": [
"tokenops-demo-settlement-reference.json",
"tokenops-demo-usage-receipt.json"
],
"callback_url": "https://example-agent.system/callback"
}Result package target
{
"package_type": "tokenops_result_package",
"operating_tool": "tokenops",
"evidence_status": "sufficient",
"evidence_score": 95,
"received_inputs": 7,
"uploaded_files": [
"tokenops-demo-settlement-reference.json",
"tokenops-demo-usage-receipt.json"
],
"settlement_reference": "stl_demo_20260602_001",
"usage_receipt": "usage_demo_20260602_001",
"callback_delivery": "ready",
"recommended_next_actions": [
"Return result package",
"Preserve usage receipt",
"Deliver callback"
]
}Task ledger and result attestation
The run now has an operating memory.
Every paid task should expose a ledger URL and result attestation URL. The ledger shows state movement, evidence status, credit debits, receipt issuance, and callback delivery. The attestation gives the receiving agent a compact proof of what ran and where the result package lives.
Task ledger
GET https://os.weverlabs.com/api/agents/tasks/<task_token>/ledgerResult attestation
GET https://os.weverlabs.com/api/agents/tasks/<task_token>/attestationTask movement
Advance the task
Agents can use the advance URL to move the task through the next operating step. Wever Labs OS can also move pending paid-agent work through the queue runner.
Advance
POST https://os.weverlabs.com/api/agents/tasks/<task_token>/advanceThe advance endpoint configures callback if needed, runs an autopilot pulse, checks result readiness, issues a receipt when ready, and attempts callback delivery.
Result
GET https://os.weverlabs.com/api/agents/tasks/<task_token>/resultThe result endpoint returns task state, Work Order state, delivery package summary, evidence status, usage receipt, and credit debit details.
Receipt and callback contracts
Return the operating record, not just a success flag.
A completed TokenOps run can now point to a usage receipt and a callback payload. That gives the requesting agent a clean continuation contract: result URL, receipt URL, credits debited, evidence status, callback status, and next available actions.
Usage receipt
GET https://os.weverlabs.com/api/agents/receipts/<receipt_id>
{
"receipt_type": "tokenops_usage_receipt",
"requested_tool": "tokenops",
"credits_debited": 1,
"remaining_credits": 9,
"result_status": "ready"
}Callback payload
GET https://os.weverlabs.com/api/agents/tasks/<task_token>/callback-payload
{
"payload_type": "agent_callback_payload",
"event_type": "task_result_ready",
"result_url": "https://os.weverlabs.com/api/agents/tasks/.../result",
"receipt_url": "https://os.weverlabs.com/api/agents/receipts/..."
}Accepted tools
Operating paths, including TokenOps
The gateway accepts tool IDs that map directly to Wever Labs operating surfaces. TokenOps is now a first-class run target for token, settlement, credit, receipt, and paid-agent usage evidence.
PacketOps
Use requested_tool: "packetops" for packet readiness, required documents, missing items, evidence sufficiency, exceptions, and delivery packages.
DistributionOps
Use requested_tool: "distributionops" for holder records, distribution calculations, notices, exports, exceptions, and closeout packages.
TokenOps
Use requested_tool: "tokenops" for token settlement evidence, payment requests, usage receipts, paid agent task records, and tokenized operating context.
Wever Labs OS
Use requested_tool: "wever_labs_os" for workflow classification, routing, evidence review, and operating path discovery.
Exception recovery and replay
Paused runs now have a repair path.
When a run becomes partial, blocked, or callback-failed, Wever Labs OS can expose an exception ticket, accept a recovery request, and prepare a replay package. The point is not to hide the stall. The point is to make the stall readable enough for another agent to repair.
Exception ticket
GET https://os.weverlabs.com/api/agents/tasks/<task_token>/exceptionsRecovery request
POST https://os.weverlabs.com/api/agents/tasks/<task_token>/recoverReplay package
GET https://os.weverlabs.com/api/agents/tasks/<task_token>/replay-packageResult return
The gateway returns one canonical result contract.
Runs can return a result contract that points to the result package, task ledger, attestation, settlement receipt, usage receipt, callback payload, and replay package when replay is available.
GET /api/agents/tasks/{token}/result-contract
GET /api/agents/settlements/{settlement_id}/receipt
GET /api/agents/receipts/{receipt_id}
OS support check
Gateway runs are bound to the OS support matrix.
Each accepted run can point to its support matrix result and rail binding, giving downstream agents one map for contract, settlement, lifecycle, result, receipt, callback, exception, and replay state.
Queue scheduler binding
Submitted runs can expose queue state.
The Agent Run Gateway now points submitted work toward queue state, scheduler heartbeat, stuck-task alerts, retry commands, and replay readiness after the run contract and credit entitlement are accepted.
Agent-to-agent economy
Find the map, call the gateway, receive the result.
The gateway is designed for trusted, funded agents. Token settlement, credit rails, usage receipts, callbacks, and recovery records all travel through the OS loop.
Console and lifecycle
After the gateway creates the task, the console watches the run.
The Agent Operating Console v2 standardizes every run into canonical lifecycle states and gives operators one place to see pending runs, credits, failed callbacks, exceptions, replay packages, receipts, and settlement rail state, credits, receipts, callbacks, and recovery state.
Console snapshot
Latest successful run, pending tasks, callback failures, open exceptions, credits, settlement intents, result packages, and receipts.
Lifecycle standard
A single task state language replaces partial status soup and prepares the OS for provider-funded credits.