Axtor.App

How Axtor works

From proposed action to runtime decision.

Axtor evaluates a proposed AI action across scope, intent, evidence, policy, authority, and risk before execution. It can allow the action, block it, request clarification, or require approval.

See the Flow Explore a Pilot

Currently in development.

Illustrative scenario

Customer request

“I was charged even though the service was down.”

Proposed action

Refund $750

Proposed

Axtor Control Engine

Outcome: CLARIFY

Reason: “Which charge does the customer mean?”

The decision behind the action

Permission is only one part of the decision.

A proposed AI action should not execute simply because the agent has technical access or one internal permission allows it.

The right target

Which transaction, order, account, or record does the request refer to?

The right action

Does the proposed action actually address the intended problem?

The right scope

Does the amount, privilege, record set, or state change stay within the request?

Capability Can the agent technically perform the action?

Permission Does the agent have access to the required tool or system?

Runtime Control Does the action have sufficient support across each control dimension?Scope · Intent · Evidence · Policy · Authority · Risk

Axtor evaluates the proposed action before deterministic enterprise controls decide whether and how execution can proceed.

Control context

The same action can require a different runtime decision.

Axtor evaluates only the context relevant to the proposed action. Changes in the acting entity, transaction, agreement, jurisdiction, delegation, or risk can change the control outcome.

  1. 01

    The agent proposes an action

    Start with the action the AI agent wants to execute, such as refunding $75 tax for transaction TX-28491.

  2. 02

    Axtor gathers relevant context

    Build the evidence chain connected to the proposed action through agreed integrations. The chain defines the scope, not the enterprise’s entire historical dataset.

  3. 03

    Evaluate six control dimensions

    Evaluate scope, intent, evidence, policy, authority, and risk using the inputs relevant to this action.

  4. 04

    Return a runtime outcome

    Return ALLOW, BLOCK, CLARIFY, or APPROVAL with reasons, supporting references, and unresolved gaps.

  5. 05

    Enterprise controls enforce execution

    Existing controls apply deterministic permissions, approvals, and execution boundaries. Axtor does not execute the action.

Context can change the runtime decision.

Explore which inputs become relevant. These fictional variations do not determine real legal obligations.

Connect the original action context

Connect the human instruction, acting entity, affected customer, transaction, invoice, governing agreement, policy, and risk inputs relevant to this action.

Relevant control inputs

Enterprise

  • Refund policy
  • Agent delegation
  • Approval limits

Contractual

  • Customer agreement
  • Transaction terms

Regulatory

  • Tax rules
  • Privacy obligations
  • Sector regulation

Jurisdictional

  • Acting legal entity
  • Customer / affected party
  • Transaction location
  • Cross-border context

User IP or current location alone does not determine jurisdiction. The acting entity, affected parties, action, agreement and evidence must be considered together.

Depending on scope, authority inputs may include financial or tax rules, privacy obligations, AI and sector regulation, or relevant cross-border, treaty and trade constraints. These are possible sources, not claims of implemented regulatory integrations.

Semantic assessment

Does the proposed action match sufficiently established human intent and relevant evidence?

Deterministic control inputs

Do policy, permissions, limits, delegation, contracts, and other trusted constraints support the action?

The runtime decision combines semantic assessment with deterministic or trusted control inputs. Missing, conflicting, or unvalidated inputs remain visible. Configured enterprise controls still enforce permissions, approvals, and execution boundaries.

Runtime control walkthrough

See how context changes the runtime decision.

Explore how human intent, relevant evidence, policy, authority, and risk shape the control outcome for a proposed AI action.

Clear intent. Is authority established?

Illustrative tax-refund scenario. It demonstrates runtime control evaluation, not a conclusion about real tax law.

Illustrative workflows using fictional data.

Static preview. Read all five stages or press Play.

  1. 01

    Proposed action

    Current step
    Originating human request
    “Why was Indonesian tax charged? Please refund it.”

    Refund $75 tax for transaction TX-28491

    Axtor starts with the consequential action the agent proposes, not with tool access alone.

  2. 02

    Action context

    Seller legal entity

    Company in Indonesia. Acting entity identified in the fictional transaction.

    Customer / affected party

    Customer context: United States. This fact alone does not determine applicable tax rules.

    Transaction

    TX-28491 · Digital service · $75 tax component.

    Invoice + agreement

    Linked invoice and transaction terms require validation before any tax adjustment.

    Conversation + account

    The refund request is linked to this transaction and affected customer account.

    Agent identity

    Support agent acting for the seller. Delegation and limits supplied by enterprise controls.

    Axtor retrieves the evidence chain connected to the proposed action through agreed integrations. It does not search all enterprise history.

  3. 03

    Control inputs

    Enterprise authority

    Fictional refund limit: $1,000. The proposed $75 is within the agent limit; that is only one input.

    Contractual authority

    Validate the customer agreement and transaction terms governing the proposed adjustment.

    Regulatory authority

    Tax treatment requires a trusted validation input. No tax-law conclusion is supplied by this demo.

    Jurisdictional context

    Consider the seller entity, affected customer, digital service, place of supply and evidence. IP address alone is not determinative.

  4. 04

    Runtime evaluation

    Intent
    • Refund requested
    • Transaction identified
    Enterprise authority
    • Refund amount is within agent limit
    Context
    • Seller legal entity identified
    • Customer context identified
    • Transaction identified
    External authority
    • Tax treatment requires validation
    • Additional transaction or invoicing evidence may be required

    Semantic assessment is separate from deterministic enforcement. Trusted control inputs define constraints; a language model does not invent legal permission.

  5. 05

    Runtime outcome

    APPROVAL

    Customer intent is clear, but the tax treatment requires trusted validation or approval before execution.

    Audit / reason trail
    1. Intent: customer request identifies the tax component on TX-28491.
    2. Enterprise input: $75 is within the fictional $1,000 limit.
    3. Unresolved authority: tax treatment and linked invoicing evidence need validation.
    4. Next step: route the proposed adjustment and evidence to the responsible review workflow. No refund is executed.

    Illustrative product decision only. No action is executed and no real legal or tax determination is made.

All stages remain visible while playback highlights the sequence. No action is executed.

Evidence scope

Follow the relevant records.

Axtor should evaluate only the records connected to the proposed action. Transaction IDs, account identifiers, support cases, conversations, and previous resolutions help define the relevant evidence chain.

If records are missing or their connection is unclear, that gap should remain visible in the assessment.

Evidence access is scoped to the agreed workflow and available integrations.

Illustrative record connections
  • Transaction identifierTX-B
  • Linked support caseSC-218 → TX-B
  • Relevant conversationCV-031
  • Previous resolutionCR-050

Runtime outcomes

Four ways Axtor can respond.

ALLOW

The proposed action has sufficient support to proceed to enterprise execution controls.

BLOCK

The proposed action conflicts with established scope, evidence, policy, authority, or other control requirements.

CLARIFY

Intent or required evidence is not sufficiently established.

APPROVAL

The action may be valid, but a human or higher authority must approve it before execution.

Each outcome includes reasons and the control inputs used. Enterprise systems remain responsible for execution.

How Axtor Fits

An additional check within your existing workflow.

An integration defines where proposed actions are submitted, which evidence and control inputs are available, and how runtime outcomes return to your workflow.

Proposed integration flow

The customer service platform or AI agent sends a request and proposed action to Axtor. Axtor returns a runtime outcome and reasons to enterprise authorization controls. Business systems execute only if permitted and approved.

01

Customer service platform or AI agent

Handles the conversation and proposes an action.

Request + proposed action
02

Axtor Control Engine

Runtime control

Evaluates the proposed action across scope, intent, evidence, policy, authority, and risk.

Inputs linked to the request and proposed action

Relevant evidence

  • Conversations
  • Transactions
  • Support cases
  • Account data

Relevant records are supplied or retrieved through agreed integrations.

Control context

  • Enterprise policies
  • Delegated authority
  • Contracts
  • Jurisdiction and regulatory constraints

Control inputs are supplied through agreed, trusted integrations and enterprise systems.

Axtor evaluates the proposed action against the relevant evidence chain and control context that applies to that action.

Runtime outcome + reasons
03

Your execution controls

Enforce configured permissions, deterministic constraints, and required approvals.

If permitted and approved
04

Your business systems

Execute the action if all required checks pass.

An Axtor runtime decision does not itself execute an action. Existing enterprise controls remain responsible for deterministic permissions, approvals, and execution boundaries.

An initial pilot

Start with one workflow.

  1. 01

    Define the action boundary

    Choose the proposed actions, their intended scope, common ambiguities, and outcomes to evaluate.

  2. 02

    Map the evidence

    Identify relevant records, their connections, and access requirements.

  3. 03

    Evaluate in shadow mode

    Assess proposed actions without controlling live transactions. Review the findings together and identify what needs improvement.

Explore a Pilot Contact Us