Cyntex Documentation

Your data is stale. Your AI knows it.

The Problem with Your Current Stack

Most data stacks work like this: a nightly ETL job extracts data at midnight, loads it into a warehouse by 3am, and a dashboard refreshes at 7am. Your AI agent makes decisions at 9am — on 9-hour-old data.

Meanwhile your competitors are acting on data that’s 150 milliseconds old.

🔴 Spaghetti ETL

Hundreds of brittle, point-to-point pipelines. One schema change in Oracle breaks a dozen downstream jobs simultaneously.

🔴 Batch blindness

Fraud detection that fires hours after the transaction. Clinical alerts that lag behind the ICU monitor. Inventory that double-books because two systems synced at midnight.

🔴 Frankenstein stack

Debezium + Kafka + Flink + a warehouse — five teams, six SLAs, a Kafka incident at 2am. Powerful, but you need a dedicated platform team just to keep it running.

🔴 AI agents flying blind

Your LLM is only as good as its context window. If the context is stale, the decision is wrong — no matter how smart the model.

Why Cyntex

One platform, millisecond latency

CDC capture → transform → materialize → serve. Log-based, non-intrusive. Zero impact on your Oracle, MySQL, or Mainframe production systems.

YAML-first, no drag-and-drop

Every pipeline is a .cyn.yml file. Version-controlled, diff-able, reviewable. AI agents write them. Humans review them.

connector: mysql
mode: cdc
config:
  host: db.prod
  database: orders

BYO AI agent — model-agnostic

No bundled LLM. Connect Claude, GPT-4o, or Gemini via MCP. Your agent creates pipelines, monitors lag, and queries live materialized views — all through a standard protocol.

Replace the Frankenstein stack

Get 80% of Kafka + Flink capability with 20% of the operational overhead. See the full comparison →

See It in Action

A real-time customer 360 view — MySQL CDC → enrich → MongoDB — in one file:

apiVersion: cyntex/v1
kind: source
id: mysql-prod
connector: mysql
mode: cdc
config:
  host: db.internal
  port: 3306
  database: production
  username: ${MYSQL_USER}
  password: ${MYSQL_PASS}
---
apiVersion: cyntex/v1
kind: pipeline
id: customer-360
source: mysql-prod
tables:
  - name: customers
  - name: orders
  - name: support_tickets
transforms:
  - name: active-only
    filter: "record.status != 'deleted'"
  - name: normalize
    rename:
      customerId: id
      fullName: name
sync:
  - source: customers
    target:
      collection: customer_profiles
    options:
      write_mode: upsert

cyntex validate customer-360.cyn.yml   # three-layer offline validation
cyntex apply   customer-360.cyn.yml   # deploy to running Cyntex

That’s it. No Kafka cluster. No Flink job. No separate CDC tool to operate.

Start Here

What is Cyntex? The Data Freshness Gap, Operational Data Hub concept, and where Cyntex fits.

Architecture Four-layer runtime: Engine → Store → Serve → Manager. With diagram.

Cyntex vs. The Streaming Stack Honest comparison: Debezium + Kafka + Flink vs. Cyntex. When to use which.

DSL Grammar Reference Complete .cyn.yml syntax — source, pipeline, transforms, serve.

Connector Reference MySQL, PostgreSQL, Oracle, MongoDB, Kafka, and more — with DSL config examples.

AI Integration MCP server, llms.txt, and the BYO-agent authoring workflow.