Every action follows this lifecycle — no shortcuts
Action requested
agent calls preflight
Preflight validate
schema + policy → approved
Execute
external API call
Verify outcome
query external system directly
Mark complete
only when verified = true
Action-taking agents fail silently. APIs return accepted, queued, or processing — and agents treat all of them as done.
A 202 means queued. A 200 means accepted. Neither confirms that a payment cleared, a record was written, or a ticket was opened.
The agent receives accepted, marks the step complete, and triggers the next action. The payout never arrived. No one knows.
By the time a human catches the error, the agent has already chained a refund on a charge that never existed.
Payments are where this hurts most
Your agent charges a customer, receives a charge ID, reports success, and moves on. Two hours later: the charge doesn't exist in Stripe. The agent created a false completion. DriftGentic catches this before the downstream systems act on it.
A complete 4-phase action lifecycle. Each phase produces explicit machine-readable state — no ambiguous outcomes your agent has to guess at.
Validate the action payload against a typed contract before touching the external API. Schema errors return suggested fixes, not production failures.
Every action runs through policy rules: block on missing fields, require approval above a risk threshold, halt on suspicious inputs.
Every action gets a run_id. Status transitions — pending, accepted, completed, failed, unknown — are explicit and machine-readable.
After execution, DriftGentic queries the external system directly. If no matching record exists, the run is flagged false_complete — not success.
Verification is not the same as validation
Validation catches bad inputs before execution. Verification confirms the real-world outcome after execution. Both are required. Most tools only do the first.
REST API and MCP server. Both return machine-readable responses your agent can act on directly — no parsing, no guessing.
Request
POST /functions/v1/action-preflight
Authorization: Bearer bsk_live_...
{
"contract_slug": "stripe-charge",
"action_input": {
"amount": 2000,
"currency": "usd",
"customer_id": "cus_abc123"
}
}Response
{
"ok": true,
"run_id": "run_8f2a1b...",
"risk_level": "high",
"validation": {
"status": "passed",
"issues": []
},
"policy": {
"decision": "approved",
"rules_evaluated": 3
},
"next_step": "proceed_to_execution"
}// DriftGentic as an MCP tool
const pre = await mcp.call(
"preflight_validate_action",
{
contract_slug: "stripe-charge",
action_input: {
amount: 2000,
currency: "usd",
customer_id: "cus_abc123"
}
}
);
if (!pre.ok) {
throw new Error(pre.instructions);
}
// Execute then verify
await stripe.charges.create(pre.run_id);
const result = await mcp.call(
"verify_action_outcome",
{ run_id: pre.run_id,
external_ref: charge.id }
);
// verified: true = safe to continuePayments first. Each integration has typed schemas, verification strategies, and policy hooks built in.
Payments & refunds
CRM writes
Support tickets
Outbound messages