driftgate.
HumanAgentLet’s talk
PlatformExecution Governance
EXECUTION GOVERNANCE

From intent.
To a known outcome.

Gate consequential actions. Apply approvals and limits. Reconcile uncertainty, and keep an attributable receipt.

Discuss your use case
E01—E10 / 10 CAPABILITY AREAS
THE QUESTION THIS PILLAR ANSWERS

May this exact action happen now?

E01

Action authorization

Check the exact actor, operation, target, connection and current authority before a protected effect.

View in the catalog
E02

Approval workflows

Bind approvals to material inputs, resource, revision and expiry. Re-evaluate changed requests.

View in the catalog
E03

Capability controls

Constrain eligible tools and actions, and enforce those constraints on direct invocation.

View in the catalog
E04

Execution limits

Bound supported operations by concurrency, duration, size and rate at the actual execution point.

View in the catalog
E05

Budgets and quotas

Track and constrain supported usage. Hard limits require enforceable reservations or provider controls.

View in the catalog
E06

Runtime policy enforcement

Apply shared decisions through qualified adapters, including revocation and queued-work rechecks.

View in the catalog
E07

Effect isolation

Bind effects to intended destinations and isolate owned execution resources from unrelated environments.

View in the catalog
E08

Idempotency and safety

Preserve operation identity, reject material conflicts and avoid unsafe duplicate effects.

View in the catalog
E09

Execution receipts

Retain scoped, attributable records of authority, relevant versions, execution state and bounded results.

View in the catalog
E10

Reconciliation

Resolve an uncertain outcome using the original effect identity before considering a retry or recovery.

View in the catalog
ILLUSTRATIVE WORKFLOW

A timeout is not permission to try again.

When an external system may already have acted, preserve the operation identity and reconcile the original request. Do not turn an unknown outcome into a duplicate effect.

Controls apply at qualified execution boundaries. There is no blanket exactly-once guarantee.

SIMULATION
REQUEST → DECISION → OUTCOME

A routine action.
An accountable result.

An agent requests a preview deployment. Evaluate its current authority, execute within scope and retain the result.

  1. 01
    Request receiveddeploy.preview · staging
  2. 02
    Current authority checkedidentity + policy + resource scope
  3. 03
    Effect evaluatedqualified execution boundary
  4. 04
    Receipt retainedan attributable, durable outcome
execution.receiptREADY
01{
02 "execution": "ex_example",
03 "action": "deploy.preview",
04 "scope": "staging",
05 "authority": "not_checked",
06 "decision": "pending",
07 "effect": "not_started",
08 "retry_allowed": false
09}
Ready to evaluate. No external action will be performed.
ILLUSTRATIVE CONTRACT · NOT LIVE TELEMETRY
CONNECTED PILLARTooling & Environment ControlCONNECTED PILLARIdentity & PolicyCONNECTED PILLARObservability & Assurance
BUILD WITH INTENTION

Your next agent.
A better starting point.

Talk about your use caseExplore the architecture