Actions

A connector brings the world in (read-only discovery). An action changes the world out: send an email, update a deal, create a task. Actions are the write half of the runtime — and because writing is where the risk is, every action runs through the permission model.

What an action is

Like a connector, an action is a small plugin on a stable interface. It declares:

• an id (gmail.send) and a typed input schema,
• the authz grant it requires (send_email),
• whether it's external (touches the outside world — so the autonomy gate can require approval),
• which source's credentials it runs with (resolved from the encrypted vault),
• an execute that does the write and returns a result.

The runtime handles the rest — gating, persistence, the audit trail. The action just does the write.

Propose → gate → execute

An actor proposes an action; it doesn't just happen:

1. Authz decides. A human (or a token) holding the grant acts directly. An agent teammate is subject to the autonomy gate: an external action at low autonomy needs approval.
2. Gated actions wait. A proposed action that needs approval is persisted and surfaces in the review queue as its own kind — routed to the right person, like everything else.
3. Approval executes it. On approval the runtime resolves the source's credentials and runs the action, recording the result. Rejection never executes.

So a teammate drafting a follow-up doesn't send it — the send lands in your queue, and you approve. Discovery is free; mutation is earned.

Built-in actions

More land as the connector pack grows a write side (task creation, DocuSign). Every one is narrow, typed, and gated the same way.