Have you noticed it yet? Your organization is building AI agents across multiple teams. One team creates a customer support agent, another builds an internal knowledge assistant, and a third develops a set of MCP tools for code review. But none of these teams know what the others have built. Agents and tools are scattered across repositories, accounts, and business units with no central place to discover, govern, or manage them.

You are building an agentic solution. Your agent has access to MCP tools, and those tools perform real actions: approving expenses, issuing refunds, updating records. You write careful prompt instructions so the large language model picks the right tool for the right situation. Everything works on the happy path. But what happens when it doesn’t?

Have you experienced it already? You are working on an agentic solution and writing prompts for large language models. Where do you put your prompts? Do you write your prompt in your Python file itself? Or are you creating a separate file containing the prompt, then loading it into a variable to pass it to the model when invoking it?

As consultants, we must juggle multiple credentials, including those from Xebia. But we are also onboarded at the customers where we are hired for our assignments. I already blogged on how I separate my browser sessions for different clients. This gives me the ability to have relevant bookmarks for my assignment. This blog will continue to explain how I organize my git access and separate them per customer.

The future of AI isn’t just about smarter models—it’s about building systems that can think, act, and adapt autonomously in production environments. Moving from experimental AI prototypes to scalable, reliable agentic systems presents unique challenges that most organizations are just beginning to understand.

I built a workload using AWS Cloud Development Kit (AWS CDK), and the AWS CodePipeline stopped working at the worst moment. It was right at the end of the sprint; we had done multiple deployments before. But at this moment, the moment you might recognize. When this last PR is released, we will have met our deadline! Kaboom, the pipeline stops working, and the reason for the failure is not related to the changes you made.

Have we given up on the least privileged principle? Personally, I am a big fan of it. But let’s be honest, it can also be tough to follow the principle strictly. With the rise of AWS Cloud Development Kit (AWS CDK), it became even harder.

Ingesting data into an OpenSearch cluster looks easy if you read the documentation. The truth is it is easy, but it all depends on how much you care about the data you are ingesting. Let me go one step back. Why do we even use OpenSearch? With the rise of AI, you also need a knowledge base. These knowledge bases can be hosted in OpenSearch. However, to use the OpenSearch database, you must also fill it out with data.

Have you ever been in a situation where you want to provision or configure things cross-stack? Splitting these into logical stacks is always good when dealing with more complex environments. I already shared this in one of my previous blogs. But this also introduces a different problem!