Book a technical demo

Use cases

Actions worth checking before they run.

Three kinds of action, one check. Something proposes the action, StreamKernel checks it against your policy before anything is sent, and the decision is kept as signed evidence. Each scenario below says whether it is demonstrated in the runtime today, with synthetic data, or would be built in a pilot.

Payments

Payment operations, treasury, and platform teams at fintechs, payment providers, and merchants.

Automation and agents now propose transfers, payouts, and refunds. StreamKernel checks each proposal against your policy before it dispatches anything, and writes a signed record of the decision.

Where this stands todayThe runtime includes a payment-transfer demo: synthetic accounts, a simulated processor, and transfers only. It authorizes the agent identity a proposal asserts and does not verify it. Connecting a real processor or bank API is pilot work.

  • Transfers and payouts Demonstrated with synthetic data

    The demo policy enforces a per-transfer ceiling, an approval threshold for destinations not paid before, a permitted currency, restricted destinations, and which agent may move money from which account. The simulated processor accepts a transfer only with a grant bound to the exact request.

  • Decision evidence around a fraud score Demonstrated with synthetic data

    A demo pipeline combines synthetic fraud, credit, and screening scores into one decision event that carries the policy version, the reason codes, and the route. The scorers in it are synthetic; putting your own fraud engine in that position is pilot work.

  • Refunds and credits Built in a pilot

    A pilot would add the refund as an action type and a policy for it: what an agent or a support workflow may refund without a reviewer, and which refunds are refused before they are issued.

  • Payment-run release Built in a pilot

    A pilot would put the release of a batch behind the checks you already require, such as approver identity, cut-off, and total value.

Talk through one of these

ERP

Finance-systems, accounts payable, and controllership teams adding automation or agents to their ERP.

An agent that can change a vendor's bank details or post a journal entry needs the control a payment does: a policy decision before the write, and a signed record afterwards. The check is the one demonstrated for payments. Everything specific to ERP is still to be built.

Where this stands todayNothing ERP-specific exists in the runtime yet. There is no ERP connector, no model of invoices, purchase orders, or vendor records, and no control that spans two documents. These scenarios describe how the demonstrated check would apply, and each would be built with a design partner in a pilot.

  • Vendor bank-detail changes Built in a pilot

    A changed bank account is the usual first step of payment fraud. A pilot would escalate the change to a reviewer and hold payments to the new account until it is confirmed. Tying those two documents together is the part that does not exist yet.

  • Invoice approval and payment release Built in a pilot

    A pilot would apply approval limits by role and amount to invoices an agent has matched and coded. Today's escalation already refuses a reviewer who took part in the decision; the invoice itself is not modelled.

  • Journal entries Built in a pilot

    A pilot would check agent-proposed journals against thresholds, period status, and who may post to which accounts before the entry is written, most likely through the JDBC or HTTP executor.

  • Purchase orders and vendor onboarding Built in a pilot

    A pilot would gate purchase-order release and new-vendor creation on the approvals your policy requires, with the decision recorded against the document number.

Talk through one of these

Agent actions

Platform and security teams giving AI agents access to tools that change money or records.

The agent recommends; the policy decides. In the payment demo the policy judges the request that would be sent, and the agent's own recommendation is recorded but never read by the policy.

Where this stands todayAgent tool calls are governed as events in the runtime, with a completed tool-audit run on synthetic records. No specific agent framework has been integrated: a proposal reaches StreamKernel over Kafka, REST, or a file, and there is no synchronous ask-and-wait API yet.

  • Tool calls as governed actions Demonstrated with synthetic data

    Normalize agent tool calls, classify risk, apply a policy decision, and write an audit record before the call affects a system.

  • High-impact action review Demonstrated with synthetic data

    Route refund approvals, customer-record access, workflow execution, and notifications to an operational, review, or dead-letter path according to policy.

  • Model routing with a budget Demonstrated with synthetic data

    Keep routine work on a local model, escalate to a more capable one only when required, and stop at a hard budget cap with a spend audit record. Shown in the agentic benchmark lane.

Talk through one of these

The same runtime also moves and enriches event data.

These lanes predate the payments and ERP focus and are still supported. They share the policy, provenance, and delivery behavior the action check is built on.

  • Pre-ingest enrichment

    Score and label records before they land in MongoDB Vector, Delta Lake, Snowflake, or Postgres.

  • PostgreSQL pgvector path

    Land text, embeddings, metadata, and lineage in a self-managed Postgres vector table.

  • OpenTelemetry intake

    Accept OTLP logs, metrics, or traces and apply policy, redaction, routing, and DLQ behavior.

  • Transport changes

    Swap Pulsar and Kafka sources without rewriting transform or sink logic.

  • Model promotion and rollback

    Promote an MLflow model during a run and fall back automatically when a fresh version degrades.

  • Multi-destination delivery

    One pipeline with consistent retry, DLQ, and metrics across Kafka, MongoDB, Postgres, Delta Lake, and Snowflake.

AI infrastructure paths Runtime architecture

Commercial path

Bring the action closest to yours.

A short review maps one action to the check, and says plainly which controls are enforceable today and which need pilot work.

Book a technical demo See commercial options