Delphi is built for autonomy with guardrails. Agents watch your data, spot what needs doing, and propose concrete next steps — but nothing leaves the platform without a policy saying it can and, in most cases, a human saying go. Agents propose, you dispose.
A pending action proposal rendered from the governed execution UI used inside Delphi.
Action types
Delphi agents can propose four kinds of action. create_ticket opens work in your tracker when an issue needs an owner and a due date. send_notification pushes a message to a person or channel when someone needs to know now. update_record writes back to a connected system — flipping a status, updating a field, acknowledging an alert. escalate hands the situation up the chain when it has outgrown the agent’s remit.
Each proposal carries a target (the ticket project, the channel, the record), the parameters needed to execute it, a plain-language rationale, and a confidence score. You see all of it before you decide.
Define an execution policy
Policies are the contract between your agents and the outside world. Each policy lives on a dashboard and answers three questions: which action types are allowed, who is allowed to approve them, and how many can fire in an hour.
You define policies on the Permissions tab. Pick the allowed action types from the four above, list the approver scopes (see roles — usually owner and admin, sometimes editor), and set a rate limit so a misfiring agent can’t flood your ticket queue. If a proposal doesn’t match any enabled policy, it can’t be approved — full stop.
The proposal lifecycle
Every proposal moves through a fixed set of states. It starts as proposed when the agent creates it. A reviewer with the right scope moves it to approved or rejected. Approved proposals transition to executing while Delphi hands them to the right bridge, then land on completed or failed depending on how the downstream system responded.
Rejected proposals keep their rationale and rejection reason for the record. Failed ones keep the bridge’s error so you can see what went wrong without digging through logs.
Approving an action
Pending proposals show up in the Alerts tab under “Pending action proposals” and, where relevant, inline on the notification that triggered them. You get the agent’s reasoning, the target, the full parameter set, any linked recommendation, and the confidence score. Approve, reject with a reason, or ask the agent a follow-up question in chat before you decide.
Once you approve, Delphi routes the action through an execution bridge. Email actions go out over the email bridge. Slack notifications go through the Slack bridge. Tickets are opened via the Jira bridge. The bridge handles the downstream call and writes the result back onto the proposal doc.
Autonomy tiers
Not every agent needs approval for every action. Delphi supports three autonomy tiers and you pick one per agent.
Observe is the safest — the agent can report, recommend, and explain, but it cannot create proposals at all. Propose is the default — the agent drafts action proposals and waits for a human. Execute is the most autonomous — the agent can auto-execute actions that its policy has explicitly allowed, skipping the manual approval step. Rate limits and policy checks still apply.
Child agents inherit constraints from their parent: a child can never escalate beyond its parent’s tier, so an observe parent guarantees its whole subtree stays read-only.
What gets logged
Every state change is recorded. Delphi writes ledger events for action.proposed, action.approved, action.rejected, action.executed, and action.failed, each stamped with the actor, the timestamp, and a reference back to the proposal. You get a complete, hash-chained history of who decided what and when, alongside the raw bridge response for successful executions and the error payload for failures.
This is the same hash-chained ledger that backs the rest of your compliance posture — see audit for how to query it, export it, and prove integrity to an outside reviewer.