Posts

Infrastructure as Code for the Agentic Cloud: AWS-First and Multi-Cloud Patterns

Infrastructure as Code for the Agentic Cloud How infrastructure strategy changes when moving from AWS-first to multi-cloud agent platforms Infrastructure as Code has traditionally been concerned with relatively predictable things: networks, compute, storage, databases, identity, queues and deployment pipelines. Agentic systems change the shape of that infrastructure. An AI agent is not simply another workload running in a container. Production agents increasingly require a collection of capabilities around them: runtime isolation, model access, memory, tool connectivity, workload identity, policy enforcement, evaluation, tracing and sometimes communication with other agents. Cloud providers are responding by building increasingly complete agent platforms. AWS has Amazon Bedrock AgentCore. Microsoft has Foundry Agent Service. Google has been evolving its managed age...

Beyond Agent Frameworks: The Emerging AI Harness Stack

Why LangChain, Strands, Pi, Omnigent and a new generation of agent infrastructure point to a shift in how we build AI systems For the last few years, much of the conversation about building AI applications has revolved around agent frameworks . LangChain became one of the best-known examples. Then came alternatives such as LlamaIndex, AutoGen, Semantic Kernel, CrewAI, Pydantic AI, Mastra, Strands, Google ADK and the OpenAI Agents SDK. The usual comparison looked something like: Which framework has the best tool calling, memory, RAG, multi-agent support and model integrations? That is increasingly the wrong question. By the middle of 2026, a different architecture was becoming visible. The basic model-and-tools loop was no longer the interesting part of an agent system. Pydantic put it particularly clearly when announcing Pydan...

Your Micro-Frontend Shell Should Be a Platform Runtime, Not a Layout Wrapper

Your Micro-Frontend Shell Should Be a Platform Runtime, Not a Layout Wrapper Build the host shell as an enterprise runtime, extract it into its own remote, and keep startup fast. Most teams that adopt Module Federation start by treating the host shell as a layout wrapper: a header, a sidebar, and a <div> where the active micro-frontend (MFE) mounts. That works until the second team ships. Then every remote reinvents auth, every remote wires up its own HTTP client, navigation drifts, and telemetry is a different shape in every product area. The shell is the wrong place to be minimal. In an enterprise SPA hosting Module Federation MFEs, the shell should be a platform runtime — it owns the cross-cutting enterprise runtime so each remote can focus on its own domain. This post walks through three decisions, in order: What the runtime should own (and what it shouldn't). Where that runtime should live — and why, at scale, you extract it out of the shell entirely....

Supercharging AI Coding Agents: A Deep Dive into My Custom Skills Repository

The rise of AI coding agents, like Claude Code, has fundamentally changed how we write, review, and ship software. But out of the box, even the most advanced models can lack the structured, context-aware workflows that seasoned engineers rely on. That’s why I created fabianmagrini/skills —my personal directory of custom skills designed to extend coding agents that support the Agent Skills standard . If you're looking to transform your AI coding assistant from a generic code-generator into a rigorous, end-to-end engineering partner, here is a look at what the repository offers and how you can use it to level up your workflow. What are Agent Skills? At their core, skills are reusable, invocable prompts that extend the capabilities of your coding agent. Each skill lives in its own directory and is triggered via a simple slash command. Instead of writing out a massive, detailed prompt every time you want your AI to perform a comp...