What does an approver see?

The exact payload: the action, its arguments and who the agent acts for. Approving it resumes the run.

Can an agent end up with more access than the person it acts for?

No. Delegation only narrows. An agent never has more than the person it acts for, and revoking the delegation stops everything that depends on it.

Sandboxed, standard and trusted. Trust is earned. The gate checks each action's risk against the agent's tier, and anything above it needs a person.

No. The kernel applies an approved action exactly once.

People in charge

Agents propose. Rules decide. The kernel applies. Approvals show the exact payload, delegation only narrows, and trust is earned.

Approvals

When the gate says an action needs approval, the run waits and the request lands in the approver's inbox.

The approver sees the payload: the action, its arguments and who the agent acts for.
Approve it and the run resumes from where it waited.
The kernel applies the approved action once. A $240 refund is paid exactly once.
Deny it and the agent is told why. Both decisions land in the log.

inbox / approval (example)

Refund to AcmeNeeds approval

DenyApprove

Approved once, applied once. The run resumes from where it waited.

Delegation and trust

Every agent acts for a person. Delegation answers the first question. The gate and the log answer the second.

An agent never has more than the person it acts for. Pass on less, never more.

Revoke a delegation and everything that depends on it stops.

Sandboxed, standard, trusted. The gate weighs each action's risk against the agent's tier.

Approvals wait in the inbox of the person who has to decide, with the exact payload.

A person's ask is a trigger. Ask an agent for work and it acts for you, within your limits.

Approvals, denials and delegations land in the tamper-evident log with the run they belong to.

Design partners run one real workflow on OrchKernel and work directly with the engineers building it.

OrchKernel is source-available and self-hosted.