​
Steps

  1. The agent sends POST /__aim/invoke with { "actionId": "...", "input": ... }.
  2. The bridge checks the token, finds the action in the session’s snapshot, and validates input against that action’s input_schema.
  3. It checks the tab’s heartbeat. No live tab means 409.
  4. It takes the session’s single in-flight slot. If another invocation holds it, 409.
  5. It queues the invocation. The tab picks it up on its next poll and runs the registered handler.
  6. The tab reports the result and its new snapshot. The bridge stores the snapshot, then responds.

​
Outcomes

A 504 does not mean the action failed. The handler may have run. Never automatically repeat a consequential action after a timeout. Re-read state first.

​
Guarantees and non-guarantees

  • The snapshot is stored before success is returned, so an immediate re-read reflects the action.
  • There is no atomic read-then-act. State can change between your read and the handler running. A stricter guarantee would need a revision or precondition mechanism, which 0.1 doesn’t have.
  • AIP is not an exactly-once or durable transaction system.
See Errors for response bodies.