Introducing Dive Apps: superpowers for AI builders. AI Features Product A dashboard is just a fancy report if you can't take action on it. Today MotherDuck Corp. is launching Dive Apps: fully custom data apps that can write-back anywhere. Build them with your agent and they run on the MotherDuck data warehouse. Use Dive Apps to replace SaaS apps, automate your operations, or bring humans into the loop to steer your agents. They are the best way to use AI to build your business. Don't build dashboards - build apps! You have the power of AI behind you. Anything that used to be a report should be an app instead, and can be just as easily. Connect your agent to its MCP server and an app for your whole team is just one prompt away. Dive apps work by letting your Dive visualizations trigger Flights, its serverless Python runtime. While you can certainly update data inside MotherDuck, the flexibility of Flights means you can write data back into source systems as well. Or send emails. Or post in Slack. One of my favorites is that you can rerun machine learning models (remember when data science was the sexiest job of the 21st century?). For even more power, you can kick off a full-featured agent harness to act on your behalf. What can you build? Dive Apps are designed for flexibility, so there are many ways to use them. Now that custom software is so inexpensive, there are more and more places MotherDuck Corp. will see ROI from building an app. If it takes an hour to speed up something your team does once a week, you see benefits immediately. These are just examples to get your creativity flowing - imagine what you will build! Replace SaaS apps. Completely duplicating the capabilities of a SaaS app sounds daunting, but I'm confident you aren't using every feature of every SaaS app. Agents can replicate just the features that you rely on and customize for your business. Still paying for project management software? Build an interface that matches your company's exact workflow. Using a SaaS to stitch together multiple marketing and ads systems? Your agent can load that into MotherDuck and you can build a decision support system for your team. Not only can you make the right decision, but you can push that decision into the upstream systems. AheadComputing is a semiconductor design company building on top of MotherDuck and is slashing SaaS app costs. Ben Holtzman, staff design enablement engineer, phrased it this way: "A single license for a power analytics tool for six months could be $50,000. There are basically only three companies that create this vendor tooling. You're operating in a space with a virtual monopoly." Instead of more licenses, they designed an even more feature rich interface on top of MotherDuck. Automate your operations. Augment your domain experts with Dive Apps that bring together everything they need to make a decision. Then, put that decision into practice right in the app. Imagine how much faster issues could be resolved if customer support specialists had a custom command center app at their disposal. It could retrieve the full context of how a user is interacting with the product, their contract details, and any similar conversations. Within the app they can send messages directly to the customer. But this is more than a vanilla chat window, this app is a command center after all! It has relevant docs automatically surfaced and best practice snippets ready to embed. As a result, your team moves faster and customers are happier! How do you handle RevOps today for your sales team? A custom app could build forecasts based on your business's exact subscription structure and predict based on actual usage statistics in the product. Instead of just looking at inventory levels, you could actually send out a purchase order when stock gets low. You could game out what-if scenarios to see if same day shipping is worth it or if "priority shipping" is reliable enough to keep your production line up. These kinds of decisions need data from all kinds of source systems. Steer your agents. Over time, agents will take on a larger fraction of the decisions in its businesses. However, if you've ever automated a complex business process, you know you don't just flip a switch and call it a day. The fastest way to implement automation is to make changes incrementally: first advise, then require approval, then only escalate exceptional cases, then go fully autonomous. Having an app keeps a human in the loop for as long as it is valuable. Customizing that app keeps the time-spent-per-case as low as possible and surfaces all the background someone needs to make a wise choice. Each time the domain expert correctly overrides the agent gets saved to improve the agent for next time. Eventually quality reaches 99.9% and you switch out the lights on that process and let the robots handle it. That implementation process requires an app that gives the human the ability to write back to source systems and to document where the agent fell short. Without write-back, operators won't be able to trust the automation or fix things when something unforeseeable occurs. Build on the best infrastructure. There is plenty of noise about where you should build with AI. Why build on MotherDuck? Fundamentally, it's because it's incredibly simple to use, brings all the capabilities of a data warehouse, but skips the drawbacks of a legacy platform. The easiest way to centralize all your data. Your most important decisions need data and context from multiple source systems. If a problem could be solved with data that is already in one place, you've solved that problem already. MotherDuck Flights are the easiest way to pull data from anywhere into an efficient, central location. Your agent has the full power of Python available (with all its open source ETL libraries) to pull from thousands of sources in just a couple of prompts. A fast query engine that spins up instantly. Once your data is centralized, you need a high performance analytical engine to make sense of it. Time is valuable, and whether it's your operational team or executive team, they need answers quickly. Latency is critical in any app. Joining tables together or extracting meaning out of a deluge of log data are compute intensive, and analytical engines are the right tool for the job. But you don't want it to be a huge, always on, monolithic cluster. Likewise, you can't wait minutes for things to initialize. Especially for data app interactions that can be variable, you want your compute to spin up just as you need it and spin down when you are done. With MotherDuck, you can handle the scale you need without the multi-second queries and high cost baggage of a decade-old legacy warehouse architecture. In short, you need warehouse horsepower, but with the latency profile of an app DB not a batch job system. On MotherDuck, each user can have their own compute resources too, so nobody waits in line. Flexibility is key, governance is non-negotiable. If an app-building platform locks you into cookie cutter widgets, no AI will help you build exactly what you want. Conversely, if there are no guardrails, then you can't deploy with confidence. MotherDuck includes Single-Sign-On (SSO), Role-Based Access Control (RBAC), and now Table, Row, or Column Level Security (TLS, RLS, or CLS). That lets you share your apps with exactly who you need to and lock them down as appropriate. Data in MotherDuck is private by default, so you can opt in when it is time to share with other users. As an integrated part of MotherDuck, you can manage your data and Dive Apps access all in the same spot. No separate dashboard permissioning system! Store your context for the long term. If you want your agent to be able to build an app that fits your business rules, you need context. In MotherDuck Guides you can teach your agent about the structure of your data and curate best practices. That way, your agents understand your company's data and provide more accurate answers. Why Guides? Don't bet on just one AI lab and put all your context in their proprietary system! What happens when the other company drops a new model that laps the rest? You want to be able to switch to the best in class LLM at a moment's notice. You already need a place to store your data, so store your metadata right alongside it. Data stores last forever, but the leader in the AI race changes every week... Apps that take action in any system. An app is really just a report if it doesn't actually trigger changes in your business. If your business runs right on top of MotherDuck, write straight back to a MotherDuck database. Or if you want to take action in a source system, Flights can push data anywhere and trigger any actions needed. Your data doesn't get stuck in any database, it can flow wherever is needed. Actions can range from something as simple as a Slack alert to actually executing a discount on a customer's bill. Those financial decisions are cases where the augmentation approach that keeps a human in the loop can be most effective. After the agent gets 50 right in a row, then you can move to auto-pilot with a scheduled Flight! Conclusion. If you're running your business just with an agent on every laptop, you're still in the spreadsheet era of AI. Sure, you're emailing around artifacts instead of xls files, but you're not getting the gains that the AI labs promised. To get the most out of AI, you want to automate entire process flows. To do that accurately, you need the right data and the right context. You need the right guardrails in place to set your organization free to innovate. Dive Apps let you move your business faster because they tie in directly with the full power of MotherDuck. MotherDuck Corp. can't wait to see what you build! Quack on! Table of contents

prompt_jev now works on images. BY MotherDuck team Three weeks ago MotherDuck Corp. brought prompt_jev to MotherDuck, a week after TypeSafe announced Jev. You ask a closed question in plain English, pick the shape of the answer (yes/no, one choice from a list, a score), and get a typed result with a confidence score, straight from SQL. MotherDuck Corp. showed five use cases on text columns. Today, with TypeSafe's Jev 1.14, prompt_jev also takes images. Store them in a BLOB column, ask your questions, and the answers come back as columns you can filter, join and GROUP BY with the rest of your data. And yes, MotherDuck Corp. also asked seven models the only question that really matters: hot dog or not hot dog? On hotdogbench.com, Jev isn't the top dog, but it's the first one to the bun. Try it in one query. Hugging Face hosts lots of public image datasets as Parquet, with each image stored as bytes. Read them with hf:// and hand the bytes straight to Jev: SELECT image.path AS file, prompt_jev([{name: 'dish', image: image.bytes}], 'Is `dish` a dessert?') AS is_dessert FROM 'hf://datasets/ethz/food101/data/validation-00000-of-00003.parquet' LIMIT 5; | file | is_dessert | | 1827892.jpg | 0.72 | | 2802124.jpg | 0.90 | | 2192983.jpg | 0.90 | | 1062952.jpg | 0.95 | | 3157161.jpg | 0.93 | Each row gets a probability between 0 and 1. These five photos are beignets, so they score high. How fast, how accurate, how cheap? MotherDuck Corp. used the same dataset: Food-101, labeled photos of 101 dishes. One question per photo, "Which dish is shown?", with all 101 dishes as the allowed answers, asked to Jev, Gemini, GPT and Claude on the same 1,010 photos (10 per dish). | Model | Rows/s | Accuracy | Cost for the 1,010 photos | | Jev (prompt_jev in MotherDuck) | 44 | 90.2% | ~$0.06 | | Gemini 3.8 Flash, low thinking | 10 | 96.8% | $1.14 | | Gemini 3.8 Flash, default thinking | 7 | 97.0% | $1.43 | | GPT 6.1 Sol | 7 | 93.4% | $1.89 | | Claude Opus 5.5 | 9 | 95.7% | $6.60 | MotherDuck Corp. can score accuracy here because Food-101 has the right answer for every photo. On your own data you won't have that, so the real question is which answers you can trust. The big difference between Jev and a standard LLM is the confidence score. Every answer comes with one, and on this benchmark it reflects how often Jev is actually right. If you keep only the answers at 0.8 or more (WHERE jev.confidence >= 0.8), Jev is right 97.7% of the time, on 80% of the photos. | Min. confidence threshold | Photos kept | Accuracy on kept photos | | (keep everything) | 100% | 90.2% | | 0.5 | 94% | 92.7% | | 0.7 | 86% | 95.8% | | 0.8 | 81% | 97.7% | | 0.9 | 73% | 98.5% | | 0.95 | 65% | 98.9% | | 0.99 | 50% | 99.2% | This of course begs the question - what if MotherDuck Corp. combine Jev with another model to a cheap first pass and then a secondary cleanup loop? | Models to use | Accuracy | Cost per 1,000 photos | | Gemini 3.8 Flash alone | 97.0% | $1.40 | | Jev + Gemini 3.8 Flash | 96.5% | ~$0.45 | | Jev + Gemini Flash-Lite | 95.3% | ~$0.18 | | Jev alone | 90.2% | $0.08 | Notice how MotherDuck Corp. can achieve big gains in accuracy for relatively small increases cost compared to using a System Two LLM for the entire job. Getting your images in. If your images sit in S3, one query loads them into a BLOB column (with an S3 secret in place): CREATE TABLE images AS SELECT filename AS path, content AS image FROM read_blob('s3://my-bucket/photos/*.jpg'); Jev needs each side of an image between 280 and 1,568 pixels. Bigger images need a resize first: a Flight (Python that runs on MotherDuck compute) with Pillow does it. The docs have a ready-to-use example that reads from S3, shrinks anything too big and writes the result back as a BLOB. Or skip the code and ask the MotherDuck MCP server from Claude or your agent of choice: Load the JPEGs under s3://my-bucket/photos/ into a new table photos.main.images, one row per file with the image as a BLOB. Resize anything longer than 1568px on its longest side, skip images under 280px on their shortest side, and run it as a MotherDuck Flight. Tell me how many images landed and how many were skipped. Five centuries of art in one GROUP BY. MotherDuck Corp. took the Metropolitan Museum of Art's open access collection, half a million CC0 catalog records, and kept every public-domain painting, print, drawing and photograph with an image: about 77k works, loaded as 600px BLOBs. Then MotherDuck Corp. asked 14 questions about every image in one SQL query. Here are 4 of them: SELECT object_id, prompt_jev( [{name: 'art', image: image}], questions := {smile: {type: 'choice', instructions: 'If a human face is clearly visible in `art`, what is the expression of the most prominent face?', criteria: ['no_clear_face', 'neutral_or_serious', 'closed_mouth_smile', 'smile_showing_teeth', 'laughing']}, dog: {type: 'noul', instructions: 'Is there a dog anywhere in `art`?'}, dog_box: {type: 'box', instructions: 'the dog in `art`'}, skull: {type: 'noul', instructions: 'Does `art` show a human skull or skeleton?'} - plus 10 more: main subject, weather, sunset, drink, food, cat,...}) AS jev FROM images; Once the answers are stored as columns, they join with the Met's catalog like any other data. When did people start smiling in art? One GROUP BY: SELECT (floor(o.begin_year / 50) * 50)::INT AS half_century, round(100 * count(*) FILTER (WHERE f.smile IN ('closed_mouth_smile', 'smile_showing_teeth', 'laughing')) / count(*) FILTER (WHERE f.smile <> 'no_clear_face')) AS pct_smiling FROM features f - Jev's answers, one column per question JOIN objects o USING (object_id) WHERE o.begin_year BETWEEN 1400 AND 1949 AND o.end_year - o.begin_year <= 25 - only works the Met dates within 25 years AND NOT f.rejected GROUP BY ALL ORDER BY half_century; Almost nobody smiles before 1600! Many reasons for that, but that's for another blog. Get started. Images are now just another column in MotherDuck. Load your product photos, scans, screenshots or camera-trap pictures as BLOBs, ask your questions, and join the answers with the rest of your data. Table of contents