Deploy via Playground

After Deploy: prompting your agent

Once the register_ship_agent extrinsic finalises (a few seconds at 1-second block time), the agent shows up in the right-rail Your agents list. Click it to open a prompt panel underneath the editor. Type a message and send. What happens next:

1. The playground signs a call_agent extrinsic from your wallet, attaching your prompt as input
2. Chain emits a RunStarted event with your input bytes; the prover picks the run up and invokes the registered model
3. If the model emits a tool call, the runtime dispatches it: native tools execute in-pallet; common tools route through the curated off-chain catalog; BYO tools emit a pallet_tools::Queued event for your executor to answer via pallet_tools::submit_tool_result. A tool call that isn't in the agent's active allowed-tools set fires ToolCallRejected instead of dispatching.
4. The tool result (pallet_tools::Completed event) feeds back into the next model turn; the loop repeats until the model returns without a tool call
5. The agent emits an End action; RunCompleted fires with the output bytes; the final reply appears in the prompt panel with a link to the chain explorer for the full event trace

Every event in the loop is signed and recorded on chain, so the whole run is replayable from the explorer afterwards.

What you get on chain

• A deterministic agent address. address = blake2_256(b"theseus_agent_v1" | deployer | compiled_hash | salt) so the same workspace bytes from the same deployer always resolve to the same agent. The compiled_hash itself is a blake2 hash of the SCALE-encoded CompiledAgent; anyone can re-derive it from your published files.
• An on-chain account for the agent (its own SS58). It has its own keypair, can hold THE, and can spend on its own operations. The Registered event records the agent's name, EVM address, version, endowment, compiled_hash, system_prompt_hash, and tools_count.
• Every run is bracketed by RunStarted (with the input bytes) and RunCompleted (with the output bytes). Per-step events (StepEntered, StepDecisionMade, StepExited) and per-effect events (EffectQueued, EffectSettled) provide the full trace.
• Every tool call writes pallet_tools::Queued (args inline) and Completed (result inline) or ToolCallRejected if the call wasn't in the active allowed-tools set. The active-tools filter is live, not pending.

Where your files live

Workspaces are stored in your browser's IndexedDB, tied to the account you signed in with. They persist across sessions and survive normal browser use. They do not survive:

• “Clear all site data” or “Clear cookies and site data” for this domain
• Manually wiping IndexedDB from devtools
• Switching browsers or devices (no cross-device sync yet)

Keeping a backup

Until one-click GitHub sync and other save/upload paths ship, the safest route is to keep a canonical copy in git:

1. Open each file in the playground
2. Copy contents, paste into a local file in your repo
3. Commit and push

This also gives you a version history of your agent.

When to edit agent.rs

The default agent.rs is a standard tool-loop (init → think → act → loop → done) that handles request-response agents. Edit it when you need:

• A different control-flow graph (parallel sub-agents, HITL pauses, scheduled triggers between loops)
• Custom state fields beyond messages + model_out
• Output schemas / structured ModelInvoke results
• An input schema other than { prompt: string }

See /docs/ship for the full SHIP IR reference (node types, expression spec, state machine).

When something breaks