# MovingLake's Bidirectional Connectors: How Real-Time ETL Agents Skip the Data Warehouse > Source: > Published: 2026-10-15 10:06:06+00:00 Most reverse ETL tools assume you already have a data warehouse. You extract from production systems, load into Snowflake or BigQuery, transform in dbt, then push enriched records back to your CRM. MovingLake skips the warehouse entirely and pipes data straight from APIs to destination systems in both directions. For agentic workflows that need to read from third-party APIs and write decisions back to production databases without manual orchestration, this architecture exposes new failure modes and design trade-offs. MovingLake provides bidirectional data connectors that handle both traditional ETL (API to Snowflake) and reverse ETL (warehouse or API directly to CRM) in real time. The core claim is that you can move data between systems without staging it in a central warehouse first. **Key capabilities:** This matters for agent-driven workflows because agents often need to: Traditional ETL pipelines batch these steps hourly or daily. MovingLake targets sub-minute latency. The standard reverse ETL flow looks like this: ``` Production DB → Fivetran → Snowflake → dbt → Census → CRM ``` MovingLake collapses it: ``` Production DB ↔ MovingLake ↔ CRM ``` **How it works under the hood:** No intermediate warehouse means no dbt transformations, no SQL-based business logic layer, and no single source of truth. You trade centralized data modeling for lower latency and fewer moving parts. "Real-time" in ETL contexts usually means one of three things: | Mechanism | Latency | Agent Suitability | Failure Mode | |---|---|---|---| | **Webhooks** | Sub-second | Best for event-driven agents | Missed events if endpoint is down | | **Change Data Capture (CDC)** | 1-10 seconds | Good for database sources | Requires database-level permissions | | **API Polling** | 30-300 seconds | Acceptable for batch-like agents | Rate limits, stale data between polls | MovingLake likely uses a mix depending on the connector. Salesforce supports webhooks via Platform Events. PostgreSQL supports CDC via logical replication. Stripe requires polling unless you configure webhook endpoints. For an agent that needs to update a CRM record after processing a payment, webhook-based sync means the agent sees the payment event within seconds. Polling-based sync means the agent might wait up to five minutes, which breaks real-time decision loops. Bidirectional sync introduces a classic distributed systems problem: what happens when the same record changes in both systems between sync cycles? **Example scenario:** `contact.status = "lead"` from HubSpot at 10:00:00`contact.status = "qualified"` and writes to HubSpot at 10:00:05`contact.status = "unqualified"` in HubSpot at 10:00:03 **Common resolution strategies:** MovingLake does not publicly document its conflict resolution strategy, but the architecture suggests it defaults to last-write-wins with optional custom merge rules. For agent workflows, this means you need to: Traditional ETL uses the warehouse as a schema normalization layer. You load raw JSON from Stripe into a staging table, then transform it into a clean `payments` table with standardized column names. Without a warehouse, MovingLake has to map schemas on the fly: ``` # Conceptual example of schema mapping config mapping = { "source": "stripe.charges", "destination": "salesforce.opportunities", "fields": { "amount": "salesforce.amount__c / 100", # Stripe uses cents "customer.email": "salesforce.contact_email__c", "created": "salesforce.created_date__c" }, "filters": { "status": "succeeded" # Only sync successful charges } } ``` **Challenges this introduces:** `amount` is an integer (cents), Salesforce expects a decimal (dollars)`customer.email`, Salesforce uses flat `contact_email__c` For agents, this means your schema mapping config becomes part of your infrastructure-as-code. If the agent needs to enrich CRM records with payment data, you need to version and test the mapping rules just like you would a dbt model. Bidirectional sync without a warehouse removes the audit trail you get from warehouse logs. When a sync fails, you need to answer: **What to instrument:** MovingLake likely provides a dashboard for these metrics, but you should also emit them to your own observability stack (Datadog, Prometheus, etc.) so you can correlate sync failures with agent behavior. This architecture makes sense when: It does not make sense when: MovingLake's bidirectional connectors are infrastructure for low-latency agent workflows that need to read from APIs and write back to production systems without manual orchestration. The architecture trades centralized data modeling for speed and simplicity. **Use it when:** **Avoid it when:** The hardest part is not the sync latency. It is reasoning about conflict resolution and schema drift when your agent's view of the world diverges from the source system's view. If you can keep your mappings simple and your agents idempotent, bidirectional sync removes a lot of orchestration overhead. If you cannot, you will spend more time debugging conflicts than you saved by skipping the warehouse.