Skip to main content

Methods

Reboot uses qualified method kinds to provide better safety guarantees for your application. Based on a method kind, you can easily answer questions such as:

  • Will a method perform any mutations of a state?
  • Will a method perform any mutations on other states?
  • If this method performs mutations on other states, when do those effects become visible?
  • Which other methods can run concurrently with this method?

Enforcing these guarantees naturally creates a safety hierarchy, in which methods can only call other methods that enforce similar or stronger guarantees. This allows Reboot to:

  • Safely maximize the number of operations running in parallel on a state, while still preserving safety guarantees.
  • Take over complicated safety semantics for you, such as locking and transactionality across states.
  • Monitor the call graph, to guarantee that transitive calls don't have unintended side-effects, even as code changes.

Kinds​

The five kinds of methods in Reboot are:

Kind
readerreader methods are allowed to read from but not mutate state. Every reader is given a read-only snapshot of the state allowing multiple readers to execute concurrently on a given state instance. readers can only call other readers.
writerwriter methods can both read from and mutate state. writer execution happens serially on a given state, allowing each update to happen atomically. To enforce write atomicity, writers can call any readers, but they cannot call other writers.
transactiontransactions combine multiple read/write operations into a single atomic action, often across multiple states. All of the reads and writes included in the transaction will happen atomically: once a state is involved in a transaction, no other RPCs may mutate its state until that transaction is complete. If any part of the transaction fails, the entire transaction will be rolled back. transactions may call readers, writers, and other transactions. Every transaction declares whether it holds its own state exclusive or shared while it runs; see Exclusive or shared.
workflowworkflow methods asynchronously combine multiple read/write operations without holding a lock. State updates may be visible to the outside world before the workflow completes. If a failure occurs, the workflow is retried from the beginning until it runs to completion.
UIUI methods declare a React component to display inside an MCP client. The React App.tsx is the implementation; there is no backend servicer code. When the AI calls the associated tool, the MCP client opens the React app. See UI methods.

Exposing methods to an AI​

Every method is callable from your own code, from a web or React Native frontend, and from anywhere else you have a client. Whether an AI may call it is a separate, explicit decision.

When you define your API with Pydantic, every method declares its MCP exposure with mcp=Tool() (expose it as an AI-callable tool) or mcp=None (hide it from the AI). There is no implicit default, so nothing reaches an AI by accident. This applies to all state types, including User. See Creating tools and MCP UIs.