DEV Community: Sugunah

I let a coding agent build my analytics — here's the guardrail system that made it safe

Sugunah — Sun, 15 Nov 2026 07:36:08 +0000

Dex by Exmergo, hands-on. Independent notes; not affiliated with Exmergo. Links to my free cheat sheet and starter pack are at the end.

An agent with warehouse access runs two meters at once: the warehouse bill (bytes scanned, compute seconds, DBUs) and the token bill. Most "AI analytics" demos quietly ignore both. Dex by Exmergo — open source, Apache 2.0 — is a tool that treats both meters as design constraints. Here's how the system works, based on the official docs, the open-source engine, and its public benchmark repo.

The loop: Explore, Transform, Maintain

Dex installs into your coding agent (Claude Code as a plugin; Codex, Cursor, Gemini CLI via skills) and gives it three commands:

/dex:explore — read-only profiling. It ranks tables, profiles columns from aggregates, infers and verifies joins, establishes each table's grain, and flags PII columns (flagged, never surfaced). The map is cached locally in .dex/, so the next session doesn't re-scan — or re-bill — your warehouse.
/dex:transform — ask for a metric and you get a plan, then diffs: dbt SQL models, schema tests, docs, and the semantic layer on top (MetricFlow, Apache Ossie, SLayer, Cube, Snowflake Semantic Views, or Databricks Metric Views). Builds validate against dev targets only.
/dex:maintain — diff the project against your .dex/ baseline and get drift reports on four axes: schema, volume, grain, semantic — each with a proposed fix you review before anything merges.

The part I didn't expect: semantics as code

The November "Dex Semantics" release adds declarations to analytical models: what a row means, what a join does to row counts, how a number is allowed to add up, and which business assumptions a metric rests on. They live in your models, in your repo — and they flow forward into the next agent session, which is exactly where unaided agents usually re-guess your conventions and get them wrong.

The test worth running on your own data (the starter pack below walks through it step by step): ask a fresh agent session for a metric that depends on one of your conventions — refund timing is the classic — once without the semantic context and once with it, and compare the corrections you have to make. That's your personal version of the benchmark. Exmergo's own ADE-bench numbers (80% vs 73.3% task success, Sonnet 5.5) are vendor-reported and linked from their site if you want the methodology.

The guardrails, concretely

Read-only against source data; reads pass a SQL/cost guard.
Dry-run first: billed scans return a needs_confirmation estimate and run only with an explicit budget (e.g. --confirm --budget <bytes> on BigQuery), capped server-side. Over-ceiling calls are refused outright.
A spend ledger you can read: .dex/spend.jsonl, one record per billed call.
Credentials are discovered, never collected: BigQuery via ADC, Snowflake via connections.toml/env/dbt profile. Dex never asks for a key — if your agent ever asks you to paste one, stop; something else is wrong.
PII containment: flagged columns stay out of the model's context.

Try it in 10 minutes (free)

# Claude Code, one command at a time
/plugin marketplace add exmergo/exmergo-agent-plugins
/plugin install dex@exmergo

# or the Python engine with the zero-credential DuckDB on-ramp
pip install "exmergo-dex-core[duckdb]"

Start on a local DuckDB file. Prove the loop at $0 before any agent touches a billed warehouse — that ordering is the whole trick.

Honest limits

Dex is early and under active development; connector maturity varies (check the PyPI page for exmergo-dex-core). There are also at least four other products called "Dex" — make sure you're installing Exmergo's (exmergo/dex on GitHub).

Free: I condensed the install, the three commands, all 8 connectors, and the 6 safety rules into a one-page cheat sheet: https://sugukavi.gumroad.com/l/lytoz

Full starter pack: an 18-section tutorial, 12 copy-paste agent prompts, and 3 workflow worksheets (source onboarding, metric requests, weekly drift log): https://sugukavi.gumroad.com/l/jzgaqk

Disclosure: the pack is my own independent product, sold on Gumroad. The cheat sheet is free and covers the essentials.

I connected Claude to AXL's MCP server — exact setup, the safety model, and the first loop I built

Sugunah — Sun, 15 Nov 2026 07:35:58 +0000

AXL hit #1 Product of the Day on Product Hunt on Nov 8, and most of the discussion was about "all-in-one marketing." The more interesting part, to me, is the plumbing: AXL exposes its whole stack — pages, CRM, email, webinars, courses, payments — to your own AI assistant through a remote MCP server. I connected Claude and built my first loop. Here's exactly how it works, including the parts the launch posts skip.

The setup (verified against docs.axl.tech/mcp)

One server address for every account:

https://app.axl.tech/mcp

It's also in your AXL account under Settings → MCP, with per-client steps. There is no API key to paste into chat — connection is browser OAuth sign-in. Per client:

Claude (web/desktop): Customize → Connectors → Add → Custom → Web → name it AXL, paste the address, sign in in the browser, enable the connector in your conversation.
Claude Code: claude mcp add --transport http axl https://app.axl.tech/mcp
ChatGPT: Plugins → + → Add custom MCP server → paste the address, OAuth.
Codex: codex mcp add axl --url https://app.axl.tech/mcp
Cursor, Windsurf, VS Code, Cline follow the same remote-server pattern.

Verify before you build: my first prompt was read-only — "list my CRM pipelines and find the contact with [my test email]. Do not create or change anything." If your agent can't read your real test data, don't hand it build tasks yet.

How it actually works: meta-tools, not 1,200 loaded tools

AXL advertises 1,200+ actions (their number). Your AI does not load 1,200 tool definitions into context. Per the co-founder's explanation, the server exposes a small set of meta-tools: the agent searches a live operation catalog, reads only the one schema it needs, then executes it — with your account's permissions, over Streamable HTTP.

Two consequences worth knowing:

Outcome briefs beat operation names. "Build a draft registration page for X, show me a preview, do not publish" works. Guessing an operation name and insisting the agent call it gets you confident nonsense.
The connected AI is a staff member with your keys. Per the founders' walkthrough, 21 sensitive operations are kept off the AI surface (no token minting, no admin-permission changes, no billing writes), and publishing / sending / calling / spending are separate steps the agent prepares but shouldn't silently execute. Keep it that way: default every brief to draft, and make publish a second, explicit instruction from you after review. The authorization is currently one broad account-scoped grant, so disconnect clients you stop using (Settings → MCP).

The first loop I built

Not "my whole business." One loop:

Landing page (one ask) → form (name, email, one question)
→ contact in CRM with a source tag → welcome email (draft, reviewed, then activated)

The step everyone skips: submit a test signup yourself, then find that contact in the CRM and confirm the form answers saved. "The page looks done" is not verification. A findable CRM record is. AXL's own open-source skill (axlhq/business-stack) uses the same test — good instinct, worth copying whether or not you use the skill.

Pricing context, since it decides whether this is worth your weekend: the Free plan is permanent (500 contacts, 5,000 emails + 5,000 messages/mo, no card, hard limits). Paid starts at $49/mo; every plan includes the full platform — tiers change usage and admin seats, not features. AXL says it takes 0% of sales; your payment provider's fees still apply, and AI credits / overages are a real budget line. Judge vendor headline numbers (the 1,200+ count, the lead-scoring model's training claims) the way you'd judge any vendor's: on what the tool does in your account, on your offer.

Steal this

I turned my setup notes into a free one-page cheat sheet — the loop checklist, the 2-minute MCP connection for each client, and my first 3 prompts (verify / build-as-draft / audit):

👉 Free cheat sheet: https://sugukavi.gumroad.com/l/eqvqjt

And if you want the full system — 18-section tutorial, 12 GTM play templates, 15 MCP prompts, plan math, troubleshooting — it's in my starter pack here: AXL — Getting Started Pack

Disclosure: the pack is my own independent guide — not affiliated with or endorsed by AXL. The cheat sheet is free either way.

Full, Incremental, or CDC? How to Pick a Read Mode in Filament by Galaxy (and Why CDC Won't Run on Your Laptop)

Sugunah — Sun, 15 Nov 2026 05:49:58 +0000

Filament by Galaxy launched on Product Hunt on November 13 and hit #2 Product of the Day. It's an open-source (Apache 2.0) data movement engine written in Go: you define connections, resources, and pipelines, and it replicates data from databases, APIs, and streams into warehouses, lakes, and other databases — from a terminal CLI, or driven by an AI coding agent.

(Quick disambiguation, because it matters: this is Filament by Galaxy, the data engine. It has nothing to do with FilamentPHP, the Laravel admin framework.)

If you try it, you'll hit one decision before anything else, and it's the decision that determines whether your pipeline is correct or quietly wrong: how each resource is read. Filament gives you three read modes — full, incremental, and cdc — and pairs each with a write mode (replace, append, upsert, merge). This post is the short version of how to choose, including the two traps that bite almost everyone.

The three read modes

full reads every selected row, every run. It's the easiest mode to reason about and the easiest to verify: pair it with replace and the sink is a fresh snapshot of the source. It also sees deletes naturally, because a deleted row simply isn't in the next rebuild. For small tables, nightly reporting rebuilds, and your first week with the tool, this is the right default.

incremental reads only rows past a saved cursor — typically rows whose updated_at is newer than the last run's watermark. It's how you keep a large table fresh every few minutes without re-reading it. The requirements are strict, though: the table needs a primary key, plus a NOT NULL timestamp-style cursor column that genuinely advances on every insert and update. If one code path in your app updates a row without touching that column, that change is invisible forever.

cdc reads the ordered change stream from the database log itself — PostgreSQL logical replication, or the MySQL binlog. Inserts, updates, and deletes all arrive as events, in order. This is the only read mode that sees hard deletes and preserves change order, which is why it's the mode everyone wants. It's also the mode with the most setup attached, which brings us to the traps.

Trap 1: Incremental reads cannot see deletes

This is the one that produces silently-wrong dashboards. A hard delete removes the row — and an incremental read works by reading rows. No row, no event, nothing to propagate. Your destination keeps the deleted row forever, and nothing errors.

So the rule is simple: if deletes must disappear from the destination, you need either full + replace (rebuild and swap) or cdc + merge (apply deletes as they happen). incremental + upsert — the combination most people reach for first — keeps a "current state" table that is current except for deletions. Know that before you ship it, not after someone audits the numbers.

Trap 2: CDC does not run on the local CLI

This one surprises people because the local CLI feels complete: you can install Filament, run a pipeline in about five minutes with no database at all, and replicate PostgreSQL → ClickHouse from your laptop. Then you switch a connection to CDC and the run fails, complaining it can't durably admit replication streams.

That's by design. CDC pipelines need Filament's PostgreSQL-backed datastore to track replication stream state durably. The local CLI context uses SQLite, which isn't enough — so CDC means deploying Filament as a server first, then creating the source as a CDC connection (it's a property of the connection, not a per-table toggle, and a CDC route is CDC for the whole run; you can't mix CDC and standard resources in one pipeline).

CDC also asks things of your source database. On PostgreSQL: logical replication, a publication over the tracked tables, a replication slot, and a primary key on every tracked table — plus REPLICA IDENTITY FULL if updates to large columns need to carry old values. On MySQL: 8.0+, binlog available over TCP (a Unix-socket DSN is rejected for CDC), and binlog retention longer than the longest gap between your runs, or positions expire and the fix is a re-snapshot.

And a few operational truths worth knowing in advance: a replication slot can only be read by one consumer at a time ("slot is active" means something else is holding it); a slot nobody reads makes WAL grow on your source, so when you delete a CDC pipeline, check for orphaned slots; and CDC support on a connector doesn't automatically mean continuous (always-on) support — check the connector's page.

The cheat sheet

Goal	Read	Write	Watch out for
Rebuild a reporting table nightly	`full`	`replace`	A failed run restarts that resource from the beginning
Keep a big table fresh every few minutes	`incremental`	`upsert`	Hard deletes are invisible; the cursor column must really advance
Keep an audit history of every change	`cdc`	`append`	Deletes appear as events; rows are not removed
Maintain a live replica, deletes included	`cdc`	`merge`	Needs a primary key; runs on a deployment, not the local CLI

One more thing in Filament's favor: it validates the read/write pairing before any data moves — source policy, sink capabilities, primary keys, cursor configuration. An invalid combination is rejected up front instead of corrupting data halfway through. When a create command fails validation, read the error; it's usually telling you exactly which requirement is missing.

Going further

I spent a few days reading Filament's official documentation end to end — it's good, but it's spread across dozens of pages, and the decisions above sit scattered between concept guides and how-tos. I turned my notes into a starter pack: a 14-section plain-English tutorial (including a full PostgreSQL → ClickHouse walkthrough and a troubleshooting table for the errors new users actually hit), 12 copy-paste prompts for driving Filament with an AI coding agent safely, and 3 workflow templates. It's $19 on Gumroad if you want the distilled version: https://sugukavi.gumroad.com/l/kgocba

Disclosure: the pack is an independent guide, written from the official docs and the open-source repo. It is not affiliated with or endorsed by Galaxy. Filament itself is free and open source — the docs are there if you'd rather assemble all of this yourself.