For Technical Teams

How Reqursor works, in technical detail

This page is for developers and technical leads at agencies. It explains how Reqursor turns a request into a running store and what keeps every change safe. For the plain overview, see Features.

Reqursor is an AI platform with two distinct layers. The AI layer interprets natural language, generates store declarations and proposes changes. The deterministic engine validates, executes, verifies and recovers, so only validated changes reach a store.

The boundary between these layers is the Git commit. Above it, everything is non-deterministic and human-gated. Below it, everything is deterministic, auditable and can be rolled back.

Core Pipeline

From Intent to Running Store

Every AI action follows the same path: generate → validate → commit → plan → apply → reconcile. Same inputs, same result, every time.

  1. 1. AI Generates

    The agency describes what it wants in plain language. AI produces a structured store declaration conforming to the adapter schema.

  2. 2. Validate

    Three validation tiers: stateless per-file, stateless cross-file, and stateful checks against the platform and adapter schemas. Invalid output is rejected before any mutation.

  3. 3. Git Commit

    Confirmed declarations are committed to Git: the boundary between non-deterministic AI and deterministic execution. Everything below is reproducible.

  4. 4. Plan → Apply

    The Runtime reads desired state at an explicit SHA, generates a deterministic operation graph and executes it. No dynamic decisions during apply.

  5. 5. Reconcile

    Observed state is compared against expected state. Convergence or divergence is reported as structured evidence. Drift is surfaced, not ignored.

Desired State as Code

Your team can review, diff and roll back any change, because every store is defined by a set of versioned files in Git. The AI generates these files, and the engine consumes them.

  • Store Definition Schema

    Every store is a set of versioned files in Git: store-definition.yaml, pinned-refs.yaml, design-tokens.json and pages/*.json. The schema is normative: unknown fields are rejected, and null values are forbidden.

  • Immutable Version Pinning

    Every artifact (runtime, adapter, container images) is referenced by SHA-256 digest. No floating tags, and no "latest". Every deployment is traceable to exact artifact versions.

  • Git as Source of Truth

    Every change (AI-generated, human-authored or migration-produced) is an auditable Git commit. Rollback is deploying a prior SHA. The Runtime never reads from anything other than an explicit revision.

store-definition.yamlExample data
store_id: "example-store"
tenant_id: "example-agency"
domain: "shop.example.com"

adapter_ref:
  name: "example-platform"
  digest: "sha256:9f86d08..."

runtime_ref:
  digest: "sha256:a1b2c3d..."

resource_profile: "standard"
secrets_ref: "vault://example-agency/example-store"

# AI-generated, human-confirmed, Git-committed
# Deterministic from here.
Example: an illustrative store declaration with placeholder values.

Deterministic Engine Guarantees

These guarantees decide what reaches a production store. The AI proposes; the engine applies only what passes every check, and every change can be traced and reverted.

  • Validation Before Mutation

    AI errors are caught before any infrastructure change occurs. The engine never applies state that fails validation.

  • Per-Store Isolation

    Dedicated network, volumes, containers and resource limits per store. One store's failure cannot affect another. Structural, not configurable.

  • Continuous Drift Detection

    Observed state is compared against declared intent across topology, pinning, policy and platform configuration. Silent degradation is surfaced automatically.

  • Safe Rollback

    Any committed state is a valid rollback target. Managed configuration and artifacts revert; business data (orders, customers, media) is never affected.

Store Platforms

One AI and one engine, with a versioned adapter per store platform. Reqursor works with one widely used store platform today, and support for more store platforms is on our roadmap.

Adapter Model
  • Supported today

    One widely used store platform

    Full adapter: schema declarations, topology (app, database and cache containers), plan operations, reconcile probes and validation. AI reads the adapter schema to constrain its output.

    • Design token injection via CSS custom properties
    • Block Registry with parameterized page composition
    • Managed configuration for platform config files and extension settings
  • On the roadmap

    More store platforms

    Each new adapter extends platform reach without changing the AI layer, the Control Plane or the Runtime. Tell us what your clients' stores run on when you request early access.

Run more stores with the team you already have

Moving your stores is free. We earn when we run them. Early access starts with a pilot, so you can see Reqursor run your own stores before you choose a plan.