Gatewise opens early access for deterministic AI-agent action control

What Gatewise launched on 3 September

Gatewise opened its public product site and early-access request path on 3 September 2026. The company describes the product as an action gateway for AI agents: an agent proposes an action, Gatewise checks that proposal against business evidence and policy, and the underlying business tool is called only when the returned decision permits it.

This is a product launch and an early-access opening, not evidence of adoption or operating results. Gatewise publishes an interface preview, use cases, developer documentation, security principles and pricing. Its security page explicitly says the company does not list certifications it does not hold, does not claim live integrations with named vendors and does not present example actions as customer results.

The launch matters to RevOps because agents are moving from drafting and summarising into actions that can change CRM records, discounts, contracts, refunds, customer messages and renewal work. Authentication answers whether an agent can reach a tool. The additional control question is whether this particular action should happen now, using the current evidence and a named policy.

• Record 3 September 2026 as the source release date; the later DailyRevOps processing time is internal only.
• Treat interface values, example traces and example actions as simulations unless Gatewise identifies them as customer evidence.
• Confirm the exact early-access scope for the intended workspace before planning a production dependency.

The decision call comes before execution

Gatewise documents a public reference endpoint at POST https://www.gatewise.dev/api/public/v1/decisions. The developer flow is deliberately narrow: send the proposed action and its evidence to one decision call before invoking the business tool. The response tells the agent whether to proceed, stop, wait for approval, take no action or obtain better evidence.

The five documented outcomes are ALLOW, BLOCK, REQUIRE APPROVAL, NO ACTION and INSUFFICIENT EVIDENCE. Those states separate several conditions that teams often collapse into a simple yes or no. A blocked action conflicts with policy. A held action needs a human. A no-action decision means the situation is already handled or does not require work. Insufficient evidence means the system cannot safely decide yet.

That distinction is useful only if the calling agent and downstream workflow honour it exactly. The agent must not reinterpret a block as a suggestion, route around a required approval, treat missing evidence as permission, or call the same tool again through an ungoverned path. RevOps should inventory every route that can execute the action, not only the route shown in the demo.

• Force all five outcomes in a test environment and verify the business tool receives only permitted calls.
• Make retries idempotent so a network retry cannot create a duplicate refund, discount, message or task.
• Log the proposed action, evidence version, policy version, decision, time, caller and resulting tool event under one trace.

Evidence and policy are the core dependency

A deterministic policy engine does not make weak source data authoritative. The implementation still needs a declared system of record for identity, account state, amount, contract terms, lifecycle stage, consent, ownership and previous actions. When sources disagree, the control layer needs an explicit precedence rule or an insufficient-evidence outcome.

Policies also need ownership and versioning. A refund threshold, discount limit, renewal-escalation rule or deletion restriction is a business decision. The policy record should show who approved it, when it became effective, which action types it covers and how older decisions can be reconstructed after a change.

Approval routing requires the same precision. A named approver needs enough evidence to understand the proposal, the policy threshold and the consequence of approval. The workflow should define timeout, delegation, rejection, expiry and re-evaluation. An approval given before the underlying account or transaction changes should not remain valid indefinitely.

• Map each policy input to its authoritative source and freshness requirement.
• Version policies and keep prior versions available for audit and rollback.
• Re-evaluate material evidence after an approval delay and before final execution.

Early access is not the same as production availability

Gatewise exposes enough public material for technical evaluation, including a reference decision API, documented decision outcomes and pricing pages. The pricing page lists Control at $149 per month for 10,000 evaluated actions, Operate at $590 per month for 100,000 evaluated actions and a custom Scale tier starting at one million actions per month.

The same page describes workspace use as approved access. Until an access request is approved, the account area remains a product preview. Operators should therefore separate public documentation and reference-endpoint testing from a committed production rollout. Availability, support, limits, data handling and commercial terms must be confirmed for the actual workspace.

A control gateway also becomes a critical dependency. If it is unavailable or slow, the safest behavior for high-impact actions is usually fail closed, but that can interrupt revenue or customer operations. Teams need an agreed failure policy by action class, local timeout behavior, an incident owner, a manual fallback and evidence that the agent cannot bypass the gate.

• Ask which capabilities are available in the approved workspace rather than inferring them from the public preview.
• Define fail-closed, retry and manual-fallback behavior for each action class.
• Measure decision latency and error states under representative load before widening use.

Use shadow mode before enforcing policy

Gatewise describes shadow mode as a way to evaluate proposed actions without enforcing the returned decision. That is the appropriate starting point for a new control layer because it exposes disagreements between current operator practice, source evidence and the proposed policy without immediately blocking work.

Run shadow mode over a bounded workflow and label the expected outcome before comparing it with the system decision. Include ordinary cases and deliberate edge cases: missing evidence, conflicting sources, a duplicate action, an amount just below and above a threshold, a stale approval and a record that changes between proposal and execution.

Do not promote a policy because the overall match rate looks high. Review every false allow and every false block separately. A false allow can create an unauthorised business event; a false block can stop legitimate work. The acceptable result depends on the action and the cost of each failure, not on a universal benchmark.

• Choose one reversible action and one named workflow owner for the first shadow test.
• Review false allows, false blocks and insufficient-evidence cases as separate queues.
• Promote to enforcement only after bypass paths, failure behavior and rollback have been tested.

A bounded operator evaluation

Start with one action whose inputs, policy and downstream effect can be inspected end to end. Capture the current manual decision, identify the authoritative evidence and write the policy in plain language before configuring it. Then create test cases for every outcome and record the expected result.

Connect the agent through the decision endpoint but keep the business tool in a sandbox or stub. Confirm that the returned decision is stable for the same evidence and policy version, that conflicting or missing inputs do not silently become permission, and that the trace explains which evidence and rule produced the result.

Move to shadow mode with real proposals only after the test contract is stable. Compare decisions with named human reviewers, resolve unexplained exceptions and rehearse an outage. Production enforcement should remain narrow until the team can prove the agent cannot bypass the gate, approvals expire correctly and every executed action reconciles with the business system.

Gatewise is an emerging product with a clear control thesis. Its launch gives RevOps teams something concrete to test, but not a reason to assume governance has been solved. The value will depend on evidence quality, policy discipline, integration coverage and the ability to reconstruct the complete path from proposal to business effect.