Back from AWS re:Invent 2025, and the shift is unmistakable: the industry has pivoted from "can we build agents?" to "can we run them safely, observably, and durably in production?"

Writer CEO May Habib captured the moment perfectly on stage: "The biggest barrier to scaling agents in the enterprise isn't the technology—it's trust."

This resonates deeply with the Trust-to-Deploy framework we've been building at Fenergo. Trust isn't just a barrier to overcome—it's the foundation that enables everything else. When trust is engineered into the architecture from day one, agents move from interesting experiments to systems that compliance teams actually deploy at scale.

What struck me most across the keynotes, technical sessions, and hallway conversations wasn't the model announcements—though Nova 2, Forge, and Trainium3 are impressive. It was the operational maturity on display: observability tools, chaos testing frameworks, durable execution primitives, and governance mechanisms purpose-built for agentic systems.

Here's how I see the shift, tied to specific launches and patterns I've been tracking.

"Pressure is a privilege" - Billie Jean King​

I've been thinking about this quote a lot lately. Not because I read it in a leadership book, but because it surfaces in the back of my head as I take part in every standup, every refinement session, every conversation about what we're building next.

The ground is shifting beneath us. Weekly. Sometimes daily.

And here's what I've learned after leading teams through three years of the AI revolution at Fenergo: this pressure isn't something to manage away - it's the most valuable thing we have.

Kyra in Action: Compliance with Context​

At Fenergo, we’ve started bringing this vision to life with Kyra, our conversational AI co-pilot.

Kyra isn’t just another chatbot. When a compliance officer asks: “What documents do I need for this German corporate client?” - they don’t just get a search result.

Behind the scenes, Kyra orchestrates specialized Document Agents, Policy Agents, and Journey Agents to provide an instant, accurate answer. More importantly, it explains why those documents are required, linking regulatory requirements to specific client circumstances.

Imagine the difference: instead of juggling multiple systems and chasing guidance documents, the officer gets a clear, contextual response in seconds - along with the reasoning behind it.

This matters. In compliance, the “why” is just as important as the “what.” And when only 12% of organizations say their data is sufficiently high quality and accessible for AI, and 62% cite lack of governance as their top barrier, explainability isn’t a “nice to have” - it’s the foundation for adoption (Precisely Data Integrity Trends 2025).

Over the past year as a SaaS developer at Fenergo, I've been focused on the challenge of hosting a third-party SDK inside our AWS ecosystem. My goal was to ensure the service could run in a way that scales reliably, integrates cleanly with our existing infrastructure.

To achieve this, I used Pulumi to streamline Infrastructure as Code, which made it easier to model, manage, and iterate on cloud resources as the project evolved. Wherever possible, I leveraged existing infrastructure components - such as our VPC, subnets, and security groups - instead of duplicating effort. For new requirements, I identified and provisioned the most appropriate AWS services that fit our needs, balancing performance, cost efficiency, and maintainability.

A key part of the solution was building and automating CI/CD pipelines, which allowed us to provision infrastructure, deploy updates, and run validations in a consistent and repeatable way. This gave the team confidence to roll out changes quickly while keeping downtime and risk to a minimum.

In this blog, I'll walk through the approach we took and the technical considerations behind it.

Introduction​

Hi everyone, last week we wrapped up another fantastic Client Council where I had the chance to engage with many of our clients across a variety of topics, with one consistent topic being the methods of creating and updating Entities at scale in Fenergo and which method is best suited for particular scenarios.

With that in mind, I wanted to write a small blog on how best to load Entity information into a Fenergo tenant, depending on the scenario a user might be dealing with.

Introduction​

Hello Everyone, As we continue to push the boundaries of innovation in the financial services industry, it's crucial that we address the compliance challenges that come with adopting cutting-edge technologies like artificial intelligence (AI). At Fenergo, we understand the importance of leveraging the power of AI while ensuring the highest standards of data privacy, information security, ethics, intellectual property protection and regulatory compliance. Today, I want to share with you our robust AI compliance framework, designed as a collaborative effort by our Fen-X Engineering and Privacy & Risk team, aimed at proactively mitigating risks associated with AI adoption in our services. The AI Compliance framework provides a standard set of criteria that are embedded in the development of all AI features by default, as well as thorough assessments being completed by the Privacy & Risk team before launch.

Introduction​

When we created our SaaS solution, we needed to design an approach for the migration of data which both complements the technology and meets the requirements of our consumers. The approach challenges the norms of traditional data migrations because a SaaS platform serves multiple tenants concurrently. The software is continuously in-flight with 99.9% uptime availability, no one tenant can impede that performance and availability of another. To understand how we achieved this, we need to look at what norms do not translate to SaaS, why they do not translate and what is the right approach for loading data to a highly available, multi-tenanted software product?

Introduction​

The WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.

We normally use WebSockets when we want to get live updates of a particular object without having to constantly poll for new updates. In this scenario, WebSockets can be helpful as they reduce the required number of API calls and in turn the cost of our infrastructure, and if the number of request is very high, the API might apply throttling.

Introduction​

EventStoreDB (ESDB) is a log stream database oriented to architectures based on event-sourcing. The data in EventStoreDB is stored into streams, and each stream contains a log of events. For this reason, ESDB is a very suitable candidate for working with event-sourcing architectures and it allows us to easily implement the CQRS pattern, where there are projections that transform the events produced by the commands into data that can be consumed by the queries.

If you're a software engineer, and love what you do, nothing beats that feeling of solving a challenge, then theres the side of the job where you are "On-Call" for support.

In Fenergo, we manage a large Globally Deployed SaaS Platform for our clients. Recently I spoke with Steve O'Rourke, one of our Directors of SaaS Engineering to talk about how we handle On Call Support at scale and importantly ask the question : Is it possible to be On Call and still have a Happy Christmas ?