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 policy editor
Admins configure execution policies directly from the Permissions tab using the policy editor. The editor lets you toggle a policy between enabled and paused, select which action types it allows, set whether proposals require manual approval or can auto-execute, choose which approver scopes are eligible, and define rate limits (max proposals per hour).
The editor also exposes an emergency pause toggle. When activated, emergency pause forces manual approval for every proposal regardless of what the policy otherwise allows — including proposals that would normally auto-execute under the execute autonomy tier. Use it when something looks wrong and you want a human in the loop on everything until you’ve investigated.
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. Five bridges are available: email, Slack, Jira, Asana, and Linear. Each bridge handles the downstream call and writes the result back onto the proposal. Execution is bounded — failed calls retry on transient errors and give up cleanly on permanent ones, so a misbehaving downstream doesn’t loop indefinitely.
Edit before approve
Reviewers can modify action parameters before approving. For example, you might adjust the priority on a create_ticket proposal or change the target channel on a send_notification. Edited parameters are validated against the requirements for each action type before the proposal can move forward, so a missing field or malformed input is caught at approval time, not at execution. The proposal tracks who edited and when, so the audit trail distinguishes the agent’s original parameters from the reviewer’s adjustments.
Proposing actions from analysis
Delphi can propose actions directly during analysis. When a scenario run produces a “defer” decision, the agent auto-proposes an escalation. When a recommendation crosses a confidence threshold, it can propose a notification. Agent-proposed actions go through the same policy checks as anything reviewed manually: parameter validation, policy and allowed action types, rate limits, and autonomy tier enforcement.
Each agent-proposed action includes an explainable agency record: the inputs the agent used, a summary of the meta-task it was performing, and the alternatives it considered before settling on this action. This context travels with the proposal so reviewers see the full reasoning, not just the proposed parameters.
Explainable agency
Action proposals can carry an “Agent Reasoning” section showing what data the agent consumed, what its objective was, and what alternatives it considered before proposing this particular action. On the approval UI, this appears as a collapsible panel on the proposal card — collapsed by default so it doesn’t clutter the review flow, but always available when a reviewer wants to understand why before deciding.
Agent reasoning is populated automatically when Delphi proposes actions during analysis, and it can also be attached by child agents that inherit their parent’s execution context.
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 a ledger event each time a proposal is created, approved, rejected, executed, or fails — 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 downstream system’s response for successful executions and the error detail 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.