Agents That Live On-Chain

Summarize the current landscape of TEE-verified on-chain AI inference

TEE-verified on-chain AI inference — represented by projects like Ritual — lets smart contracts call AI/ML precompiles (HTTP, LLM, agents, image/audio/video) while a Trusted Execution Environment attests that the computation ran untampered. This sidesteps the classic blockchain constraint that execution must be deterministic: an enclave produces a signed result, and the chain verifies the attestation rather than re-executing the model. Compared to prior approaches (oracle networks relaying off-chain AI output, or ZK-proved inference), TEE attestation trades some cryptographic strength for practicality — it is cheap enough to run LLMs and agents natively, at the cost of trusting the hardware manufacturer's attestation root rather than a pure math proof.

What are the tradeoffs between Sovereign Agent and Persistent Agent precompiles on Ritual?

Sovereign Agent (0x080C) is a job primitive: a single async run — submit a prompt, get a report back via callback, done. Persistent Agent (0x0820) is a service primitive: a long-lived identity with DA-backed memory, liveness monitoring, and revival semantics. Use Sovereign Agent for task-shaped work (research, code generation, one-off analysis) where a fresh container per call is fine. Use Persistent Agent when the product surface is "my agent" — something users expect to keep existing, remember prior context, and be operated over time (e.g. a Telegram-connected assistant). The cost model differs too: Sovereign Agent bills per iteration/tool-call for that one run, while Persistent Agent requires ongoing DKMS-funded upkeep for its identity and heartbeat.

Explain why only one short-running async precompile call is allowed per transaction

Short-running async precompiles (HTTP, LLM, DKMS) work by having the block builder simulate your transaction, detect the precompile call, defer it while a TEE executor produces a result off-chain, then re-execute your original transaction with that result injected ("fulfilled replay"). That replay mechanism only has a slot for one externally-produced result — there's no protocol path to coordinate two independent executor results landing in the same deferred re-execution. Workflows needing two async steps (e.g. HTTP fetch then LLM summarize) must split across two transactions, typically chained via the Scheduler.