AI ACTION RELIABILITY

AI agents are becoming operators. Their actions need infrastructure.

AI has moved from generating information to changing the outside world — issuing refunds, booking appointments, writing to CRMs, provisioning accounts. When an action can change real state, reliability stops being a model problem and becomes a systems problem.

AI decides what to do. Struxum makes sure it actually happens correctly.
Get in touch See the issue
action · refund $500.00 → cus_X
intendedcreate action id ax_9f2c… — refund $500 → cus_X
dispatchedPOST stripe /v1/refunds
timeoutno response after 8s — outcome not returned
unknowndid the refund apply? blind retry is unsafe.
resolveread actual state from stripe…
confirmedrefund already applied — duplicate prevented
CONFIRMED SAFE RETRY REVIEW
THE ISSUE

The failure mode is changing.

When agents only produced text, a failure meant a wrong answer. Now agents commit side effects — and a new class of failure appears that text-quality metrics never see.

OLD FAILURE — the answer layer
“The model gave the wrong answer.”

Caught by evals, review, and better prompting. The world outside the model is untouched.

EMERGING FAILURE — the action layer
“The AI changed the outside world incorrectly, incompletely, twice — or without reliably knowing what actually happened.”

A timed-out call may have already committed. A “success” may have written the wrong business state. SUCCESS-or-ERROR is not enough.

THE UNKNOWN STATE

Between “sent” and “confirmed” is a gap most systems can’t see.

A consequential action can commit even when the caller receives a timeout. It can also look successful while the resulting state is wrong. That ambiguity is the center of the problem.

01 · intended

Decide

An AI billing agent decides to refund $500 to a customer.

02 · dispatched

Dispatch

The request is sent to Stripe. Then the connection times out.

03 · unknown

Unknown

Did the refund happen? The agent cannot tell. Retry may double-refund. Stopping may leave it incomplete.

04 · resolve

Resolve

Struxum turns the ambiguity into an explicit state that must be resolved before the agent continues.

Struxum makes UNKNOWN a state you resolve — not a coin you flip.
THE SOLUTION

A reliability layer at the action boundary.

Struxum sits between the agent and the systems it controls. It owns the reliability semantics around a consequential action, and leaves the agent and the underlying system exactly where they are. You don’t need Struxum because building reliability is impossible — you need it because building it yourself, for every action, is difficult, repetitive, and specialist work.

Struxum is

  • Infrastructure for reliable agent actions across external systems
  • The layer protecting the consequential side effect
  • An explicit answer to “did the intended action actually happen?”
  • Reliable, safe, recoverable, trustworthy — by construction

Struxum is not

  • An AI chatbot or an AI agency
  • An agent runtime or a workflow engine
  • An LLM observability / tracing product
  • A generic automation or governance platform
HOW IT WORKS

The action passes through one reliable boundary.

One node in your agent workflow. It treats the clean path and the ambiguous one the same way — every consequential action gets identity, verification and a recovery path, so a timeout is resolved instead of guessed.

BEFORE
AI Agent→External System

The agent talks directly to the system. When a call is ambiguous, the agent has to guess.

AFTER
AI Agent→Struxum→External System

Consequential actions pass through the reliability boundary. Ambiguity becomes a state that gets resolved, not guessed.

THE BOUNDARY

Doesn’t durable execution already do this?

Durable execution is real, and adjacent. Here’s the specific part it leaves to you — across every system your agents touch, not one.

Isn’t this just Temporal / Inngest / durable execution?
Durable execution guarantees your workflow survives crashes and resumes the step. What it doesn’t do on its own is tell you whether the external side effect already committed — that a timed-out write actually landed. Reconciling the workflow’s belief with the system’s real state — CRM, ERP, calendar, orders, a payment API — is left to you. That’s the boundary Struxum owns.
Isn’t this just idempotency keys?
They work — when the target system supports them, when you generate and persist one per action, and when you handle the ambiguous replay yourself. That’s engineering you rebuild for every system and every action. Struxum makes durable action identity and duplicate protection the default, across systems, not a per-integration chore.
Can’t I just add retry logic?
A blind retry after a timeout is the failure — it repeats the side effect: a duplicate order, a second booking, a double charge. The hard part isn’t retrying; it’s knowing whether it’s safe to, which means reading actual state before acting. Struxum turns the timeout into a resolved state instead of a guess.
We’re not replacing durable execution. Struxum sits at the action boundary beneath it — the part these tools hand back to you.
CORE CAPABILITIES

What the boundary actually does.

Struxum promises explicit state and safe handling of uncertainty — not universal exactly-once magic across arbitrary APIs.

Durable action identity
Retries and replays refer to the same logical intent, not a fresh side effect each time.
Explicit action state
Every action is INTENDED, DISPATCHED, CONFIRMED, FAILED, or UNKNOWN — never a bare success/error.
Duplicate protection
Blind repeated side effects are blocked before they reach the external system.
Timeout handling
A timeout does not silently become “failed.” It becomes a state that must be resolved.
UNKNOWN resolution
Available external evidence is checked before anything is retried or continued.
Recovery & reconciliation
Controlled paths for when execution is incomplete or inconsistent.
Outcome verification
Where the system supports it, actual state is compared against intended state.
Evidence
A readable record of what was intended, dispatched, observed, and resolved.
V1 — THE ACTION RELIABILITY NODE

Small enough to build. Concrete enough to demonstrate.

The first product should feel like infrastructure, not a new engineering project. You wrap the action — you don’t rebuild your agent.

struxum · apiresult
// wrap one consequential action
result = struxum.execute(action, parameters)

// lifecycle, handled for you
INTENDED   → create durable action id
DISPATCHED → send request
UNKNOWN    → response ambiguous
RESOLVE    → inspect external evidence
RESULT     → confirmed / retry / review
n8n is the entry point, not the company. The accessible first surface is an n8n node plus API. The long-term product is a neutral reliability layer that sits beneath AI agents regardless of framework or environment.

V1 RESPONSIBILITIES

  • 01Create a durable logical action identity.
  • 02Persist explicit action state.
  • 03Protect against blind duplicate execution.
  • 04Represent uncertain outcomes as UNKNOWN.
  • 05Resolve UNKNOWN using available external evidence.
  • 06Retry only when the action is known safe to retry.
  • 07Return a deterministic result the workflow can act on.
  • 08Provide a human-readable record of the decision.
WHERE IT APPLIES

Different systems. The same primitive.

BILLING · STRIPE

The refund that timed out

An agent refunds $500; the response times out. Struxum marks the action UNKNOWN, reads Stripe’s actual state, and returns confirmed, safe-retry, or review — never a blind double refund.

action://refund → resolve
CRM · SALES

The $50k opportunity write

An agent creates an opportunity for ACME, sets the stage, assigns the rep. Struxum protects the write and, where supported, verifies the record matches what was intended.

action://crm.write → verify
APPOINTMENTS · CALENDAR

The booking on WhatsApp

A patient asks to book Tuesday at 3 PM. If the booking call is ambiguous, Struxum resolves external state, blocks an unsafe duplicate, and returns a deterministic result before the reminder fires.

action://booking → resolve

Stripe, the CRM and the calendar are examples of one underlying primitive — not three separate company theses.

THE OPPORTUNITY

This is about to become required infrastructure.

AI agents are moving from giving answers to taking actions. The reliability of those actions is becoming a layer of its own.

THE PROBLEM

The moment an action can change real state, a timeout stops being a retry and becomes a question nobody can answer: did it happen? Every agent that touches a real system hits this.

THE SHIFT

As agents go from assistants to operators, reliability at the action boundary stops being optional. The way durable execution became standard infrastructure, this becomes standard — the layer every serious agent has to sit on.

THE ANSWER

Struxum is that layer. Durable action identity, explicit state, duplicate protection, resolution of the unknown — so a consequential action is safe to execute, retry, verify and recover, across every system an agent touches.

“When your AI agent times out after dispatch, do you know whether the action already happened?”
The agents are already here. The actions are already happening. The reliability layer beneath them is what gets built next — and Struxum is building it.
LONG-TERM VISION

From a reliable action to a reliability plane.

V1

Reliable execution state

Action identity, duplicate-safe retry, UNKNOWN state and resolution.

V2

Recovery

Partial-execution handling, recovery flows, and human escalation.

V3

Cross-system reliability

Reconciliation, preconditions, and postconditions across systems.

V4

Outcome assurance

Independent outcome verification, evidence, and discrepancy detection.

V5

AI Action Reliability Platform

A neutral reliability plane across agent frameworks and systems.

These are directional stages, not features that exist today.

Whenever AI is allowed to change something important, Struxum is the reliability layer protecting that action.
FOUNDER

I’m building this around a specific thesis.

I believe that as AI agents start changing real systems, the reliability of those actions becomes infrastructure. I found the problem, wrote the thesis, and pressure-tested it against what already exists — durable execution, idempotency keys, retry logic — to find the part they leave to you. That gap is what Struxum owns.

I’m Farhan. I left medicine to work on this full-time. What I bring is problem obsession, direct customer discovery, and the network to open doors to the first design partners. What I’m not is the engineer who builds it — that’s who I’m looking for.

If you’re a strong builder who wants to own how a reliability layer for AI actions gets built, from the first Struxum node to real design partners, let’s talk.

Farhan, founder of Struxum
Farhan
Founder · Struxum · Kuala Lumpur
Get in touch LinkedIn Email