Patterns

Integration Patterns

Reusable patterns for adding Stacksona Gate to any agent workflow.

The core flow

1
Agent prepares an action.
The agent or workflow builds the email, API request, CRM update, refund, file mutation, or deployment step.
2
Workflow creates a Stacksona decision request.
The request includes workflow name, task label, tool name, subject, risk level, summary, and payload.
3
Stacksona returns allow, reject, or pending_review.
Allow can continue immediately. Pending review waits for human approval. Reject stops the action.
4
Workflow validates approval when needed.
Signed approval tokens can be validated before sensitive actions execute.
5
Workflow logs the result.
Events are sent to Stacksona so reviewers and auditors can see what happened before and after the action.

Three integration modes

Mode	Best fit	Notes
Native package	n8n node, SDK, MCP server, agent tools	Use when a live Stacksona package exists for the runtime.
HTTP or webhook	Dify, Make, Zapier, Copilot Studio, Salesforce, GitHub Actions	Use when the platform can call external APIs or receive callbacks.
Sidecar bridge	Python frameworks and enterprise agent platforms	Use a small Node or HTTP service that owns Stacksona API calls.

Decision request shape

json

{
  "workflow_name": "Customer Support",
  "task_label": "Refund request for order #8821",
  "tool_name": "issue_refund",
  "subject": "Issue a $500 refund to customer cus_99",
  "preview": "Agent proposes a refund because shipment has no tracking movement.",
  "risk_level": "high",
  "summary": [
    "Customer requested refund",
    "Order placed 14 days ago",
    "No tracking movement found"
  ],
  "payload": {
    "amount": 500,
    "currency": "usd",
    "customer_id": "cus_99"
  }
}

Fail closed by default

Production rule

If Stacksona cannot verify approval for a sensitive action, the action should not execute. This is especially important for financial, customer-facing, destructive, production, and security actions.