Publish intent
Write task state and any application-owned coordination fields as rows.
Architecture decision 04 · Trusted processing
Treat automation as another trusted endpoint.
A worker or agent can read rows, act, and publish results without exposing task content to the mailbox. Giving it the mesh key also gives it the full row database, and convergent rows do not become an exactly-once queue.
- Decision
- Authorize a headless process to read or change mesh data on behalf of the product.
- Core boundary
- The process receives plaintext authority; the application owns claims, leases, and safe retries.
- Completion
- Choose isolation, delivery semantics, and where result rows or files live.
Correct mental model
The agent is not the mailbox.
The mailbox remains a storage surface that cannot interpret encrypted work. Trusted processing happens in a separate endpoint—browser, native runtime, Python process, or another compatible client—with the same plaintext responsibility as any other participant.
Move protected facts
Store and return encrypted changes without reading or scheduling them.
Read and act
A trusted endpoint pulls the mesh, decrypts rows, and performs the work.
Publish outcomes
Write convergent result state as rows and exact output bodies as files.
Three design obligations
Trust, coordination, and failure stay with the application.
Interocitor transports and merges state. It does not selectively disclose a shared mesh, elect a worker, or prove that an external effect happened exactly once.
Authority
Bound what the process may read
A shared mesh key grants access to every row table in that mesh.
- Use a separate mesh for narrower data access
- Keep sensitive inputs out of the shared scope
- Protect plaintext in the worker runtime
Coordination
Make duplicate work safe
Two processors can observe the same task and both act on it.
- Own claims or leases in application logic
- Use idempotency at the external system
- Make retry behavior explicit
Results
Separate state from bytes
Rows describe status, attempts, ownership, and references; durable files carry reports, media, or other exact output.
- Rows can converge after disconnection
- File transfers require connectivity
- Application owns partial-result cleanup
Queue boundary
A CRDT row is shared state, not a delivery receipt.
Convergence ensures endpoints reach the same row result after receiving the same changes. It does not prevent two workers from observing the same pending task before either worker's claim has reached the other.
Pattern checklist
Define the workflow’s honest guarantees.
Use this before giving a worker or agent credentials for a production mesh.
- List the complete row scope the process will receive and confirm that authority is acceptable.
- Split the workflow into another mesh when it needs a smaller trust boundary.
- Choose whether duplicate execution is harmless, idempotent, claimed, or leased.
- Define retry, timeout, partial completion, and external side-effect recovery.
- Keep task and result state in rows; place large exact output bodies in durable files.
- Plan key custody, recovery, logging, and compromise response for the headless runtime.
Canonical detail
Build the trusted processor.
Choose a headless peer for processing, define its key custody and mesh isolation, then add application-level coordination for work that must not overlap.