Patterns

Runtime Integration Patterns

Build fewer rigid workflows. Give the runtime its available tools, then wrap each governed execution boundary with Stacksona Gate.

The core pattern

One runtime node instead of a long chain of fixed steps

The runtime receives the request, context, SOP, and available tools. It chooses the next action from the current state. Stacksona does not dictate the workflow. It governs the selected action immediately before execution.

Request + context→Runtime chooses next tool→Gate checks exact call→Execute or replan

The same wrapper works whether the runtime takes two steps or twenty.

Who owns what

Runtime	Stacksona Gate
Reasoning and planning	Tool contracts
Model and provider credentials	Policy and rule checks
Executable tool functions	Human review
Argument validation	Decision delivery
Retries and business logic	Signed approval validation
Execution and replanning	Audit evidence

The five-part wrapper

1
Resolve contracts.
Fetch the names, descriptions, and input_schema for the governed tools this runtime may use.
2
Choose the next tool.
The runtime reasons over the request, prior results, and available contracts.
3
Validate arguments locally.
Your runtime validates the model-generated arguments against the resolved schema.
4
Gate at the last safe moment.
POST the exact tool_name and payload immediately before the real tool executes.
5
Continue from the decision.
Execute on allow/approved, wait on review, revise on feedback, and replan or stop on rejection.

Why resolve tool contracts first

Gate can return the same registered tool names, descriptions, and JSON input schemas that are governed by policy. That gives the runtime a clean capability surface without moving the tool implementation or service credential into Gate.

json

POST /api/agent/tools/resolve
{
  "tools": ["issue_refund", "send_email", "update_crm"]
}

Gate only the final proposed call

The runtime can reason, retrieve, plan, and prepare freely. The governance check belongs directly before the action leaves your system or mutates important state.

json

POST /api/agent/tasks/order-1042/requests
{
  "tool_name": "issue_refund",
  "payload": {
    "amount": 389.99,
    "currency": "usd"
  }
}

tool_name is the only required request field. Add workflow, subject, risk, summary, preview, or image context when it helps policy or reviewers.

Human review is a runtime state, not a separate workflow

Status	Meaning in the runtime loop
`allow`	Execute now.
`pending_review`	Pause this tool call and wait on its `thread_id`.
`changes_requested`	Use reviewer feedback to revise the same proposal thread.
`approved`	Execute after required proof validation.
`reject` / `rejected`	Do not execute. Replan or stop.

Task IDs group work, thread IDs identify reviews

A runtime can reuse one task_id across multiple checks and review threads. Persist the exact Gate-generated thread_id for polling, revisions, and correlation with one human-review request.

Log what actually happened

After execution, write evidence such as tool.execution.completed or tool.execution.failed. Ordinary event names are open-ended, so your application can log its own evidence vocabulary without adding a new workflow system.

Where this pattern fits

Node and TypeScript Custom REST n8n Zapier MCP OpenAI Agents LangGraph

Fail closed at the wrapper

Unknown states, API errors, timeouts, and missing required signed approval proof must never fall through to execution.