FluentLake

Welcome to FluentLake

2026-05-29T00:00:00Z

I've been meaning to write things down for a long time. Not polished think-pieces, just the working notes I usually keep in scratch files and then lose. This is the place I'm going to keep them instead.

I work in data and analytics, mostly in the Microsoft world: Microsoft Fabric, lakehouses, Azure, Synapse, and a great deal of SQL. A lot of what I do is moving data from where it is to where it can answer a question, and making that path reliable enough that someone else can trust the answer. That work is full of small decisions that never make it into the documentation, and those small decisions are exactly what I want to capture here.

What this blog is

FluentLake is field notes from the lakehouse. The emphasis is on notes: short, specific, and written close to the moment I learned something. I'd rather publish one honest paragraph about a query plan than a tidy listicle I don't believe.

A few things you can expect:

Lakehouse architecture, and the medallion pattern in particular. Bronze, silver, gold is easy to draw and harder to live with. I want to write about the parts that bite.
Azure and Synapse trade-offs, with the reasoning attached. The conclusion is usually the least interesting part; the "why" is what transfers.
SQL worth keeping. Queries that earned their place, and the tuning stories behind them.
AI-assisted engineering, told straight. I build with Claude Code, Copilot CLI, and ChatGPT as part of the toolchain now. Some of it is genuinely transformative and some of it is overhyped, and I'd like to be honest about which is which.

What this blog isn't

It isn't a product. There's no course at the end, no newsletter wall, no growth funnel. If a post is useful to you, wonderful. If it's wrong, please tell me, because the fastest way I've found to learn something is to publish a confident mistake and get corrected.

It also isn't speaking for anyone but me. Nothing here is the official position of an employer or a client. These are my notes, my opinions, and my errors.

On writing in the open

The honest reason I'm doing this in public is that it makes me think more carefully. It's easy to half-understand something when it only lives in your head. The moment you have to explain it to a stranger, the gaps show up. Writing here is partly a forcing function: if I can't explain why I reached for a serverless SQL pool instead of a Fabric warehouse, I probably don't understand the choice well enough yet.

So that's the plan. Notes from the lakehouse, written while I'm still figuring it out, kept somewhere I won't lose them.

If you want to follow along, the RSS feed is the best way. Thanks for reading the first one.

Synapse is retiring trusted-services access on 1 August 2026, and it may mean a new workspace

2026-05-30T00:00:00Z

Microsoft recently sent a notice that is easy to skim past and expensive to ignore. It announces that the trusted-services function in Azure Synapse Analytics is being retired, with a firm date of 1 August 2026. The language is dry and the impact is large, so I want to translate it into what it actually means and why it deserves attention now rather than closer to the deadline.

What is being retired, and the date

Today many Synapse workspaces reach an Azure Storage account or an Azure Key Vault using a managed identity together with a firewall exception. That exception is the trusted-services allowance, and it permits the Synapse service to reach the storage or Key Vault firewall because Microsoft treats it as a first-party service. On 1 August 2026, that allowance is removed.

The replacement is private networking. Instead of a firewall exception, your workspace reaches Storage and Key Vault through a managed virtual network using managed private endpoints. This is a stronger security model. The hard part is the work required to get there.

The change does not degrade gracefully. If no action is taken, the paths that depended on the trusted-services exception will stop working, and a Synapse workspace that cannot read its storage or its secrets cannot operate. This is a deadline that interrupts production workloads, not an optional cleanup.

Why this is the typical installation, not an edge case

It is natural to assume that only heavily hardened environments are affected. In practice, the opposite is true. The at-risk configuration is the ordinary result of following the installation guidance carefully.

When you stand up Synapse Link for Dataverse, Microsoft's guidance directs you to set the landing storage account firewall to Selected networks. That is the appropriate next step after the wizard completes, because the storage account should not remain open to the public internet. Trusted Azure services are then allowed through so that Synapse can continue to reach the account. That combination, a restricted firewall together with the trusted-services exception, is precisely the pattern being retired.

The population at risk is therefore not the teams that did something unusual. It is the majority that followed the security-conscious install. A fully open storage account, which is technically unaffected, typically appears only on demonstration tenants or in environments where the firewall was never tightened. If you followed the secure setup, you are more likely to be affected, not less.

The create-time-only trap

The managed virtual network is the workspace property that lets you use managed private endpoints. That property can only be enabled when the workspace is created. Microsoft does not provide a way to enable it on a workspace that already exists.

As a result, if your workspace was not created with the managed virtual network enabled, this is not a setting you can change in the portal. The practical remediation is to deploy a new Synapse workspace with the managed virtual network enabled from the outset and migrate your work onto it.

It is also worth remembering that every Synapse workspace has an associated primary storage account, an ADLS Gen2 account that holds its saved queries, pipelines, and related artifacts. The workspace and its storage are closely tied, which is part of why repointing an existing workspace is not straightforward.

How to tell if you are affected

This assessment is something you can run yourself today, at no cost, in a few minutes, and it establishes whether you are affected.

First, identify the relevant storage account. This is the landing storage account for your Synapse Link, found in the Power Apps maker portal under Azure Synapse Link for Dataverse, then the link entry, then Details. Copy the value shown under Storage Account.

With the correct account name, run the following Azure CLI query. Reader access on the storage account is sufficient for it to return cleanly.

az storage account show --name <landingStorageAccount> --query "{publicNetworkAccess:publicNetworkAccess, defaultAction:networkRuleSet.defaultAction, bypass:networkRuleSet.bypass, ipRules:length(networkRuleSet.ipRules), privateEndpoints:length(privateEndpointConnections)}" -o table

Interpret the result against three cases.

If you see defaultAction: Deny together with bypass: AzureServices and privateEndpoints: 0, and the paired workspace has no managed virtual network, then you are at risk and a rebuild is required before 1 August 2026. You confirm the managed virtual network status on the workspace Overview page in the Azure portal.
If you see defaultAction: Allow, then the firewall is not load-bearing. There is no trusted-services bypass to retire, so this specific change does not affect you.
If you see a private endpoint already in place and the workspace already has a managed virtual network, then you have already migrated, and there is nothing to do here.

The middle case is worth a closer look. If your storage account accepts public traffic from all networks, the retirement does not affect you on 1 August 2026, but the only reason it does not is that the account is currently open to all networks, which is a risk worth addressing in its own right. Once you properly restrict the firewall to selected networks, you return to the at-risk pattern. A fully open account defers the deadline; it does not remove the underlying work. I would still plan a move to the private-networking model on a measured timeline, so the account can be locked down properly soon after.

If you prefer to confirm this in the portal rather than the CLI, the at-risk setting lives on the storage account's Public network access page. Public network access is set to Enable, and the scope beneath it is set to Enable from selected networks. That is the firewall-on, trusted-services-allowed state, and it is the one that breaks on 1 August 2026.

This is also why the pattern is so common among Synapse Link users on D365. If you stood Synapse Link up with the enterprise policy and managed identity option, which lets Dynamics 365 write to the storage account directly while the firewall stays on, then "Enable from selected networks" is exactly the configuration you end up with. If you did not use the enterprise policy option, you had to leave the storage open to all networks instead, which drops you back into the wide-open case above. Either way, the more secure, locked-down setup is the one affected by the deadline.

On the workspace side, the at-risk condition is just as easy to confirm. Open the workspace in the Azure portal and look at the Overview page. If "Managed virtual network" reads No, that is the property you cannot change after creation, and it is the reason a rebuild may be required.

One further caveat applies to the storage check. The probe above looks at the storage account, but the same trusted-services logic applies to any Azure Key Vault your workspace reaches through a firewall. If your storage turns out to be open but you have a firewalled Key Vault that Synapse reaches as a trusted service, that path is on the same timeline, so confirm both.

That is the whole diagnosis. It genuinely takes about five minutes, and it is free. Knowing where you stand is the part you can do yourself today.

Two common but incorrect conclusions

Two readings of the portal appear reassuring and are not.

The first concerns public network access. Seeing "Enabled" on that setting is not the same as wide open. "Selected networks" still shows as Enabled, because the public endpoint exists, but it sits behind a restricted firewall, and that restricted-plus-trusted-services state is precisely the at-risk pattern.

The second concerns a private endpoint on the storage side. If your team added a customer-side private endpoint to the storage account, it is reasonable to assume that covers you. It does not. A Synapse workspace without a managed virtual network still routes its traffic over the public endpoint using the trusted-services bypass, so a private endpoint added on the storage side does not carry the Synapse traffic. The endpoint that matters is a managed private endpoint from the workspace, and that requires the managed virtual network you cannot add later.

Do you need to rebuild? Walk the decision

Two questions decide most of this: whether you are on the trusted-services path at all, and whether the managed virtual network was enabled when the workspace was created. Everything after that is scoping. Here is the whole decision in one view.

Decision flow: do you need to rebuild your Synapse workspace before the 1 August 2026 trusted-services retirement?

Who this hits hardest

The group most affected is Microsoft Dynamics 365 Finance and Supply Chain customers who use Synapse Link. The retirement actually reaches Synapse Link for Dataverse more broadly, including the customer engagement apps as well, so do not assume you are exempt simply because you are not a finance and operations shop. That is a large population, and many of them are not deep Azure specialists. They adopted Synapse Link because it was the supported way to get D365 data into a lake, not to take on Synapse networking.

Many of these same customers were recently moved off Export to Data Lake and onto Synapse Link or Fabric Link. The teams that chose Synapse Link completed the migration they were directed to make, and those without the managed virtual network enabled now face another transition soon after.

The fix, at a high level

Because the managed virtual network can only be enabled when a workspace is created, the remediation is to stand up a new workspace with it enabled and migrate your work onto it. There is no in-place toggle that makes this go away.

This does not have to mean an outage. The new workspace can run in parallel with the old one, and the old one keeps working right up until you choose to cut over. The deadline forces a rebuild, but it does not force downtime, so the work can be planned deliberately rather than compressed into a high-risk maintenance window near the deadline.

How involved the rebuild is depends entirely on what you built. A workspace that only uses Synapse Link and external tables to read from an ADLS account is a contained move. A workspace with dedicated SQL pools and a large set of pipelines is a substantial migration that requires testing. The effort is not uniform, so it should be assessed against your actual environment rather than estimated with a single figure.

Map your downstream consumers first

If I could recommend one thing before touching anything else, it would be to inventory everything that consumes the current workspace. A new workspace very likely means a new Synapse serverless endpoint hostname, and every connection pointed at the old hostname has to be repointed.

The range is wide. A single ETL connection into a downstream warehouse is the easy case, because there is one owner and one connection string. Analysts connecting directly from SQL Server Management Studio are harder, because the connections are scattered and you may not know who all of them are. Scheduled jobs that pull data into an on-premises database are harder still, because they run unattended, so a broken hostname shows up as silent missing data rather than a loud error.

The networking change is the same regardless of how many consumers you have. The repointing is where the effort actually lives, so map it before you commit to a timeline.

Bottom line

Do not wait. The date is 1 August 2026. If you have not addressed this before then, there is a real risk that your Synapse workspace stops working for these paths. Run the self-check above today, confirm whether your workspace has the managed virtual network enabled, and if it does not, begin planning the new-workspace move and the downstream repointing while you still have runway. There may be exceptions for customers who genuinely cannot transition in time, but that is not something to plan around. Treat the date as firm.

The diagnosis is the part you can do yourself, and I have included all of it here on purpose. The rebuild and the migration are a different matter. They involve real work and real risk, and the difference between a controlled, no-downtime cutover and a last-minute effort comes down to planning and experience. That controlled, parallel migration is the kind of work my data and analytics team at Alithya does. We can run the assessment, confirm exactly where you stand, and put together an estimate for the rebuild and the downstream repointing scoped to your actual workspace rather than a generic one. If you would like that, I am glad to talk through your specifics.

References

Databricks for Engineering, Fabric for Reporting

2026-05-30T00:00:00Z

A lot of the architecture debates I sit in treat Microsoft Fabric and Databricks as rivals, where one has to win the whole stack. In practice I keep landing somewhere more boring and more useful: do your data engineering in Databricks, do your reporting in Fabric and Power BI, and connect the two so the Databricks output flows into Power BI with little or no copying. This post is my field notes on making that pairing work, including the clean path and the messier workaround I needed when the clean path was off the table.

One caveat before I start. This space moves fast, and Microsoft ships changes to Fabric on a cadence that makes any "Fabric can't do X" statement risky. Everything here is current-state and experience-based as of this writing. Some of it will age.

Why Databricks for the engineering, right now

Plenty of enterprise organizations already prefer Databricks for their heavy data engineering, and in my current experience that preference is well founded. For enterprise-grade pipelines, Databricks tends to be the more reliable place to do the work today, and I will give one concrete reason rather than hand-wave. In the Fabric lakehouse, scheduled jobs and similar items have often been tied to the identity of the individual user who set them up, rather than to a durable workspace identity or a service principal. For an enterprise that is fragile. People change teams and leave companies, and you do not want a production refresh quietly bound to one person's account. To be fair, Fabric workspace identities have been improving, and I am hopeful this rough edge gets resolved soon. I am describing where things stand in my hands, not handing down a permanent verdict.

Why Fabric for the reporting

The flip side is that Databricks is not always the best place to serve reports. Microsoft has been moving quickly on the reporting side of Fabric and Power BI, and that pace is hard to ignore. Direct Lake semantic models, the tight OneLake integration, and the general Power BI experience make Fabric a strong reporting layer. So instead of forcing one tool to do everything, pair them. Engineer in Databricks, report in Fabric, and the interesting question becomes how you connect the two without paying for the data twice.

The clean path: shortcuts and Direct Lake

When everything lives in one tenant, the integration is close to a no-brainer.

Databricks writes Delta Lake tables, which are Parquet files plus a transaction log, into ADLS Gen2 (Azure Data Lake Storage). From your Fabric lakehouse you create a OneLake shortcut that points at those Delta tables. A shortcut is a reference, not a copy, so the data stays where Databricks wrote it. On top of the shortcut you build a Direct Lake semantic model, and Power BI reports straight off that data.

Two wins fall out of this, and they are the whole reason the path is so attractive:

There is no data copy from Databricks to Fabric. The shortcut reads the same Delta files Databricks produced.
With Direct Lake there is no import into the semantic model, so there is no data refresh to schedule. The model reads the Delta files directly. It does reframe to the latest Delta version when the data changes, but that is a metadata-only operation that happens automatically, not a copy you have to babysit.

Put those together and the workflow is genuinely pleasant. You run your Databricks jobs, the Delta tables update, and the new data is immediately available to your Power BI users, with no copy step and no data refresh to babysit. When you can use it, this is the path to reach for.

The complication: different tenants and secured storage

The clean path assumes a single tenant. On a recent engagement that assumption did not hold. Databricks and Fabric lived in separate tenants, and that changes the picture in a few ways that are worth being precise about.

OneLake shortcuts do not cross tenant boundaries, so the shortcut path was gone. The storage account behind Databricks was also secured, and in that cross-tenant situation shortcuts do not work with managed private endpoints either. For completeness I also looked at Databricks mirroring in Fabric, the Mirrored Azure Databricks catalog, and that does not work across tenants in my experience either.

It is worth keeping these three mechanisms separate in your head, because they are easy to conflate. Shortcuts are references in OneLake, mirroring is Fabric's Mirrored Azure Databricks catalog, and Delta Sharing is a Databricks sharing protocol. They are three different things, and in this cross-tenant, secured-storage scenario the first two were both off the table.

The workaround that actually worked: Delta Sharing

That left Delta Sharing, and it got the data into Fabric. This path does copy the data, which sounds like a step backward, but the copy turned out to be cheap. Delta Sharing gives secured access to the shared tables through a token. Behind the scenes it hands the recipient short-lived credentials so they can read the underlying files. My read of the mechanics is that it hands out short-lived, pre-signed access to the files, which on Azure is effectively a SAS-style URL, scoped and time-limited rather than a standing key.

The Fabric side took some setup. Here is the sequence that worked for us:

Create a custom Fabric Spark environment. You want a dedicated environment, not the default one.
Install the Delta Sharing library into that environment. The cleanest way is to add it as a Spark property on the environment. Set spark.jars.packages to io.delta:delta-sharing-spark_2.12:1.0.3. Pin the version rather than floating it, so a later package update does not quietly change behavior under you.
Turn off the Native Execution Engine for this environment. The Fabric Spark Native Execution Engine acceleration is not compatible with Delta Sharing in my experience, so you do not use that acceleration here. In practice that means unchecking the native execution engine on the Acceleration page and setting spark.gluten.enabled and spark.o3exec.enabled to false in the Spark properties.
Connect to the Delta Share from that environment and read the data.

Here is what the Spark properties on the environment end up looking like:

And the Native Execution Engine stays off on the Acceleration page:

One more safety net. If you cannot guarantee the environment has the Native Execution Engine off, or someone turns it back on later, you can force the right behavior from inside the notebook. Setting these at the top of the notebook pushes Delta Sharing reads down the V1 source path and keeps the session off the native engine, so the notebook still runs:

spark.conf.set("spark.native.enabled", "false")
spark.conf.set("spark.gluten.enabled", "false")
spark.conf.set("spark.sql.sources.useV1SourceList", "deltaSharing")  # force V1 source path

There was one more wrinkle around security. The share was locked down, so I used managed private endpoints from the Fabric workspace to the Delta Share's ADLS resource. That combination worked well. Note the contrast with the shortcut case: shortcuts plus managed private endpoints did not work cross-tenant, but reading a Delta Share over managed private endpoints did.

Performance: the copy is not the dealbreaker it sounds like

The obvious objection to this workaround is that you are copying data, and copying feels slow and expensive at enterprise scale. In practice it was neither. On the capacity we had, we copied a table of about 1.3 billion rows in just a few minutes, and that was a full copy. Moving to an incremental copy, where you only pull what changed, would very likely bring it under a minute. So while the clean shortcut path is still the one I prefer when it is available, the Delta Sharing copy is fast enough that I would not let "but it copies" talk me out of it.

A side note: Copilot in Fabric notebooks has caught up more than I expected

While I was doing all of this Fabric and Databricks work in notebooks, I went back and tried Copilot in the Fabric notebooks again, almost by accident. I was surprised by how much it had improved.

For a good while, Databricks was clearly ahead here. The assistant inside Databricks notebooks could take a prompt and add cells, modify cells, run and test them, and troubleshoot, all with very little hand-holding. Microsoft's Copilot lagged that for months, and I had quietly filed it under "not there yet."

Microsoft has since closed a lot of that gap. As of when I last looked, Copilot in Fabric notebooks can do much of the same. It can modify the notebook, it carries the context of the whole notebook, and it can even look at other notebooks in the workspace. I have not tried going across workspaces yet. Here is a concrete example: you can point it at an older version of a notebook saved under a different name and say "this one works but this new one does not, what is going on," and it will work through that, execute cells, test, troubleshoot, and make changes without much interaction from me. That was a real improvement.

The lesson I want to leave you with is simple. These AI tools change constantly, so if you do not go back and re-try them, you will not actually know what they can do today. I make a point of staying current on Copilot specifically, because many clients are limited to Copilot and cannot freely use Claude or other frontier models. Copilot still lags the frontier models in general capability, and Claude is one example that is ahead. But the gap moved, and it pays to re-test your assumptions rather than carry last year's verdict. When a client genuinely needs something only another model handles well, that becomes a real and worthwhile conversation about getting them the right subscription, whether that is Anthropic's Claude, ChatGPT, or whatever fits best.

Field notes, not a verdict

That is the shape of the pairing as I have been running it: Databricks for the engineering, Fabric and Power BI for the reporting, the OneLake shortcut and Direct Lake path when tenants and storage allow it, and Delta Sharing through a custom Spark environment when they do not. I have tried to flag which parts are documented behavior and which parts are simply what worked for us, because this is a fast-moving target and some of these edges will move.

I am genuinely curious what other people are doing with hybrid architectures. If you have paired Fabric and Databricks, or stitched together some other combination across tenants, I would like to hear how you handled the seams.

Does the gold layer always have to be a star schema?

2026-05-30T00:00:00Z

I get a version of this question often. In the gold layer of a medallion lakehouse, do you always recommend a star schema? It is a fair thing to ask, because the star schema is the default answer most of us reach for, and for good reason. I have built Kimball-style data warehouses for decades, and the star schema has earned its place a thousand times over.

A couple of years ago my answer would have been an unqualified yes. I believed there was always a way to shape the data into a star schema that the business could use. If a model felt awkward, that was a sign I had not found the right grain or the right conformed dimensions yet, not a sign that the star schema itself was the wrong tool. Then I met a group of users who changed my mind.

The reality that challenged the dogma

These users were not report consumers in the usual sense. They were analysts, and they worked the way analysts on the TV show "24" work. Think of the intelligence analysts piecing together fragments from many different sources, under time pressure, to make a fast decision. My users did the same thing with their own data. They pulled from many places at once and assembled an answer in the moment.

A lot of what they needed arrived from outside their own systems. They received emails from vendors and partners, took that external information on the fly, and blended it with data from their internal systems. They needed many different kinds of information, and a great deal of it landed in Excel.

I want to be honest about the Excel part, because normally I steer users away from Excel and toward governed Power BI reports, and that is usually the right call. This was a legitimate exception. Excel has real uses, and this was one of them. These analysts were already pulling data into spreadsheets and building formulas by hand, copying and pasting, matching and cleaning manually. It was genuinely impressive to watch. They flew through spreadsheets and built formulas on the fly faster than I could follow. It was also entirely manual, and much of the logic lived only in their heads, unsupported by any governed source of truth.

Why a star schema would have failed them

You can put a PivotTable over a star schema, and for many users that is exactly the right experience. For these analysts it would not have been enough. They would still have been hand-building their working datasets with formulas every time, because the data they needed was spread across multiple tables that they would have had to understand and join themselves.

That joining is the friction that matters here. A star schema asks the consumer to know which dimension connects to which fact and on what key. For a report author or a semantic model, that is a feature. For an analyst who is moving fast and blending in external data by hand, it is a tax on every single task. The friction of understanding and joining multiple tables would have made the star schema nearly impossible for them to benefit from. We would have shipped something technically correct and practically unusable.

What we built instead

After a lot of fretting, and I will admit this went against instinct, we built a very wide, flattened model. We took the dataset these analysts needed and flattened it into a Microsoft Fabric Direct Lake semantic model: one big wide table that combined the master data and the transactions together. No joins left for the user to perform.

I will be honest that the scale made me nervous. This is a very wide table, several hundred columns across, and the dataset runs to more than a hundred million rows. I expected to pay for that at query time. The Microsoft Fabric Direct Lake semantic model handled it far better than I anticipated. Queries come back quickly and the model stays responsive, even at that width and that row count. Direct Lake only pulls the columns a given query actually touches, so a very wide table does not cost you the way you might fear.

From Excel, the analysts connect to that model and pick the fields they need. This is Analyze in Excel against the Power BI semantic model. The model exposes the fields directly, so there is no manual table stitching. They get a PivotTable or a clean dataset where everything is already in one place, with no joins to get right. The more advanced users were trained to blend and join additional tables on top of that, but not every user could do that, and that was the point. The wide flat table met them where they were instead of demanding they come to the model.

The gold layer is not a single shape

Here is the reframing I want you to take away. The gold layer is not one shape, and you do not get only one of it. You can have more than one gold layer for different consumers.

In this case we built what I have started calling a gold Power Query layer: a flattened model purpose-built for these analysts. A conventional star-schema gold layer can still exist right alongside it, serving the reports and semantic models that want a star. Other gold layers can be shaped differently again for other use cases. None of them are wrong. They are answers to different questions.

A star-schema gold layer for report authors and Direct Lake semantic models that benefit from conformed dimensions and clean grain.
A wide, flattened gold layer for analysts who blend on the fly and cannot afford to join tables themselves.
Room for more shapes as new consumers show up with needs that neither of the first two serves well.

A medallion lakehouse with two gold layers: a star-schema Gold for Power BI, and a wide, flattened PQ Gold for Excel.

Most data warehouse and lakehouse architects, myself very much included until recently, would reflexively insist on the star schema. This is a case for looking twice. The job is to serve the consumer, not the dogma.

The payoff

Had we shipped a star schema, these analysts would have been stuck with something they could not use. Instead their work accelerated, because the datasets now arrive with everything already blended. They write far fewer Excel formulas and spend far less time piecing things together. They still blend in external datasets when they need to, because that is the nature of the work, but the job is much easier now that the internal side comes pre-assembled and trustworthy.

There is one more payoff, and it is the part I find most interesting. With clean, pre-blended, trustworthy data sitting in that model, the analysts can build reusable components and bring AI into the loop. They can use AI to combine the Power Query datasets with their external data and get what they need without writing queries or Excel formulas at all. The hard part of that has always been trusting the joins, and the flattened model takes that worry off the table.

Making clean, joined, trustworthy lakehouse data available for both people and AI to consume, without anyone having to worry about getting the joins right, has been a real unlock. That is worth going against instinct for. So the next time someone asks me whether the gold layer has to be a star schema, my honest answer is that it depends entirely on who is standing on the other side of it.

How this blog gets made: HAL, a terminal, and a little BBS nostalgia

2026-06-05T00:00:00Z

A few months ago I started spending real time in Claude Code, and something about it felt familiar. I was working entirely in a terminal, typing into a prompt and watching text scroll back at me. It took me straight to the mid-1990s, when I would dial into a local bulletin board system and live inside those sixteen-color ANSI screens, listening to the modem handshake and then waiting my way into a world drawn entirely from text characters. Claude Code brought all of that back. The difference is that it is far more capable than any BBS I ever called. Working in a terminal in 2026 feels backwards. It is also, I have come to think, part of why it works.

A system of specialists

Over those months I built a multi-agent system on top of Claude Code and named it HAL. The idea behind it is simple. Instead of asking one general-purpose assistant to do everything, HAL spins up specialist subagents, each focused on a single kind of work. One specializes in marketing content. One formats Word documents to a brand standard. One does web design. One writes SQL and DAX and builds Power BI reports. HAL can also use Claude Code to build MCP servers, the connectors that let an agent read from systems like Dynamics 365.

Dividing the work this way buys accuracy. A generalist who is good at many things, handed a long list of instructions, will eventually make mistakes. Give a narrow, well-defined task to a specialist, and the work comes back noticeably better. Smaller and more focused leaves less room to hallucinate.

The roster is not fixed, and that is the part I find most useful. HAL keeps a dispatcher, ABRAXAS, that watches the work coming in against the specialists already on hand. When a task needs a skill none of them have, ABRAXAS hires a new specialist built for exactly that job. Every new hire then passes through ARGUS, a security agent that audits it and clears it before it can touch real work, and flags anything that looks wrong for me to review. That is the same reason you would not give a new employee production access on their first day. Several of the specialists below began as a gap that needed filling.

Here is the current crew, grouped by what they do.

Build and model the data:

CORTANA: Microsoft Fabric and lakehouse engineering
DAEDALUS: data warehouse and lakehouse architecture, Kimball and dimensional modeling
V'GER: Dynamics 365 Finance and Supply Chain data
GERTY: Dynamics 365 finance and operations, the functional side
SHODAN: Dynamics 365 customer engagement and CRM data
NEBO: SAP schema research and table profiling
SAMANTHA: Power BI dashboards, KPIs, and semantic models
NOMAD: naming conventions and data-modeling standards

Research, write, and package:

MOTHER: research and competitive intelligence
WINTERMUTE: statements of work, estimates, and proposals
TRON: document and presentation formatting to a brand standard

Check the work:

DEEP THOUGHT: architecture and design review
GLaDOS: QA, testing, and data validation

The list keeps growing, and it is only a slice of the full crew. When a job calls for a skill none of them have, HAL adds a specialist for it, which is how several of the names above came to exist.

Every piece of work goes through review, and that rule matters as much as the specialists themselves. When something is produced, a separate agent reviews it, and it usually gets sent back for revision. Sometimes it cycles through several rounds before it ever reaches me. The review step is not optional. It is the difference between work that looks right and work that is right.

How HAL works: one orchestrator delegates each task to a focused specialist, a separate agent reviews the result, and only approved work comes back to me. Approved posts are then committed to Git, and the host publishes automatically.

How the site itself got made

So how was this website built? I asked HAL to build it.

We started with the name. I described what I do, the work in Fabric and lakehouses and the broader data world, and it came back with a list of candidate domains. Most of the good ones were taken, but FluentLake was available, so that settled it.

Then came hosting. I wanted something simple and inexpensive, and there was a static hosting option for about two dollars a month. At that price it was worth a try. I pointed Claude Code at it and said, let's design a site for fluentlake.com.

I told it what I wanted the blog to be, the kind of things I would write about, and who it was for. It came back with three design directions to choose from, each with its own logo, color palette, and overall feel. I picked the one I liked.

We talked through how to deploy to static hosting, and it researched the options and settled on Eleventy, a static site generator, as the framework. From there it built the whole site. All of that happened in the span of a couple of hours.

Writing by talking to a terminal

What I have now is a writing workflow that fits the terminal-first theme. I have voice recognition enabled in Claude Code, so I dictate what I want a post to be about. HAL writes it up using its subagents, runs it through review, and hands me a preview. I read it, ask for changes, and when it is ready, it commits the post to a Git repository. My web host watches that repository and syncs automatically, so the moment a change is pushed, the site updates.

From dictation to live: I talk, HAL writes and reviews, I approve, the post is committed to Git, and the host publishes it automatically.

The part I did not expect to enjoy this much is what is missing. There is no content management system. A site like this would normally mean standing up a CMS, which is more software to configure, more to maintain, and more to pay to host. Claude could configure a CMS too, but I do not need one. Claude is my CMS. I describe the change I want, and it makes it. I am not clicking through admin panels or guessing what a template will do to my layout. I describe the outcome, and it happens.

Backwards, and better

It seems backwards to create a website and blog posts via terminal. It is also the simplest publishing workflow I have ever had. The old ANSI terminal is back, only this time it designs the site, writes the posts, reviews its own work, and ships it. The BBS days were good. This is better.