Sakura Sky

The first edition of the Executive AI Playbook was drafted when AI was, for most enterprises, a recommendation engine - a model that suggested and a human that decided. That assumption no longer holds for the deployments that matter most. Agents act. Marginal inference cost falls roughly 10x a year. The sourcing question has moved decisively past public vs. proprietary. v1.1.1 addresses all three shifts directly: https://lnkd.in/eZNBr8SK

Your bank has known the same customer for years. It knows them four different ways, and the four do not agree. Onboarding holds a passport and a verification date. The fraud engine holds a pattern of devices and spending. The AML system holds a risk rating and a stack of cleared alerts. The app and the contact centre hold a name and a service history. Four systems, four versions of one person. The customer feels the seams: repeat verifications, held payments, an address updated in one place and nowhere else. The people who defraud banks feel them too, and for them the seams are the opportunity. The bank's view of the customer is split four ways. The criminal's view is whole. Fraud, financial crime, KYC, and customer experience have quietly become the same engineering question, and most banks' identity layer cannot yet answer it. In the closing post of our Financial Services Engineering series, we look at why the fragmentation happened, what a unified identity layer actually is, and the part most teams underestimate: unifying that data and defending it are the same project, not two. Read it here: https://lnkd.in/ePvuth5K #Banking #FinancialServices #IdentityManagement #FinancialCrime #DataEngineering

Less than 5 minutes downtime with zero data loss, this is the story of an AWS to GCP migration. We recently moved a live real-time communications platform from AWS to Google Cloud for 11Sight. Calls are their product, so taking the platform offline for a weekend was never an option. The final cutover window was planned at 45 to 90 minutes. Users saw less than 5. Zero data loss. What made that possible was mostly unglamorous cloud engineering: * Landing zone before workloads. Enclave, our Terraform blueprint, laid down the org structure, IAM, Shared VPC, centralized logging, and an HA VPN back to AWS before a single workload moved. * Everything as code, owned by the client. Every resource defined in Terraform from day one, in repositories created inside 11Sight's own environment. Close-out had nothing to hand over because 11Sight already controlled all of it. * Rehearse before touching production (nothing new for those that have been here before). A full staging environment (GKE, Cloud SQL for PostgreSQL, Memorystore, Compute Engine autoscaling groups) let the team run the entire migration end to end, validate VPN latency against production thresholds, and put a measured number on the downtime window. That environment stays on as a proving ground for future releases. Full case study: https://lnkd.in/eqqfmkr4 Special thanks to Farokh Eskafi and team. #CloudEngineering #Terraform #GoogleCloud #IaC

The Executive AI Playbook v1.1.1 is out. Our co-founders Andrew Stevens and Olivia S., with Bill Sanders and Jennifer Capo, have substantially expanded the playbook for the 2026 reality: agents that act, inference costs falling roughly 10x a year, and a sourcing question that has moved past public vs. proprietary. What's new: ✦ A three-layer taxonomy for the 2026 AI stack - specialized, frontier, agentic ✦ Three sourcing paths - frontier API, retrieval-augmented hybrid, fully custom ✦ A governance framework for AI that acts: action risk vs. model risk, scope-of-action charters, the human-in-the-loop spectrum ✦ A unit economics chapter - pricing intelligence when marginal cost falls 10x a year ✦ One contrarian stake: most enterprises should not build proprietary foundation models Written for CEOs, boards, and senior executives. Free download. https://lnkd.in/edu5aRyb

The enterprise AI post-mortems I read have changed. It used to be misunderstood problems and weak data. Now it's the same three findings every time: the agent behaved differently today than it did yesterday, the model asserted something that doesn't exist, and nobody could give the auditor an answer that survived scrutiny. Determinism failures. Hallucinations. Compliance gaps. Three symptoms, one defect. Nothing machine-readable says what exists in your business, how it connects, and what actions are allowed, by whom, with what trace. That artifact has a name: an ontology. It grounds what your agents may assert, pins what they may do, and produces the evidence when someone asks why. Here's the important bit: your vendors have worked this out. The ontology is becoming the platform moat of the AI era, and it gets built from your operations, your edge cases, and your people's time. Workflow lock-in is dying; semantic lock-in is replacing it. You can export every table you own and still be unable to leave, because the map of what the tables mean stays behind. My position: author the ontology yourself. Version it like code, in a neutral format, in a repo you control. Let the platforms compile it. If a vendor's engineers help you extract it, contract for the definitions as a named deliverable. Build the map. Let the platforms render it. Never let them own it. Full argument: https://lnkd.in/excktYq2

Trust Is an Engineering Output Being correct is not the same as being able to prove it. This final post in The Engineering Underneath argues that trust is an engineering output produced when sovereignty, load, evidence, telemetry, and multi-cloud are each engineered correctly, and previews the industry deep-dives still to come. https://lnkd.in/eq4uR4SZ

Multi-Cloud Versus Consolidation Most enterprises already run several clouds, whether they chose to or not, so the real question is not whether to consolidate but how to engineer coherence across what they already have. This fifth post in The Engineering Underneath sets out five things multi-cloud actually demands, and argues the answer is a control plane that spans clouds rather than standardisation inside each one. https://lnkd.in/eVXU96Qs

Telemetry Is Becoming the Business Operational telemetry has moved from a back-office by-product to one of the most valuable assets a business owns. This fourth post in The Engineering Underneath argues that the infrastructure built for exhaust data is wrong for a strategic asset, and that telemetry now has to be engineered as a first-class data product. https://lnkd.in/eD745eS5

Regulated organisations have long optimised for speed and assumed the evidence could be assembled later. This third post in The Engineering Underneath diagnoses why that assumption has finally broken, and argues that evidence is now an architectural property of the data and execution layers rather than a documentation exercise. https://lnkd.in/eKi8nNUh

When peak load was an event, it was a project. Retail had Black Friday. Media had launch day. Sport had grand finals. Traffic curves were forecastable, warrooms were staffed, and capacity was released the following Monday. That world is gone in most consumer-facing sectors, and the architectural assumptions have not caught up. The named peaks still happen. But a single video from a creator can now drive more traffic than a planned campaign. A retail brand can wake up on a Tuesday to a fifteen-times surge because a product went viral. A streaming platform can see peak concurrency exceed launch day because a scene became a meme. And underneath the customer-facing layer, the data pipelines that used to run overnight now run continuously, because personalisation and fraud scoring cannot tolerate stale data at machine speed. Peak load is no longer an event. It is the operating condition. The architectures that survive share five properties: continuous capacity planning, graceful degradation designed in, cell-based fault isolation, observability that runs all the time, and intelligent load shedding that preserves what actually matters when the surge exceeds elastic capacity. These are not new inventions. They are the disciplines telecommunications engineers have used for decades. They are becoming the ordinary requirement for any business whose customer trust depends on reliability at machine speed. New from the Sakura Sky blog, part two of The Engineering Underneath. https://lnkd.in/ef3vVX9e #Cloud #Resilience #Architecture #Engineering #DataPlatforms