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.

1. Making Prompts Cheaper, Smarter, and Controlled​

For too long, prompts have been treated as static strings—write once, hope for the best, and throw compute at the problem. That's changing fast.

LLMLingua for Prompt Compression
Using compression techniques and tools like LLMLingua and JSON minify, you can aggressively compress long inputs—documents, logs, specifications—while preserving task-relevant signal. The result? Lower latency, reduced costs, and the ability to fit more context into model windows without hitting token limits. For Bedrock-style workloads handling enterprise documents, this matters.

Bedrock Intelligent Prompt Routing (GA)
Instead of hard-coding a single model for all requests, Intelligent Prompt Routing dynamically selects the optimal model in a family based on quality and cost criteria. This isn't an R&D experiment anymore—it's a first-class Bedrock feature in general availability.

→ Net effect: Prompts become an optimized, governed resource. You're not just throwing raw text at the most expensive model and hoping. You're treating prompts as engineered artifacts with compression, routing, and cost controls built in.

---

2. Enterprise-Grade Observability for AI Systems​

If agents are going to run multi-day workflows, make autonomous decisions, and touch production systems, we need observability that goes beyond "did it finish?" We need to understand how it finished, why it made specific decisions, and where it's degrading over time.

CloudWatch Application Signals Enhancements
The new capabilities—service maps, grouping, and Transaction Search—provide end-to-end visibility into distributed services. Critically, you can now trace 100% of spans into CloudWatch Logs without throttling. For agentic workflows that span multiple services, APIs, and tool invocations, this is essential.

AgentCore Evaluations
Built-in continuous evaluations for Bedrock AgentCore allow you to score agents on correctness, helpfulness, harmfulness, and other criteria based on real interactions—not synthetic test cases. This closes the feedback loop between agent behavior and quality measurement.

We're getting closer to "APM for agents": Service-level objectives, automated evaluations, and distributed tracing—not just vibes and anecdotal success stories.

---

3. Trust You Can Engineer and Test​

This is where re:Invent 2025 delivered something fundamentally new: trust as a first-class engineering concern, not a compliance checkbox.

AgentCore Policy + Evaluations
AgentCore Policy provides real-time, deterministic controls on what agents can do—fine-grained gates on tool calls, data access, and external integrations. Combined with Evaluations, you get both preventative boundaries and continuous quality monitoring. It's the difference between "we hope the agent behaves" and "we enforce and measure how the agent behaves."

Fault Injection Service (FIS) for Agentic Chaos Testing
This is what I've been waiting for. AWS is now explicitly positioning FIS for multi-step, agent-based systems. The guidance and sessions focused on stress-testing failure modes like:

• Decision loops where agents get stuck
• Task handoff failures between agents or humans
• Resource contention under load
• Cognitive boundary violations

Chaos engineering is extending beyond infrastructure resilience into cognitive boundaries, ethical guardrails, and decision-making under adversarial conditions. This is the next frontier for agent reliability in regulated environments.

Trust becomes something you build, measure, and validate—not something you hope for.

---

4. Durable Execution for Real Workflows​

Agent demos often show impressive 30-second interactions. Production reality involves workflows that span hours, days, or weeks—with failures, retries, human approvals, and external dependencies.

Lambda Durable Functions
This addresses a critical gap: long-running, multi-step workflows that can checkpoint their state, pause for up to a year, and resume after failures without you building custom state machines or orchestration infrastructure. It's clearly positioned for complex agent orchestration, approval flows, and multi-service coordination.

For serious agentic systems in financial services—think KYC reviews, screening workflows, periodic compliance checks—durable orchestration inside the Lambda developer experience is a game-changer. You get reliability without the operational overhead of managing separate orchestration platforms.

---

5. Spec-Driven Development for Agents​

Outside the AWS announcements themselves, I'm seeing an emerging pattern in how teams are actually deploying agents successfully: spec-driven development.

The approach: write a detailed design specification and task breakdown, then let the agent implement tasks one by one against that specification. The spec becomes both the source of truth and the safety contract.

Combining this with the new AWS capabilities creates a powerful model:

• Specs as the source of truth and safety contract
• Agents as spec executors, not free-form coders
• Policy/Evaluations/FIS as runtime enforcement and feedback

This mirrors what we've experienced with tools like AWS Kiro, GitHub Copilot and similar coding agents. The constraint—requiring a spec upfront—actually increases both quality and trust. The agent isn't improvising; it's implementing against a verifiable contract.

---

My Conclusion​

re:Invent 2025 marks the inflection point from "new models and agents" to "operational, observable, governed AI systems that can run for days, survive faults, and pass audits."

The frontier models—Nova 2, Forge, the expanded model families—are still advancing rapidly. But the real story is this: we finally have the building blocks to treat agents as production software, not conference demos.

For those of us building AI in regulated industries like financial services, this convergence of innovation and operational discipline is exactly what we need. The technology was never the blocker. The blocker was the gap between "it works in the demo" and "I can deploy this, observe it, govern it, and explain it to regulators."

That gap is closing fast.
The technology is ready.
The question now is: are our processes, culture, and governance frameworks ready to match it?

Warm regards,
Evangelos Liatsas
Director of Engineering
Fenergo Ltd

"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.

The Day Everything Changed (Again)​

I remember the exact moment in early 2023 when one of our senior engineers put forward a What Did Not Go Well card in our team's retrospective with the title: 'My work is doomed to be obsolete even before release.' He had just built an SQL authoring tool, and he made the argument that ChatGPT could build better SQL with just a short prompt.

This wasn't the first time I'd heard this. I've been in engineering for over 20 years - from military aircraft systems to banking compliance platforms. I've seen Y2K, the cloud migration, the mobile revolution, microservices, DevOps transformations.

But AI is different.

The pace isn't measured in years or even quarters anymore. It's measured in weeks. The skills that made someone valuable six months ago? They might be table stakes now. The architecture decisions we made with confidence? They're being questioned by foundation models we didn't even know existed when we made them.

For the first time in my career, I've watched engineers with 15 years of experience feel like they're starting over.

And you know what? That's the privilege.

What "Pressure is a Privilege" Really Means​

When Billie Jean King said "pressure is a privilege," she wasn't talking about enjoying stress. She was talking about the opportunity to compete at the highest level - to be in a position where what you do actually matters.

For engineering leaders today, the AI revolution is exactly that moment.

We're not under pressure because we're failing. We're under pressure because:

• What we build directly shapes how humans and AI will collaborate in the future
• Our decisions define whether AI empowers or replaces human expertise
• The systems we architect today become the foundations for industries we can't even imagine yet

Think about that. How many times in a career do you get to work on something genuinely transformative? Not incrementally better. Not evolutionary. Transformative.

At Fenergo, we're not just adding AI features to compliance software. We're fundamentally reimagining how financial crime fighters interact with their systems. From doing the work to orchestrating intelligent agents that do the work.

That's not pressure. That's privilege.

The Three Shifts That Define AI-Era Leadership​

Leading teams through this revolution has taught me that success requires three fundamental shifts in how we think about engineering leadership:

1. From Knowledge Keeper to Learning Architect​

I used to pride myself on having the answers. Deep technical knowledge was currency. Authority came from expertise.

Not anymore.

Today, the engineers who thrive aren't the ones who know the most - they're the ones who learn the fastest.

When we started building our AI ecosystem and our Agent Operating System, I didn't have all the answers. None of us did. AWS Bedrock was new. Multi-agent architectures were emerging. Agentic AI patterns were being invented in real-time.

My job wasn't to know everything. It was to create an environment where my team could:

• Experiment safely - We set up dedicated innovation time and hackathons (like the Athens 3-day session that birthed Kyra)
• Share relentlessly - Every discovery, every failure, every insight got documented and distributed
• Question everything - Including my own decisions about architecture and approach

The result? We went from zero to a production multi-agent platform in less than 18 months. Not because I was the smartest person in the room. Because we built teams of rapid learners.

2. From Stability to Intelligent Instability​

Traditional engineering leadership says: minimize change, reduce uncertainty, create predictable delivery.

AI-era leadership says: embrace strategic instability.

Look at our agent architecture. We're running:

• Anthropic Claude for complex document processing
• Amazon Nova Pro for real-time screening decisions
• Llama for cost-optimized binary decisions and the list goes on.

Why multiple models? Because we learned that optimization means flexibility, not standardization.

Six months ago, some of these models didn't exist. Six months from now, we might be using completely different ones. And that's not a bug - it's a feature.

The teams that succeed aren't the ones desperately clinging to their chosen tech stack. They're the ones that built for change from the beginning - using abstraction layers like AWS Bedrock that let us swap models without rewriting systems.

This requires a different kind of leadership:

• Clear principles, flexible implementations - We're rigid about our AI governance framework, flexible about which models we use
• Architecture for obsolescence - Build assuming everything will be replaced, not that it'll last forever
• Celebrate pivots - When we changed our approach to agent orchestration mid-flight, we didn't call it failure. We called it learning.

3. From Team Builder to Culture Engineer​

Here's the uncomfortable truth: some engineers won't make the leap.

Not because they're not talented. Not because they're lazy. But because the psychological shift required is enormous.

Going from "I'm an expert in React" to "I'm an expert at figuring out what I need to learn next" is terrifying. It means trading the security of mastery for the vulnerability of perpetual learning.

As leaders, we can't force this shift. But we can engineer a culture that makes it feel like opportunity rather than threat.

At Fenergo, we've done this through:

Psychological Safety at Scale​

• Our innovation culture explicitly protects "failure" as learning
• We showcase POCs that didn't work alongside ones that did
• Team members present "what I learned this month" sessions where admitting "I don't know" is celebrated

Mentorship That Goes Both Ways​

• Senior engineers learn AI from junior engineers who came in with more modern backgrounds and ideas
• Junior engineers learn system design from seniors who built our platform
• I learn from everyone - and I'm explicit about it

Recognition That Transcends Delivery​

• We celebrate learning velocity as much as shipping velocity
• Recognition for asking the best questions that challenged our assumptions
• Public acknowledgment of people who helped others learn

The result? Exceptional retention on my teams over the past three years. Not because we pay more than competitors. Because engineers feel like they're growing faster than anywhere else they could be.

The Real Cost of Not Embracing the Pressure​

Let me be direct: if you're an engineering leader trying to "shield" your team from AI disruption, you're doing them a disservice.

I've seen well-meaning leaders say:

• "Let's wait until things stabilize before we invest in AI"
• "We'll let others figure it out first"
• "Our team has enough on their plate"

Know what happens to those teams?

They become irrelevant. Not gradually. Suddenly.

Because while you're waiting for stability, your competitors are:

• Shipping AI-powered features your clients will expect as baseline
• Attracting the best talent who want to work on cutting-edge problems
• Building institutional knowledge about what works and what doesn't

The stable ground you're trying to protect? It's already gone. You're just pretending it's still there.

At Fenergo, we made a different choice. We ran toward the uncertainty. We:

• Deployed our first AI features in production while the technology was still emerging
• Let clients opt into beta capabilities knowing they weren't perfect yet
• Built our compliance framework and governance model in parallel with building features

Was it comfortable? No.
Was it risky? Yes.
Was it worth it? Absolutely.

Today, we're not catching up to AI. We're defining what AI-powered compliance looks like. We're the ones others are trying to copy.

Practical Strategies for Leading Through Constant Change​

Theory is nice. Tactics matter more. Here's what actually works:

Create "Innovation Containers"​

Don't let innovation be chaos. Structure it.

We run:

• Quarterly hackathons - 2-3 days, clear themes, demo at the end
• 20% exploration time - Not just Google's policy, our reality
• POC pipelines - Clear criteria for what moves from experiment to production

This gives engineers permission to explore while maintaining delivery accountability.

Build a "Learning Stack" Alongside Your Tech Stack​

We invested in:

• Shared knowledge bases - Every AI experiment documented with outcomes
• Regular "What We Learned" sessions - Monthly, team-wide, celebrated failures included
• External expertise - AWS partnerships, academic collaborations, conference attendance budget

Make learning infrastructure as real as your production infrastructure.

Transparent Decision-Making on Tech Choices​

When we chose AWS Bedrock over building our own LLM infrastructure, I didn't just announce it. I:

• Shared the evaluation framework
• Explained the trade-offs
• Invited challenge and debate
• Documented the decision for future reference

Engineers respect leaders who think out loud, not leaders who pretend to have certainty.

Metrics That Matter for AI-Era Teams​

We track:

• Learning velocity - How fast teams adopt new capabilities (not just ship features)
• Experiment volume - Number of POCs attempted (not just succeeded)
• Knowledge sharing - Documentation contributed, sessions led, peers helped
• Retention - Are our best people staying and growing?

What you measure signals what you value. Measure learning.

Personal Vulnerability as Leadership Strategy​

I regularly tell my teams:

• "I don't know how to solve this yet"
• "I was wrong about that approach"
• "You know more about this than I do"

Not as weakness. As model behavior. If I can admit not knowing, they can too. And that's where real learning begins.

The Human Side: When Engineers Struggle​

Not everyone thrives in constant change. Some engineers are genuinely overwhelmed.

I've had conversations like: "I spent 10 years becoming an expert in this domain. Now it feels like none of that matters."

Here's what I've learned to say:

Your expertise matters MORE, not less.

AI doesn't replace domain knowledge - it amplifies it. The engineers who understand compliance deeply are the ones who can:

• Ask the right questions of AI systems
• Evaluate if AI outputs are correct
• Design prompts and agents that actually solve real problems

But - and this is crucial - you do need to learn the new tools.

It's like when we moved from waterfall to agile. Your programming skills didn't become obsolete. But refusing to learn agile methodologies would have made you obsolete.

For engineers who struggle, we offer:

• Paired learning - Work alongside someone further along the AI curve
• Focused education time - Dedicated hours for courses, experimentation, learning
• Low-stakes projects - Start with AI features on less critical systems
• Honest conversations - Sometimes the answer is: this might not be the right fit anymore, and that's okay

We've had a couple engineers choose to move to teams doing less cutting-edge work. And that's fine. Not everyone wants to live on the bleeding edge.

But for those who stay? The growth is exponential.

Looking Ahead: The Next Wave​

Here's what keeps me up at night (in a good way):

We're still in the early innings.

Everything we've built - Kyra, our Agent OS, the multi-model architecture - will look primitive in 18 months. The foundation models we use today will be obsolete. The patterns we think are best practices will be laughably naive.

And I can't wait.

Because that means:

• More problems to solve
• More opportunities to build something transformative
• More chances to prove that humans plus AI is better than either alone
• More learning for my teams

The pressure isn't going away. If anything, it's accelerating.

Good.

Because pressure is a privilege. And I'm privileged to lead teams through this revolution.

To My Fellow Engineering Leaders​

If you're feeling the weight of constant change, here's what I want you to know:

You're not supposed to have all the answers.

Your job isn't to be the expert anymore. It's to be the person who:

• Creates the environment where expertise can emerge
• Builds teams that run toward uncertainty rather than away from it
• Makes learning feel like opportunity rather than obligation
• Shows that vulnerability and leadership aren't opposites

The teams that thrive through the AI revolution won't be the ones with the smartest individual leader. They'll be the ones with the fastest collective learning velocity.

One Final Thought​

In 2023, I stood in front of my leadership team and said: "Everything we're comfortable with is about to change. We can resist it and become obsolete, or embrace it and define the future."

Some thought I was being dramatic. Drama was born in Greece after all - maybe it's just me staying true to my roots.

They don't anymore.

Because we've watched AI go from experimental features to the core of our entire platform. We've seen clients transform how they work. We've experienced our teams go from uncertain to confident to pushing boundaries I didn't even know existed.

The pressure was real. The privilege was greater.

So if you're an engineering leader feeling overwhelmed by AI's pace of change, I'll leave you with this:

You're not falling behind. You're in the arena. And being in the arena - that's the privilege.

Now go build something that matters.

Warm regards,
Evangelos Liatsas
Director of Engineering
Fenergo Ltd

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 ?