Yorph AI
A Data expert in your pocket
What we learned: the best AI data product is the one that says "no"
Our mission has a line that keeps guiding every product decision: the key isn't what AI does - it's what it doesn't do.
In practice that's meant three things:
- The tool asks clarifying questions before generating anything.
- Every step is explainable - what it will do and why, giving users a full trail from raw data to insight.
- And the human stays in control of execution throughout.
The counterintuitive result: users trust it more when it slows down to confirm assumptions.
Which got us thinking about a harder design question - how do you build friction that feels like safety, not bureaucracy? Because the line between the two is thinner than it looks.
Still figuring it out. Curious if anyone else is wrestling with this.
If you want results you can trust and repeat, “ask a question, get a chart” doesn't cut it.
The workflow that gets you actionable insights needs good assumptions, branching approaches, and validation loops.
1) Pick a structured attribution analysis method (then layer if needed)
Choose the right method from a diverse toolkit:
* Metric decomposition (top-down): break a KPI into drivers (e.g., Revenue = Traffic × Conversion × AOV) and quantify contribution.
* Dimensional slice-and-dice: localize where the change happened (geo, device, channel, segment), then drill down.
* Driver tree / causal chain: trace breakpoints through dependencies (sessions → conversion → orders → revenue).
* Change-point / anomaly analysis: find when the shift started; align to launches/incidents; compare pre/post distributions.
* Funnels / cohorts / baselines: use when the metric is driven by conversion or retention, or when seasonality matters.
2) Multi-agent planning before writing queries
The platform uses multiple parallel agents to propose different plans (strategy, data audit, attribution, pipeline design), then reviews them to select the most robust plan.
3) Build a pipeline (dbt-backed) instead of one-off analysis
The agent creates a modular data pipeline:
* cleaning + standardization
* outlier detection / anomaly checks
* multiple analysis branches if needed
This keeps the analysis reproducible and operational.
4) Validation loops
Before producing insights, the agent checks:
* deltas reconcile (explained vs observed)
* grain/dimensionality is correct (no join explosions)
* no unexpected nulls/missingness
* results are stable to window/segment tweaks
* outputs align with business logic
If checks fail, the agent loops back, adjusts, and reruns.
5) Insights + viz, report assumptions and further suggestions
After executing and validating the pipeline, the agent generates:
* quantified drivers + supporting evidence
* visuals appropriate to the method (waterfall, ranked deltas, funnel comparison, cohort curves) * report of all assumptions used (column & metric definitions, cleaning done)
* suggestions for further analysis
6) Store logic + schedule it (recurring analysis)
Finally, the platform gives you:
* business logic: dbt project, pipeline code, semantic layer file
* insights, viz, validations, and assumptions
* all data output at every step of the pipeline, available for download
* scheduling/triggers available if necessary
That’s how we handle complex recurring analysis at Yorph: structured methods + branching pipelines + validation loops, not one-off answers.
-
1
This is a great breakdown - especially the emphasis on validation loops and avoiding one-off analysis.
Feels like the same gap exists in user behavior/retention: most teams look at engagement as static metrics or dashboards, but don’t build a structured system to detect early shifts and validate whether they actually matter.
Curious if you’ve seen similar pipeline-based approaches applied to things like churn or disengagement prediction, rather than just KPI analysis?
While analyzing data, you tweak logic, redefine metrics, and try again.
Yet we often run this entire process directly on full datasets.
You usually don't need all the data
Early on, you’re testing logic, not scale - and a small, truly random sample is enough for that stage.
- Queries run instantly
- You can iterate without worrying about cost
- You're more willing to experiment
A sandbox is not "dev but smaller"
A real sandbox should be cheap, fast, and easy to throw away. It's the place where you
- Try new ideas
- Break things on purpose
- Ask "what if?" without consequences
Most teams skip this step and jump straight from idea to production logic. That's why analytics work often feels heavier than it needs to be.
At Yorph, we treat small, random sandbox datasets as a default step before scale testing - not to replace full-dataset validation, but to get the logic right first. Analytics work needs space to explore, and sandboxes make that possible.
In practice, most of the difficulty isn’t in generating analysis steps/transformations, but in verifying that the result is correct.
Our current approach includes:
Sandboxed / sample runs on smaller datasets before full execution
Step-level transparency: summaries, intermediate tables, and generated code are visible
Parallel and sequential test-time execution to surface inconsistencies
dbt-style pipelines for reproducibility and explicit dependencies
Decomposing analyses into small, verifiable steps to avoid error compounding (e.g. MAKER-style approaches)
Online validation checks that trigger re-analysis when assumptions are violated
A gradually evolving semantic layer to improve consistency and governance over time
Curious to hear from others: what would make you trust an AI-driven data platform?
If you’ve ever waited days for a simple “can we break this down by X?”… you know the pain.
Yorph is our attempt to give data users the power to do real recurring analysis themselves: connect data, join/clean/analyze it, get charts/insights - without needing any technical chops.
Who it’s for (so far):
• Product Managers, FP&A, BizOps, strategy, and business analysts - anyone who is tired of relying on technical teams for their data needs, tired of waiting days for a "quick" data pull and stitching together messy spreadsheets, spending more time wrangling data than actually analyzing it.
Question: what’s the most annoying “small” data request you still can’t self‑serve today?
Domain knowledge is your differentiator.
Recommend building good simulators of the environment your agent will live in to scale these capabilities.
Architecture matters a lot.
How we structure agents i.e. their tools, callbacks, and most importantly: context management, is key.
Balance deterministic code and LLM "magic".
Finding the right balance is hard and it can take a lot of trial and error
Use frameworks, don't rebuild them.
Stand on the shoulders of fast-evolving Agent frameworks like Google's ADK etc.
If you're interested in what me and my team built, check out yorph.ai. It's an agentic data platform that helps you sync across different sources, clean/analyze/visualize data, automatic semantic layer creation, and build version controlled data workflows.
I am the founding engineer so ask away!
-
1
Great insights! Totally agree that domain knowledge and solid architecture make or break production agents. The balance between deterministic logic and LLM flexibility is the hardest part in my experience too.
-
1
Yes, it's been a lot of trial and error :)
-
-
1
Building reliable agents in production teaches you the importance of clean data, robust testing, clear workflows, monitoring, fail-safes, and continuous optimization to handle real-world unpredictability and ensure consistent performance.
-
1
Great post, asreddy.
You're spot on that "context management, is key." This is the part that's a constant struggle.
Since you invited us to "ask away" — how are you approaching this? Are you using vector stores for long-term memory, or have you found a more effective way to manage the short-term context window to keep the agent on track?
-
1
Good points. The domain knowledge thing is real. Most of the “agent problems” I see are just the model not knowing the world it’s supposed to work in. One question though. What happens when the agent runs long enough that its understanding starts drifting? That’s usually where things get weird.
-
1
Solid breakdown. The domain knowledge point is the one nobody talks about. Most agent failures happen because the LLM has no clue about the actual environment it’s operating in, not because the model is “bad.” Simulators and tight context management are the real moat.
Curious how you’re handling the balance between deterministic logic and model-driven behavior at scale. That line gets messy fast once you throw real users and unpredictable data into the mix.
At Yorph, we know security isn't a checkbox, it's a commitment. When you're working with AI-powered data systems, trust is everything. That's why we're designing Yorph with a security-first mindset, from data flow to agent behavior.
Here's how we think about it:
Two kinds of data, handled differently
Your data (uploaded/synced) is not stored by default
Interaction data (questions, prompts) is used only to improve agent behavior, never shared
Opt-in to retain data for up to 30 days. Otherwise, it's wiped after each session only the logic remains.
Your data never trains our models
No tricks, no exceptions. We use anonymized interaction patterns to simulate edge cases your actual data stays yours.
Agentic platform = new responsibilities
Agent actions are logged and explainable.
No auto-execution in sensitive workflows.
Agents only access what you allow.
Tenant data is fully isolated
Enterprise-grade LLM boundaries in place
We're building towards trust not just speed. Your data belongs to you. Our job is to treat it that way.
-
4
Congratulations on your launch. It looks impressive! What channels are you exploring to attract early users?
-
1
I like the emphasis on agent behavior, not just data handling. In practice, a lot of AI security conversations focus on storage and retention, but the harder problem is making agent actions predictable under real-world conditions. Hyperlambda is interesting to me in that context because it pushes toward deterministic executable structures with constrained runtime capabilities, which feels like a useful complement to logging, isolation, and permission boundaries.
2 Comments
The "friction as safety vs bureaucracy" distinction is something I think about a lot. My mental model: friction is welcome when it protects the user from a mistake they'd regret. It's bureaucracy when it protects the company from liability the user doesn't care about.
ATM asking "are you sure?" before a $5,000 withdrawal — safety. Cookie consent popup on every website — bureaucracy. The difference is who benefits from the pause. Your approach of asking clarifying questions before generating is smart because it signals "I'm slowing down FOR you, not AT you." That's a hard tone to get right in UI.
Curious: have you found a threshold where users start skipping the confirmations? Like, do repeat users eventually want a "just do it" mode, or does the trust loop keep them engaged with the friction?
Love this philosophy. "What AI doesn't do" is where trust lives.
The "clarifying questions before generating" insight resonates deeply. I apply similar thinking earlier in the pipeline: before AI generates code/content, I validate that users actually want the feature with video prototypes.
The "no" happens at the idea stage, not the execution stage.
Curious: How are you validating that users actually want these friction points (clarifying questions, explainability, human control) before fully implementing them?
I'm finding that what users say they want (safety, transparency) and what they tolerate in practice (speed, automation) can diverge. Would love to hear how you're testing these assumptions.