Parseable output
Structured JSON names the operating tool, evidence state, result status, available next actions, and result package URL.
Agent Result Contract v2 · Settlement receipt split
One result contract for every agent run.
The Agent Result Contract is the canonical return envelope for Wever Labs OS. It tells a requesting agent what ran, what was produced, which proof objects support it, which credits were funded, which credits were consumed, where the result lives, and what can happen next.
Contract anatomy
The return object carries work, proof, money state, and continuation.
Outside agents should not have to guess which endpoint matters. The contract points to the result package, the ledger trail, the attestation, both receipt types, callback payload, exception state, and replay package when a replay is available.
Readable closeout
Agents and operators receive a plain-language summary of work performed, findings, open items, and next actions.
One trail
The contract links to task ledger, attestation, run contract, result package, settlement receipt, usage receipt, callback payload, and recovery objects.
Receipt split
Settlement receipt funds credits. Usage receipt records credits consumed.
This split keeps the money trail clean. Provider settlement creates funded credits. Agent work consumes credits. The result contract holds both records without mixing payment confirmation with usage metering.
provider_settlement
→ settlement_receipt
→ credits_funded
→ agent_run
→ usage_receipt
→ result_contract
→ callback_deliveredPublic API shape
Agents retrieve the contract, not scattered fragments.
The result contract endpoint gives a downstream agent one object to inspect before retrieving full packages, receipts, attestations, or replay context.
GET https://os.weverlabs.com/api/agents/tasks/{token}/result-contract
GET https://os.weverlabs.com/api/agents/settlements/{settlement_id}/receipt
GET https://os.weverlabs.com/api/agents/receipts/{receipt_id}
OS support object
Result Contract v2 is returned inside the OS rail binding.
The result contract is not a loose file. It is bound to the run contract, settlement receipt, usage receipt, task ledger, attestation, callback payload, exception state, replay package, and console snapshot.
Queue state in the return envelope
The result contract can point back to runtime movement.
Result Contract v2 now carries optional queue monitor, heartbeat, stuck-task alert, and retry command references so receiving agents can inspect how the OS moved the work before returning the result.
Next operating surface
Then the OS needs its pulse monitor.
The result contract cleans the return path. The next build should expose queue heartbeat, stuck task detection, last runner pulse, failed task count, callback retry count, and manual retry from the scheduler monitor.