<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <title>beetl</title>
  <subtitle>Notes from building beetl.</subtitle>
  <link rel="self" type="application/atom+xml" href="https://beetl.io/atom.xml"/>
  <link rel="alternate" type="text/html" href="https://beetl.io/blog/"/>
  <updated>2026-11-12T00:00:00+00:00</updated>
  <id>https://beetl.io/atom.xml</id>
  <entry xml:lang="en">
    <title>Should I turn my heating on? I asked Germany's gas storage data</title>
    <published>2026-11-10T00:00:00+00:00</published>
    <updated>2026-11-12T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/should-i-turn-my-heating-on-germany-gas-storage/"/>
    <id>https://beetl.io/blog/should-i-turn-my-heating-on-germany-gas-storage/</id>
    <summary type="html">&lt;!-- Figures as of gas day 7 Nov 2026 unless stated (ranking chart: 8 Nov). Present-tense figures are dated in the text, so screenshots need no retake at publication. --&gt;&lt;p&gt;It&amp;#39;s November in Berlin and 1°C when I get up, and I still haven&amp;#39;t turned the heating on. Partly to save money. Partly because I&amp;#39;d read that Germany&amp;#39;s gas storage is low this year, and some stubborn part of me figured every radiator counts.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>What we learned putting decision models inside a production AI agent</title>
    <published>2026-10-07T00:00:00+00:00</published>
    <updated>2026-10-07T00:00:00+00:00</updated>
    <author><name>Bougouma Fall</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/decision-models-in-a-production-agent/"/>
    <id>https://beetl.io/blog/decision-models-in-a-production-agent/</id>
    <summary type="html">&lt;aside class=&quot;tldr&quot;&gt;&lt;p&gt;We gave Beetl&amp;#39;s AI agent a decision model for two jobs: picking which datasets matter for a question, and double-checking automation reports. We tested two, TypeSafe&amp;#39;s Jev and OpenAI&amp;#39;s new Decisions API, through the same OpenRouter endpoint. Jev found the right datasets 97% of the time and the Decisions API 91%, and with either one ranking datasets, the agent searched over a quarter less. The Decisions API gives the same answer every time but is sure of itself even when it&amp;#39;s wrong; Jev hedges. No prompt injection we tried changed either model&amp;#39;s answers. Large catalogs need a second round of scoring, and it all stays an experiment for now.&lt;/p&gt;
&lt;/aside&gt;&lt;p&gt;Most of the AI in Beetl today is a large language model in a loop. Our assistant reads the question, calls tools such as &lt;code&gt;list_data_sets&lt;/code&gt; and &lt;code&gt;execute_query&lt;/code&gt;, and writes an answer. Automations do the same on a schedule: they check a condition in the data and write a report that ends in a finding, either &amp;quot;clear&amp;quot; or &amp;quot;needs attention&amp;quot;.&lt;/p&gt;
&lt;p&gt;Many of the decisions inside that loop are small: is this dataset relevant? Does this report actually show what it claims? Did anything change since last run? Each one costs a full language-model call today, or doesn&amp;#39;t happen at all.&lt;/p&gt;
&lt;p&gt;Decision models are a new kind of model built for exactly those questions. We spent two days wiring one into Beetl and measuring it with our own evaluation suite. Then OpenAI released its own, and we ran the same tests on it. This post is what we found.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>How we wrote 20 integrations in one day</title>
    <published>2026-09-14T00:00:00+00:00</published>
    <updated>2026-09-14T00:00:00+00:00</updated>
    <author><name>Michele Vigilante</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/how-we-wrote-20-integrations-in-one-day/"/>
    <id>https://beetl.io/blog/how-we-wrote-20-integrations-in-one-day/</id>
    <summary type="html">&lt;aside class=&quot;tldr&quot;&gt;&lt;p&gt;Beetl Connect keeps integration code focused on fetching data, while the SDK and platform handle the shared work. That let a coding agent help us write and initially test twenty integrations in one day, followed by human review. The same tools make custom integrations practical for us and for customers who want to write their own.&lt;/p&gt;
&lt;/aside&gt;&lt;p&gt;We wanted Beetl users to connect their business applications and work with the data together, such as comparing sales in HubSpot with invoices from their accounting system.&lt;/p&gt;
&lt;p&gt;First, we need to get that data into Beetl. This is why we built &lt;a href=&quot;https://beetlio.github.io/connect/&quot;&gt;Beetl Connect&lt;/a&gt;, a toolkit that keeps the code for fetching data small and lets our platform handle running it.&lt;/p&gt;
&lt;p&gt;Connect lets us build ready-to-use integrations for our catalogue and quickly create custom ones for individual customers. That could mean connecting an internal application or handling a customer&amp;#39;s specific data needs. Both use the same toolkit and run on the same infrastructure.&lt;/p&gt;
&lt;p&gt;Using Connect and a coding agent, we wrote and initially tested twenty integrations in one day. HubSpot gives us a good example of how we did it.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>Fivetran charges you to delete data</title>
    <published>2026-08-26T00:00:00+00:00</published>
    <updated>2026-08-26T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/fivetran-what-you-dont-own/"/>
    <id>https://beetl.io/blog/fivetran-what-you-dont-own/</id>
    <summary type="html">Since 1 January 2026 deleted rows count toward paid monthly active rows. That change, and what actually triggers a full table re-sync, are both documented by Fivetran.</summary>
  </entry>
  <entry xml:lang="en">
    <title>AI Automations for the messy half of data quality</title>
    <published>2026-08-18T00:00:00+00:00</published>
    <updated>2026-08-18T00:00:00+00:00</updated>
    <author><name>Michele Vigilante</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/feature-spotlight-ai-automations/"/>
    <id>https://beetl.io/blog/feature-spotlight-ai-automations/</id>
    <summary type="html">&lt;p&gt;I had been thinking about this feature for a while because we had already built most of the pieces it needed: pipelines, a query engine, scheduling, run history, and an AI assistant that could inspect data. I wanted to combine those pieces into a check that runs every day and tells me whether the data is still correct.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;https://docs.beetl.io/automations/&quot;&gt;AI Automations&lt;/a&gt; are scheduled or manually run data checks in Beetl. You describe a business condition in plain language, and Beetl investigates the current data with read-only SQL before reporting Healthy, Needs attention, or Failed.&lt;/p&gt;
&lt;p&gt;Of course, you can already do this deterministically. Write a query, assert that it returns zero rows, and send an alert when it does not. For a well-defined invariant, that is often exactly what you should do.&lt;/p&gt;
&lt;p&gt;A deterministic check only covers the conditions encoded in its query. As exceptions and new source values appear, the query has to be updated or its results become increasingly noisy.&lt;/p&gt;
&lt;p&gt;I wanted something more &amp;quot;agentic&amp;quot;. By that I mean a check that can choose investigative steps beyond the path I explicitly defined. I wanted to describe the outcome I cared about, then let the system inspect the schema, sample the data, write queries, and follow up on whatever it found. The queries still had to be read-only, and I needed to see the evidence behind the result.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>You already have BI. What you're missing is trustworthy joined data.</title>
    <published>2026-08-11T00:00:00+00:00</published>
    <updated>2026-08-11T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/you-already-have-bi/"/>
    <id>https://beetl.io/blog/you-already-have-bi/</id>
    <summary type="html">If you have a BI tool and still cannot trust your reporting, the tool is fine. The work that is missing sits upstream of the chart.</summary>
  </entry>
  <entry xml:lang="en">
    <title>The mapping your ERP vendor never documented</title>
    <published>2026-08-04T00:00:00+00:00</published>
    <updated>2026-08-04T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/erp-migration-undocumented-mapping/"/>
    <id>https://beetl.io/blog/erp-migration-undocumented-mapping/</id>
    <summary type="html">In an ERP migration the export is easy. The hard part is the undocumented business logic the old system encoded over years, and recovering it before go-live.</summary>
  </entry>
  <entry xml:lang="en">
    <title>Why data-driven decisions are hard to make routine</title>
    <published>2026-08-01T00:00:00+00:00</published>
    <updated>2026-08-01T00:00:00+00:00</updated>
    <author><name>Michele Vigilante</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/why-data-driven-decisions-are-hard-to-make-routine/"/>
    <id>https://beetl.io/blog/why-data-driven-decisions-are-hard-to-make-routine/</id>
    <summary type="html">&lt;p&gt;Most companies already have the data needed to improve an important decision. Those records sit in several operational systems and need to become a result that arrives on time, can be checked, and continues to work after the first analysis. Rebuilding that path for every question is especially difficult for a company without a dedicated data team.&lt;/p&gt;
&lt;p&gt;I have come to think that this repeated integration work is the main obstacle to making data-driven decisions routine. It is also why we are building Beetl: a company should be able to begin with one recurring decision and reuse the connections, mappings, deployment, and monitoring for the next one. Later AI systems rely on the same connections and definitions.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>The Excel-and-Power-BI handoff that holds post-merger reporting together</title>
    <published>2026-05-27T00:00:00+00:00</published>
    <updated>2026-05-27T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/excel-power-bi-handoff-post-merger/"/>
    <id>https://beetl.io/blog/excel-power-bi-handoff-post-merger/</id>
    <summary type="html">&lt;p&gt;For months or years after a manufacturing acquisition, the Excel workbook is the consolidation engine. The Power BI card shows the resolved number but never the formula or the comment beside it. That is what fails at year-end audit.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>Can you see per-order margin while the shift is still running?</title>
    <published>2026-05-23T00:00:00+00:00</published>
    <updated>2026-05-23T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/can-you-see-per-order-margin-during-the-shift/"/>
    <id>https://beetl.io/blog/can-you-see-per-order-margin-during-the-shift/</id>
    <summary type="html">&lt;p&gt;The actual profit margin of a manufacturing order in most cases is decided based on what happens during the shift, but almost no plant can see it while the shift is running. &lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>Anatomy of a 5-4 Champions League Thriller: A Football Data Case Study</title>
    <published>2026-05-15T00:00:00+00:00</published>
    <updated>2026-05-15T00:00:00+00:00</updated>
    <author><name>Ray Kameda</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/anatomy-of-a-5-4-champions-league-thriller/"/>
    <id>https://beetl.io/blog/anatomy-of-a-5-4-champions-league-thriller/</id>
    <summary type="html">&lt;p&gt;Champions League knockout games aren&amp;#39;t usually 5-4 thrillers. April&amp;#39;s PSG vs Bayern semi-final first leg was. Bayern had 57% possession, an xG of 3.06 to PSG&amp;#39;s 1.90, and six big chances to PSG&amp;#39;s two. PSG won anyway. I dug into the data to see what might be going on.&lt;/p&gt;
</summary>
  </entry>
  <entry xml:lang="en">
    <title>DACH manufacturing now trails every major economy on digitalization</title>
    <published>2026-04-30T00:00:00+00:00</published>
    <updated>2026-05-23T00:00:00+00:00</updated>
    <author><name>Michele Vigilante</name></author>
    <link rel="alternate" type="text/html" href="https://beetl.io/blog/why-mittelstand-manufacturers-arent-using-their-data/"/>
    <id>https://beetl.io/blog/why-mittelstand-manufacturers-arent-using-their-data/</id>
    <summary type="html">&lt;p&gt;Manufacturing companies in the DACH Mittelstand are sitting on a great deal of valuable data, and almost none of them are using it well. I&amp;#39;ve spent the last few months talking to plant managers, controllers, and owners across the region, most recently at Hannover Messe last week, and the pattern is consistent. The data exists. They know it exists. They can&amp;#39;t really use it.&lt;/p&gt;
</summary>
  </entry>
</feed>
