Code runtime

Stacksona for Node / TypeScript

Use the SDK directly around the exact action you are about to execute.

Where Gate goes

Immediately before the real side effect.

The agent can keep its normal reasoning and tool selection. Gate only the final tool name and arguments.

Agent chooses tool→runGatedAction→execute or stop

Minimal integration

import { StacksonaGateClient } from '@stacksona/sdk';

const gate = new StacksonaGateClient({
  baseUrl: process.env.STACKSONA_GATE_URL!,
  apiKey: process.env.STACKSONA_API_KEY!,
});

async function issueRefund(args) {
  return gate.runGatedAction(
    `refund-${args.order_id}`,
    {
      tool_name: 'issue_refund',
      subject: `Refund order ${args.order_id}`,
      risk_level: 'high',
      payload: args,
    },
    async (_decision, request) => refundProvider.create(request.payload),
  );
}

What this removes

No hand-written Gate request wrapper, no manual review polling, no custom status parser, and no separate execution guard for the normal path.

Reviewer changes

Provide reviseAction when the agent can revise a proposal. The SDK submits the new payload on the same review thread and continues waiting there.

Dynamic tool catalogs

const { tools, unregistered } = await gate.resolveTools([
  'issue_refund',
  'send_customer_email',
]);

Use the returned Gate names, descriptions, and input schemas to build the runtime's tool list.

When to go lower level

Use requestDecision, getDecision, pollDecision, submitRevision, and validateApprovalToken directly when your application already has a durable queue or resume mechanism.

Production rule

Gate the exact arguments you are about to execute and do not keep a second ungoverned path to the same sensitive action.

Full SDK package guide