AI ACTION RELIABILITY

Your AI agent just changed a real system. Do you know it worked?

AI agents are becoming operators, they act, not just answer: booking a slot, updating a record, sending a message, placing an order, provisioning an account. The moment an agent can change real state on its own, 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.

Same class of failure, several shapes, in any system:
NEVER HAPPENED

Dispatched, but you can’t confirm it landed.

HAPPENED TWICE

A blind retry repeated the side effect.

HAPPENED WRONG

It reported success but changed the wrong state.

LEFT HALF-DONE

A multi-step action stopped partway.

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 sales agent creates a $50k opportunity in the CRM.

02 · dispatched

Dispatch

The write is sent to the CRM. Then the connection times out.

03 · unknown

Unknown

Did the record get created? The agent cannot tell. Retry may create a duplicate opportunity. Stopping may lose the deal.

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.

TRUST ACTIONS. ENABLE AGENTS.
HOW IT WORKS
From intent to real-world impact.
One node for every agent action, across bookings, CRM, payments and ERP.
1
AI Agent
Decides to take a real-world action
Book this customer for Tue, 3:00 PM
2
Prepare Action
Agent sends action details to Struxum
{
  "action": "booking",
  "slot": "Tue 15:00",
  "resource_id": "cal_88"
}
3
Struxum Node
Validates, executes and verifies the action
Check rules & permissions
Execute with safeguards
Verify outcome
Log for audit
4
Verified Result
Returns confirmed outcome to agent
Confirmed
Booking created
booking_idbkg_4471
verifiedtrue
5
Agent Continues
Proceeds with next step in the workflow
Appointment booked. Reminder scheduled.
Next: Send confirmation message
BUILT-IN RELIABILITY
RETRIES · DEDUPLICATION · AUDIT TRAIL · ERROR RECOVERY
SAFETY FIRST
Policy and permission checks
IDEMPOTENT
Prevent duplicate actions
RESILIENT
Retries and graceful recovery
FULL AUDIT TRAIL
Trace every action
REAL-WORLD READY
Works with your existing tools
AI ACTION RELIABILITY FOR THE AGENT ECONOMY.STRUXUM.IO
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.
WHY NOW

The field is naming the same wall.

For years the race was raw capability, can the model reason, can it code. In 2026 the research is converging on a different limit: reliability, not intelligence, is what stops agents from running unsupervised. A single successful run proves nothing; what matters is whether an agent does the same thing, safely, every time it touches a real system.

Struxum works one specific, high-stakes slice of that problem, the consequential action, and whether it actually happened. Not the whole science of agent reliability; the part where a wrong answer costs real money.

RESEARCH, PRINCETON, 2026

“Towards a Science of AI Agent Reliability” evaluated 15 models and found recent capability gains have yielded only small improvements in reliability, arguing that a single success metric hides the operational failures that matter. arXiv:2602.16666

LONG-TERM VISION

From a reliable action to the AI trust layer.

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

The AI Trust Layer

Reliability, verification, evidence and policy, across every action an AI takes, in any system.

These are directional stages, not features that exist today.

Whenever AI is allowed to change something in the real world, Struxum is the trust layer standing behind 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