- Interviewer: PythonMiao
- Interviewee: William Zhu (Co-founder, InfiniSynapse)
- Date: July 22, 2026
- This article is edited from a verbatim interview transcript. Sections were trimmed and copy-edited without changing the original meaning.
When people hear "AI data analyst," most picture a chat box: throw in a question, get back a chart.
William Zhu sees it differently. As co-founder of InfiniSynapse, he has spent the past two years focused on this product—something that started as an "AI data analyst" and kept growing downward from there.
This conversation follows three threads.
The first is product: Why can't a single Agent carry the full weight of a data analyst? InfiniSynapse has grown downward into an analysis language, an execution engine, and a memory system—what problem does each layer solve?
The second is business: Why did they stop betting on "selling subscriptions to end users" and turn instead to serving the developers who build applications?
The third is differentiation: Facing Cortex Analyst, Genie, and Fabric Data Agent, how do they use storage-neutral, language-neutral middleware—and the GA360 harness compression case—to explain where they sit?
Highlights in this issue:
- How a real analysis request travels from an SSE long connection all the way to a richly illustrated PDF report;
- Why results are trustworthy: small steps, fast iteration, plus a visual data lineage tree;
- When finance and sales disagree on what "revenue" means, how memory "confirms first, then consolidates";
- A shift in customer profile: from subscription users to app developers—a business selling to small B (app developers);
- Pricing: account count as the primary unit, project delivery as secondary, with inference on the enterprise's own models;
- Versus cloud-vendor Data Agents: storage neutrality, language neutrality, and how cross-source federated compute works;
- How InfiniSQL templates compress a 1,713-line partitioned-table query down to 52 lines;
- Why they're willing to do this interview now: enterprise deployments, contest applications, and the next step for "data analysis applications."
1. A Single Agent Is Not Enough
PythonMiao: Let's talk about how InfiniSynapse grew from an "AI data analyst" into a full data infrastructure stack. That sounds like a big shift—can you start with why you made that extension?
William Zhu: When people hear "AI data analyst," many think of just one Agent. We don't think a single Agent is enough, so we've kept extending downward.
First is the analysis language. Since we're doing data analysis, we built InfiniSQL for it—a language designed specifically for data analysis.
Second is the execution engine. A language needs an engine behind it to handle connecting different data sources and mixed compute.
Third is the memory system. Once you have language and engine, you also want this analyst to be personalized and to remember. We built a Context/Hub module that consolidates everything the analyst and people discuss into the enterprise and the organization. Users find it gets smarter over time—every alignment is captured and recorded. That rests on our relatively strong fourth-generation RAG technology.
Taken together, it's actually a data infrastructure stack covering Agent → analysis language → execution engine → memory system. On top of that we expose APIs and an application interface similar to Coze; we've also been running contests lately, encouraging developers to build apps—when an app needs data-analyst capabilities, it can plug straight into InfiniSynapse.
2. How One Analysis Request Runs End to End
After the architecture overview, PythonMiao grounded the discussion in a real request: what actually happens to a question that enters through the application UI?
PythonMiao: Let's walk through one real data analysis request: after it enters from the application UI, how does it pass through the server, runtime, InfiniSQL or RAG, and finally write results and memory back to the workspace?
William Zhu: Here's how it works. After the user enters a question, the frontend opens an SSE streaming long connection to us, and the Agent receives and starts handling the task.
Step one: small-step exploration. During processing, the Agent generates many InfiniSQL statements for exploration and hands them to the engine to execute.
Step two: the engine remembers intermediate results. At each step, the engine records intermediate results as named tables. The Agent only needs to see a table's result to reference that table directly in the next iteration—that's what we mean by an Agent-friendly language.
Step three: the knowledge base fills in context. If user preferences, metric definitions, or table business context come up, the Agent can pull them from the knowledge base.
Step four: self-verification. After getting a result, the Agent runs a round of self-verification first.
Step five: generate deliverables. Finally it delivers what the user asked for. If the user wants a PDF report, spreadsheets, or Word, the Agent calls about four conversion tools we built—nicely formatted, with text and visuals—and sends the result back to the application.
Business App / BFF (forms, auth, business orchestration)
→ InfiniSynapse Server API (SSE long connection + task endpoints)
→ Agent Runtime (planning, reasoning, tool calls)
→ InfiniSQL + cross-source execution engine (reusable intermediate tables) + InfiniRAG (definitions, preferences)
→ Task workspace (Markdown, charts, PDF, Word, and other deliverables)
→ Back to the application for presentation
Our API isn't just for starting tasks—it also supports control, such as specifying which model to use. We also support tenants and sub-accounts: after you register a tenant with us, you can create sub-accounts via API for isolation between users. So it's very friendly to application developers.
3. Why You Can Trust the Results
Application developers aren't plugging into a chat interface that only returns text—they're plugging into a multi-tenant analysis service that can execute compute, reuse intermediate results, and deliver formal documents. The next question is trust.
PythonMiao: When the Agent does cross-source compute, repeatedly references intermediate tables, and claims it has "self-verified," what standards does the system actually use to decide the result is ready to deliver?
William Zhu: When AI does analysis on our infrastructure, it works in small steps, fast iteration. For example: to get a computed result from multiple tables, it moves forward exploratively. We provide a visual data lineage interface where you can watch the AI keep abstracting—starting from two or three original tables to produce a new table, then combining that with another abstracted table to produce the next, abstracting again and again until it unfolds as a tree structure leading to the final result.
That design has three benefits.
First, each step stays simple enough. Every step has a clear goal and expected outcome, so the AI is unlikely to make large logical errors, and humans can verify very easily.
Second, errors usually aren't in the compute. We rarely see problems at the calculation layer; drift generally comes from misunderstanding user definitions (metrics and business definitions)—and that's exactly what the knowledge base is for.
Third, humans do macro-level second-pass validation. AI ultimately has the same problem people do—when it thinks it's right, it can't catch its own mistakes. But because the whole process is broken into simple pieces, a person only needs to scan the macro data flow once to do a quick second check; details are very unlikely to be wrong.
So trust isn't built on "the AI never makes mistakes." It's built on breaking complex analysis into traceable small steps so people can quickly validate the entire data flow.
After a task completes, the workspace shows the full set of deliverable files:
4. When Two Departments Disagree on Definitions, How Memory Consolidates
PythonMiao: If two departments define the same metric differently, how does the system decide which definition to use—and avoid a one-off wrong correction being consolidated into organizational memory and affecting later analysis?
William Zhu: Different departments can indeed have different definitions. Finance and sales often disagree on what "Q1 revenue" means. A typical flow looks like this.
First, discovery. Someone from finance uses the system—they're sensitive to the numbers. If the system returns sales's definition, they can spot that the data doesn't look right.
Second, correction. They tell the AI the correct definition, e.g. "only money that hits our account counts as revenue." When the AI realizes it was corrected, that means it wasn't aligned with the person before—information was insufficient.
Third, consolidate after confirmation. The AI proactively triggers an alignment consolidation. A finance colleague confirms whether the alignment is correct. Only after confirmation does it go into organizational memory and influence later analysis.
Also, all our conversations can be recalled through the knowledge base. Even if something discussed in a session never made it into the Hub, global memory can still bring it back so what you said before still applies this time. Definitions, preferences, and similar consolidations all work this way.
5. Can Unconfirmed Conversations Pollute Someone Else's Analysis?
Memory is split into two layers: confirmed organizational knowledge, and historical conversations that can still be retrieved. PythonMiao pressed on the boundaries of the latter.
PythonMiao: In enterprise settings, if unconfirmed personal conversations can also be recalled globally, how does the system control permissions and trustworthiness so wrong definitions or sensitive information don't affect other people's analysis?
William Zhu: First, unconfirmed information does not enter our Hub. Second, when recalling historical conversations, context shows whether a piece of information was affirmed or rejected at the time: if it was clearly wrong, the user directly rejected or abandoned it, or never gave affirmative confirmation, we don't use that data—and the AI can recognize that too. Because our recall is implemented on a fourth-generation RAG knowledge base, recall accuracy and intelligence are very high; the problem you describe generally doesn't come up.
PythonMiao: If you turn "usually no problem" into an enterprise-acceptable metric, what rerunnable tests do you use today to measure correct memory being recalled and wrong memory not polluting answers?
William Zhu: As I said, we've already introduced a user confirmation mechanism in this system. That mechanism ensures: content the user confirmed can always be recalled and meets user needs. We can also look at this from a development perspective—not only this one point.
6. Customer Profile Shift: From Subscription Users to App Developers
After product, the conversation turns to business—the stretch where William Zhu gave the most information in the whole interview.
PythonMiao: As InfiniSynapse expanded from a single AI data analyst to a data engine, organizational memory, APIs, and app distribution, how has your core paying customer profile changed compared to the beginning?
William Zhu: That's a great question. Business models and user behavior in the AI era change very fast.
Five or six months ago, we thought our core user was the ordinary subscription user—pay monthly or yearly like other AI tools; when enterprises had needs, they'd buy via project or subscription.
Today, things have changed. With products like Claude Code and heavy subsidies from big vendors on their own AI apps, it's hard to sell subscriptions on scenarios like "help me analyze an Excel file"—users already subscribed to those products aren't likely to subscribe to you again. And the people who really need to analyze data are usually inside enterprises; enterprise data is hard to authorize to outsiders—you need in-enterprise deployment to actually use and analyze it.
So we ultimately decided: our core audience is developers who build applications. They build apps to serve their own enterprise or consumer customers, and we provide the capability (API) to them.
The logic is simple—when you build an app, you don't build your own database just because you need a database; likewise, when you need data analysis capability, you shouldn't build a whole stack from scratch. We want every app that needs data analysis to use us directly: SaaS is the default, and we support private deployment when needed. That puts us in a model of selling to small B (app developers).
7. Account Count Primary, Project Delivery Secondary
PythonMiao: In this B2B2C model, what value unit do you anchor pricing on—so you cover inference and private-deployment costs while developers stay willing to pay as their business grows?
William Zhu: On cost first: inference still uses the enterprise's own internal models—we don't provide inference model deployment or service; use what the enterprise already has. If they don't mind third-party model services, that's fine too.
On long-term payment, our view is: enterprises go through a process—they want to quickly validate whether something is feasible and whether it really helps their business. At that stage, using our product is a good choice. If after validation they find the payoff is huge and want to invest engineering to build something similar themselves, we're OK with that too.
A business model doesn't have to cover the enterprise's full lifecycle—helping every enterprise explore, or helping a business actually land, is already enough for us.
PythonMiao: Concretely for closing deals: accounts, call volume, project delivery, private-deployment licensing, business outcomes—what's the core pricing unit?
William Zhu: If you work it out carefully, two points.
First, the core pricing unit is account count. For customers who accept per-account pricing, we price by how many people in the enterprise use it; some go project-based with project delivery. Different business shapes use different pricing, but account count will be the mainstream.
Second, outcomes have to win. Whether end users pay in the end comes down to business results—our analysis quality has to beat every other Agent product, or it's hard to answer "why buy you instead of building in-house or using a third party."
8. Versus Cortex / Genie / Fabric: Which Layer Differs
PythonMiao: Facing mature references like Cortex Analyst, Genie, and Fabric Data Agent, if you could pick only one independent, rerunnable test, what result would you use to prove InfiniSynapse's advantage?
William Zhu: Head-to-head comparison is actually hard. A different angle makes it clearer.
Cortex Analyst and Genie are tied to Snowflake and Databricks respectively; their foundations sit closer to each vendor's warehouse. Fabric Data Agent is somewhat more middleware—it can connect multiple places for joint analysis—but still mostly stops at that layer.
InfiniSynapse chose differently: storage is neutral. You can use our storage or not; you can do federated compute directly. What's truly hard—and truly valuable—is often not "all data is already in one warehouse," but data scattered in different corners where you still need to find relationships and compute them. For example, joining tabular information scraped from the web with data in a business database—that reflects that we don't strongly favor one underlying data source; we're closer to a storage-neutral analysis foundation.
Second is InfiniSQL in the middle: it's also language-agnostic—not bound to one database dialect, but a middleware language that's friendly to Agents.
9. 1,713 Lines Down to 52: Compressing Query Expression, Not Raw Data
PythonMiao: Can you use the GA360 case—from 1,713 lines reduced to 52—to explain specifically how the 59.4:1 byte compression works and what analysis information is preserved?
William Zhu: That case comes from a GA360 / Spider–style task we ran. The data had lots of partitioned tables—too large to fit in one table, so it was split by day. But once you need to process the last year, you might join 365 tables; statements get long and thin: even with million-token context windows, one SQL can eat a large share, and it's hard to compress at the Agent layer.
So we felt compression should happen at the language layer in context: make InfiniSQL simpler while expressing more meaning. The approach is something like templates—use simple loops to fold repeated structure without weakening expressiveness. With that layer, native SQL and parameterized InfiniSQL can both run on our engine, achieving very high compression ratios—that case was thousands of lines of repetition from partitioned tables.
PythonMiao: So what's compressed isn't raw data but the query expression the Agent must generate and understand: loops and templates replace repeated SQL across hundreds of partitioned tables, then the engine executes. Beyond the 59.4:1 number, how do you verify the 52-line version is fully equivalent to the original 1,713-line SQL in results?
William Zhu: Because the final execution results match. By design, the engine expands once at the syntax layer; the expanded form matches native SQL, so underlying execution results must match too.
10. Two Isolated Data Sources: How JOIN Works
PythonMiao: One step further—when JOINing across two isolated data sources where raw data can't be centrally moved, how does InfiniSynapse actually perform that federated compute?
William Zhu: The underlying engine can do cross-source compute natively. It treats different databases as different data sources and pulls data as needed; optimization strategy differs for single-source vs multi-source.
Single source: If you're connected to only one data source, we push compute all the way down whenever possible. And because InfiniSQL encourages small-step statements—you don't need the AI to write one huge complex SQL at once—multiple small statements can be equivalent to one complex query, easing the Agent's writing burden while still pushing down completely.
Multi-source: We push compute down into underlying data sources as much as possible; only the results that need merging are pulled over. Data isn't all piled in memory—it also lands on disk. Semantically it's still SQL JOIN semantics, not the traditional pattern of "move all data over first, then write code to aggregate and merge." Pushdown is engine optimization; we also pair it with Agent intelligence so pushdown works better.
11. Why Talk Now: Deployment, Contests, and "Data Analysis Applications"
PythonMiao: Why do you want to talk about InfiniSynapse now? What change actually matters to you?
William Zhu: Mainly because the product has been validated in deployments at more than a dozen enterprises; we've also been running a Vibe Coding contest, with twenty-plus apps integrated on InfiniSynapse as their foundation. I feel it's polished enough to face the market properly.
People can also watch a concept I mentioned before: general-purpose data analysis applications. It essentially brings analysis capability from the enterprise to the broader market—you can quickly give your users an analyst to help with everyday decisions like shopping, choosing a major, or filling out college applications. Many choices in ordinary life can be assisted with this kind of analyst capability.
PythonMiao: What's the minimum bar for you to count an app as "truly integrated and validated"—not just registered, filled in an address, or ran a demo once?
William Zhu: The bar can be a bit loose: actually creating the app and connecting it, passing tests, or already serving end users—I count all of that.
PythonMiao: Looking back a year from now, what measurable outcome would convince you that "data analysis applications" have moved from contests and demos into a real market?
William Zhu: Thank you very much. On that question—let's look forward to it together.
InfiniSynapse trial: China app.infinisynapse.cn, international app.infinisynapse.com; developer API and more at www.infinisynapse.cn. Vibe Coding contest entries: Contest Gallery.