Markin + Databricks integration
Lakehouse tables and feature stores as first-class signal.
What is a Databricks AI agent?
A Markin and Databricks setup treats your lakehouse as the substrate: Unity Catalog tables, existing feature stores and model outputs become inputs to the hypothesis space, and Markin writes decisions, holdouts and causal reads back as Delta tables your team can query.
Where a data science team already exists, Markin should extend it rather than duplicate it. Existing features and models become inputs to the hypothesis space instead of being rebuilt.
What Markin reads
- Delta tables and Unity Catalog assets
- Existing feature store definitions
- Model outputs your team already produces
What Markin writes back
- Decision and holdout Delta tables
- Per-experiment causal reads
How the connection works
| Pattern | What it means here |
|---|---|
| Attribute write-back | Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. |
| Read only | Markin reads signal from this system. Nothing is written back and no schema is changed. |
What can you ask Markin to do in Databricks?
- How do I operationalise the models my data science team already built?
- Can a decisioning platform read my Databricks feature store?
- How do I go from model score to a measured revenue action?
- What sits between Databricks and my engagement platform?
What Markin does in Databricks
- 01Read Delta tables and Unity Catalog assets under your governance.
- 02Consume existing feature store definitions rather than rebuilding features.
- 03Take your team's model outputs as one input among several.
- 04Generate and rank hypotheses across marketing, product, pricing and health.
- 05Arbitrate competing actions into one decision per customer.
- 06Write decision and holdout Delta tables.
- 07Write per-experiment causal reads with confidence intervals.
- 08Keep every artefact inside your workspace and lineage graph.
Scope of work
The growth work behind Databricks
The list above is what Markin touches in Databricks. A connector is only the surface. Below is the work itself: what an analyst, a lifecycle manager, a data scientist and an experimentation lead would do between them, running continuously against your own data.
Read the estate
Normally a data engineer, once, then never refreshed.
- Read contact history so past sends count as pressure on the customer.
- Track catalogue, pricing and plan changes as they happen.
Find where revenue is leaking
Normally a quarterly analyst deep dive.
- Spot pricing and packaging mismatch between what people buy and what they use.
- Spot product friction that correlates with downgrade and cancellation.
Explain why
Normally a two-week investigation pulled off the roadmap.
- Separate mix effects from real behaviour change.
- Rank drivers by how much of the movement each one accounts for.
Write hypotheses worth funding
Normally a workshop, limited to the ideas in the room.
- Attach the evidence and the assumption each one depends on.
- Rank the portfolio by expected value, not by seniority.
Decide per customer
Normally segment rules refreshed when someone has time.
- Arbitrate between every action competing for that same customer.
- Apply frequency caps, fatigue and quiet hours before anything is committed.
Execute in the tools you already run
Normally a ticket, then a slot in next month's calendar.
- Write decisions into the CRM, engagement and warehouse systems already in production.
- Trigger journeys and campaigns that your lifecycle team owns and can edit.
Prove it caused the revenue
Normally argued about, rarely measured.
- Stop an experiment early when the evidence is conclusive either way.
- Refuse to call a result that has not cleared the evidence standard.
Retire, govern and hand over
Normally nobody's job, so nothing is ever switched off.
- Retire programmes automatically when they stop beating control.
- Re-test assumptions that decay, such as price sensitivity and seasonality.
Databricks questions
- How does Markin connect to Databricks?
- Attribute write-back, Read only. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval.
- What does Markin read from Databricks?
- Delta tables and Unity Catalog assets; Existing feature store definitions; Model outputs your team already produces.
- What does Markin write back into Databricks?
- Decision and holdout Delta tables Per-experiment causal reads
- Do we have to move our data to Markin?
- No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later.
- Does Markin replace our engagement platform or CDP?
- No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout.
- What if the system we use is not listed?
- The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days.