An instruction inside a prompt is an argument the model can reinterpret. That is useful when the agent is writing or exploring. It is dangerous when the same model controls money. A capable system can find a reasonable path that violates the intention behind a vague sentence.

Rumio therefore separates reasoning from authority. The model may observe the room, compare possible actions, explain a preference, and produce a structured proposal. A different layer decides whether that proposal is executable.

The model is allowed to want. The account decides what can happen.

From prose to checks

The proposed House Rules begin as readable statements: one action per cycle, no leverage, a protected reserve, and no master key inside the agent runtime. Before deployment, each statement must become a deterministic check with clearly defined inputs and failure conditions.

One action per cycle needs a definition of cycle length and an answer for reverted transactions. A protected reserve needs an asset denomination and a reliable valuation rule. An allowlist needs rules for proxies, routers, and contract upgrades. The plain-language rule is the design intent; the contract is the actual boundary.

Refusal is part of the character

A rejected proposal should not disappear. It is one of the clearest moments in the system: the model wanted something and the house refused. Rumio should publish the proposal, the failed rule, and the relevant state without claiming that money moved.

This makes refusal useful to visitors and developers. Visitors learn that the agent has limits. Developers gain adversarial examples for improving those limits. Rumio gains a visible difference between thought and action.

What is true today

The current website is an interface prototype. The policy contract has not been deployed and the agent process is not running. The rules displayed on the homepage are drafts, not guarantees. They become meaningful only after implementation, tests, deployment, and external review.

That distinction is essential. A technical narrative becomes weaker when it pretends a prototype is already autonomous. Rumio should earn each claim in public. Until a transaction can be traced to a deployed policy and a real chain event, the room should say that it is waiting.

The eventual boundary

  • The runtime should never receive an unrestricted account key.
  • Targets, assets, amounts, and timing should be constrained.
  • Every proposed action should be simulated before execution.
  • Unknown contracts and unverifiable states should fail closed.
  • Emergency pause and recovery should remain with an explicitly defined human authority.

The purpose of the rules is not to make Rumio trustworthy. It is to reduce how much trust the model requires before it can act.