DEV Community: Meidi Airouche

Multi-Agent Platform with A2A, Python, Strands & AWS AgentCore

Meidi Airouche — Wed, 14 Jan 2026 08:39:44 +0000

A single RAG agent is easy to ship.

But the moment you need multiple domains (HR, IT, …), different knowledge sources, and clean ownership boundaries, a single “do‑everything” agent turns into:

an unmaintainable prompt,
a tangled toolset,
and a retrieval strategy that mixes unrelated documents.

This post shows a production-shaped approach:

HR Agent: RAG over HR documents (AWS Knowledge Base ID configured via env)
IT Agent: RAG over IT documents (different KB ID)
Orchestrator Agent: routes queries by calling HR/IT agents over A2A, then synthesizes the final answer

All three are deployed as AgentCore Runtime apps : each handler is a BedrockAgentCoreApp entrypoint.

Strands Agents is a Python SDK for building LLM-based production-ready agents as first-class software components.
It abstracts prompt management, tool invocation, and agent-to-agent communication, enabling to compose complex agent systems without hard-coding control flows or glue logic.

What we are building

Components

HR Agent
- Strands Agent
- Tool: strands_tools.retrieve
- Config: KNOWLEDGE_BASE_ID (HR KB)
- Exposed as an A2A endpoint via AgentCore Runtime
IT Agent
- Same as HR agent
- Config: KNOWLEDGE_BASE_ID (IT KB)
Orchestrator Agent
- Strands Agent
- Tools: ask_hr_agent, ask_it_agent (A2A client calls)
- Config: HR_AGENT_URL, IT_AGENT_URL
- Decides routing automatically (tool choice) and synthesizes a final answer

Runtime request flow

User sends a question to the Orchestrator (AgentCore Runtime endpoint)
Orchestrator LLM decides whether to use:
- ask_hr_agent()
- ask_it_agent()
- or both
Orchestrator calls the specialized agent(s) via A2A
Specialized agent uses retrieve tool (RAG) against its Knowledge Base
Orchestrator produces a final, human‑readable answer

1 — Configuration (env vars)

This architecture is intentionally configuration-first. No hardcoded URLs or KB IDs.

Knowledge bases are created with S3 Vector base but outside of this topic since it's easy to create with 5 clics. Just collect the IDs once created.

The retrieve tool provided by strands_tools is automatically configured at runtime using KNOWLEDGE_BASE_ID, which AgentCore resolves to the correct vector store and injects into the retrieval tool execution.

HR Agent env

KNOWLEDGE_BASE_ID The Knowledge Base ID for HR content.

IT Agent env

KNOWLEDGE_BASE_ID The Knowledge Base ID for IT content.

Orchestrator env

HR_AGENT_URL

A2A endpoint for the HR Agent (for example, an AgentCore Runtime service URL).
IT_AGENT_URL

A2A endpoint for the IT Agent.
AWS_REGION (optional)

Defaults to eu-central-1 in the handler.

2 — HR Agent handler (AgentCore Runtime + RAG)

This is the complete HR agent handler.

Key design choices:

Lazy initialization: create the Strands agent only once per runtime container
Single tool: retrieve
Strict behavior: if retrieval doesn’t find anything relevant, say so

"""
HR Agent handler for AgentCore Runtime deployment with A2A support.

Requirements: 1.1, 1.2, 1.4
"""

import os
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Configuration
KNOWLEDGE_BASE_ID = os.getenv("KNOWLEDGE_BASE_ID", "")
os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID

HR_SYSTEM_PROMPT = """
You are an expert HR assistant. You answer questions related to human resources,
HR policies, leave, benefits, recruitment, and people management.

Use the retrieval tool to search the HR knowledge base.
If you cannot find relevant information, clearly state it.

Always respond in a professional and concise manner.
"""

# Lazy agent initialization
_hr_agent = None


def get_hr_agent():
    """Lazy load HR agent."""
    global _hr_agent
    if _hr_agent is None:
        from strands import Agent
        from strands_tools import retrieve

        _hr_agent = Agent(
            tools=[retrieve],
            system_prompt=HR_SYSTEM_PROMPT
        )
        logger.info("HR agent initialized")
    return _hr_agent


def handle_request(prompt) -> str:
    """Handle HR agent requests."""
    try:
        prompt_str = str(prompt)
        agent = get_hr_agent()
        response = agent(prompt_str)
        return response.message
    except Exception as e:
        logger.error(f"HR agent error: {e}")
        return f"Erreur agent RH: {str(e)}"


# For AgentCore Runtime with A2A
try:
    from bedrock_agentcore.runtime import BedrockAgentCoreApp
    app = BedrockAgentCoreApp()
    logger.info("HR BedrockAgentCoreApp initialized")


    @app.entrypoint
    def handler(prompt: str) -> str:
        logger.info(f"HR received: {prompt[:100]}...")
        return handle_request(prompt)
except ImportError as e:
    logger.warning(f"bedrock_agentcore.runtime not available: {e}")
    app = None

Why `os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID`?

Some tooling layers (including retrieval integrations) resolve configuration directly from process environment. By forcing it into os.environ, you ensure:

consistent behavior in local runs
consistent behavior in AgentCore Runtime containers

What “RAG” means here

In this handler, RAG is not manual (no explicit vector DB queries in your code).
Instead, the Strands agent uses the retrieve tool:

the LLM decides when to call retrieve
the tool pulls relevant chunks from your Knowledge Base
the response is generated with that context

3 — IT Agent handler (AgentCore Runtime + RAG)

This is the complete IT agent handler.

Same architecture as HR:

lazy init
tool = retrieve

"""
IT Agent handler for AgentCore Runtime deployment with A2A support.

Requirements: 2.1, 2.2, 2.4
"""

import os
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Configuration
KNOWLEDGE_BASE_ID = os.getenv("KNOWLEDGE_BASE_ID", "")
os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID

IT_SYSTEM_PROMPT = """
You are an expert IT assistant. You answer questions related to IT,
systems, software, technical support, cybersecurity, and infrastructure.

Use the retrieval tool to search the IT knowledge base.
If you cannot find relevant information, clearly state it.

Always respond in a professional and concise manner.
"""

# Lazy agent initialization
_it_agent = None


def get_it_agent():
    """Lazy load IT agent."""
    global _it_agent
    if _it_agent is None:
        from strands import Agent
        from strands_tools import retrieve

        _it_agent = Agent(
            tools=[retrieve],
            system_prompt=IT_SYSTEM_PROMPT
        )
        logger.info("IT agent initialized")
    return _it_agent


def handle_request(prompt) -> str:
    """Handle IT agent requests."""
    try:
        prompt_str = str(prompt)
        agent = get_it_agent()
        response = agent(prompt_str)
        return response.message
    except Exception as e:
        logger.error(f"IT agent error: {e}")
        return f"Erreur agent IT: {str(e)}"


# For AgentCore Runtime with A2A
try:
    from bedrock_agentcore.runtime import BedrockAgentCoreApp
    app = BedrockAgentCoreApp()
    logger.info("IT BedrockAgentCoreApp initialized")


    @app.entrypoint
    def handler(prompt: str) -> str:
        logger.info(f"IT received: {prompt[:100]}...")
        return handle_request(prompt)
except ImportError as e:
    logger.warning(f"bedrock_agentcore.runtime not available: {e}")
    app = None

Why separate agents instead of one big agent with two KBs?

Because the separation buys you:

independent prompts
independent retrieval scopes (no “HR policy” leaking into IT answers)
independent deployment/scaling
simpler evaluation (HR answers vs IT answers)

4 — Orchestrator handler (AgentCore Runtime + A2A tools)

Now the interesting part: the orchestrator.

Your orchestrator is a Strands agent with two tools:

ask_hr_agent
ask_it_agent

Those tools are wrappers around an A2A client call.

Orchestrator key behaviors

It does not use retrieve itself
It delegates to specialized agents
It may call both if needed

"""
Orchestrator Agent handler for AgentCore Runtime deployment.

Uses Strands Agent with HR/IT agents as tools - the model decides routing.

Requirements: 3.1, 3.2, 3.3, 3.4, 3.5
"""

import os
import logging
import asyncio
from typing import Any

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Configuration
AWS_REGION = os.getenv("AWS_REGION", "eu-central-1")
HR_AGENT_URL = os.getenv("HR_AGENT_URL", "")
IT_AGENT_URL = os.getenv("IT_AGENT_URL", "")

# Lazy initialization
_orchestrator_agent = None


async def _call_a2a(url: str, query: str) -> str:
    """Internal A2A call."""
    from a2a.client import A2AClient

    async with A2AClient(url) as client:
        response = await client.send_message(query)
        if hasattr(response, 'message') and response.message:
            for part in response.message.parts:
                if hasattr(part, 'text'):
                    return part.text
        return str(response)


def ask_hr_agent(query: str) -> str:
    """
    Ask the specialized HR agent.

    Use this tool for questions about:
    - HR policies, leave, payroll
    - Recruitment, hiring, contracts
    - Training, performance reviews
    - Benefits, insurance, retirement
    - Remote work, absences
    """
    if not HR_AGENT_URL:
        return "Erreur: Agent RH non configuré"

    try:
        return asyncio.run(_call_a2a(HR_AGENT_URL, query))
    except Exception as e:
        logger.error(f"HR agent error: {e}")
        return f"Erreur agent RH: {str(e)}"


def ask_it_agent(query: str) -> str:
    """
    Ask the specialized IT agent.

    Use this tool for questions about:
    - Computers, software, support
    - Network, Wi‑Fi, VPN, internet
    - Passwords, accounts, access
    - Security, antivirus
    - Email, Teams, apps
    """
    if not IT_AGENT_URL:
        return "Erreur: Agent IT non configuré"

    try:
        return asyncio.run(_call_a2a(IT_AGENT_URL, query))
    except Exception as e:
        logger.error(f"IT agent error: {e}")
        return f"Erreur agent IT: {str(e)}"


ORCHESTRATOR_SYSTEM_PROMPT = """You are an orchestrator assistant for employees.

You have access to two specialized agents:
- HR Agent: for all human resources questions (leave, payroll, contracts, training, etc.)
- IT Agent: for all IT-related questions (software, hardware, technical support, etc.)

Analyze each question and use the appropriate agent(s) to answer.
If a question spans both domains, consult both agents.

After receiving the responses, synthesize a clear and complete final answer.
"""


def get_orchestrator_agent():
    """Get or create the orchestrator agent with HR/IT tools."""
    global _orchestrator_agent
    if _orchestrator_agent is None:
        from strands import Agent

        _orchestrator_agent = Agent(
            tools=[ask_hr_agent, ask_it_agent],
            system_prompt=ORCHESTRATOR_SYSTEM_PROMPT
        )
        logger.info("Orchestrator agent initialized with HR/IT tools")
    return _orchestrator_agent


def handle_request(prompt) -> str:
    """Handle orchestrator requests."""
    try:
        prompt_str = str(prompt)
        agent = get_orchestrator_agent()
        response = agent(prompt_str)
        return response.message
    except Exception as e:
        logger.error(f"Orchestration error: {e}")
        return f"Erreur: {str(e)}"


# For AgentCore Runtime
try:
    from bedrock_agentcore.runtime import BedrockAgentCoreApp
    app = BedrockAgentCoreApp()
    logger.info("Orchestrator BedrockAgentCoreApp initialized")


    @app.entrypoint
    def handler(prompt: str) -> str:
        return handle_request(prompt)
except ImportError as e:
    logger.warning(f"bedrock_agentcore.runtime not available: {e}")
    app = None

Why implement HR/IT calls as tools?

Because it makes routing model-driven instead of hard-coded.

You’re giving the orchestrator:

a system prompt describing the domains
tool docstrings that describe when to use them
a stable interface (ask_hr_agent(query) -> str)

The LLM chooses the right tool(s), and you keep your Python logic minimal.

5 — A2A call parsing

A2A responses often come as structured messages with parts.
The parsing strategy is resilient:

if hasattr(response, 'message') and response.message:
    for part in response.message.parts:
        if hasattr(part, 'text'):
            return part.text
return str(response)

Why this matters:

You don’t assume a single “text blob” response
You gracefully fallback to str(response)

6 — Lazy initialization (production detail that matters)

All three handlers use lazy init (_agent = None).

Why it’s important in AgentCore Runtime:

cold start cost is paid once per container
subsequent requests reuse the same agent instance
lower latency and less overhead

This is the kind of detail that separates a demo from something you can run for real users.

7 — How routing actually happens

You don’t have if "vpn" in query: ....

Instead:

The orchestrator receives the question
It decides which tool(s) to call based on system prompt + tool descriptions
It synthesizes a final answer

Example behaviors:

HR-only question → calls ask_hr_agent
IT-only question → calls ask_it_agent
Mixed question → calls both, then merges

8 — Failure modes and debugging

Your code already includes the essentials:

INFO logging
explicit “not configured” messages
tool-level error handling

Common issues:

Missing URL

If HR_AGENT_URL is empty:

ask_hr_agent returns Error: HR agent not configured

Network/A2A issues

If A2A fails:

error is logged
tool returns Error HR agent: ... / Error IT agent: ...

The orchestrator can still produce a partial answer if only one agent fails.

9 — Practical hardening ideas (optional)

These keep the same architecture, but improve resilience:

Timeouts & retries for A2A calls (network I/O).
Avoid asyncio.run() if you ever run inside an existing event loop.
Return structured tool outputs (citations, metadata) if you need auditability later.

Why this architecture scales

Adding a new domain agent (Finance / Legal / Security) is just repetition of the same pattern:

1) new RAG agent handler with retrieve + domain prompt + KNOWLEDGE_BASE_ID

2) new orchestrator tool ask_finance_agent calling A2A

3) add tool to orchestrator’s tools=[...]

No refactor required.

Final thoughts

If you already know how to build RAG (or deterministic tools), the next step is orchestration.

This pattern gives you:

domain isolation
deployable units (AgentCore Runtime)
model-driven routing (tools)
a clean evolution path

It’s basically microservices:

small, focused services with a clear interface — except the services can reason.

RAG Works — Until You Hit the Long Tail

Meidi Airouche — Sun, 11 Jan 2026 23:23:12 +0000

Why Training Knowledge Into Weights Is the Next Step Beyond RAG

If you use ChatGPT or similar large language models on a daily basis, you have probably developed a certain level of trust in them. They are articulate, fast, and often impressively capable. Many engineers already rely on them for coding assistance, documentation, or architectural brainstorming.

And yet, sooner or later, you hit a wall.

You ask a question that actually matters in your day-to-day work — something internal, recent, or highly specific — and the model suddenly becomes vague, incorrect, or confidently wrong. This is not a prompting issue. It is a structural limitation.

This article explores why that happens, why current solutions only partially address the problem, and why training knowledge directly into model weights is likely to be a key part of the future.

The real problem is not the knowledge cutoff

The knowledge cutoff is the most visible limitation of LLMs. Models are trained on data up to a certain point in time, and anything that happens afterward simply does not exist for them.

In practice, however, this is rarely the most painful issue. Web search, APIs, and tools can often mitigate it.

The deeper problem is the long tail of knowledge.

In real production environments, the most valuable questions are rarely about well-documented public facts. They are about internal systems, undocumented decisions, proprietary processes, and domain-specific conventions that exist nowhere on the public internet.

Examples include:

Why did this service start failing after a seemingly unrelated change?
Has this architectural trade-off already been discussed internally?
How does our company interpret a specific regulatory constraint?

These questions live in the long tail. And that is exactly where large foundation models perform the worst.

Three ways to give knowledge to a language model

If we strip away tooling details, there are only three fundamental ways to make a language model “know” something new.

The first is to place the knowledge directly into the prompt.

The second is to retrieve relevant information at inference time.

The third is to train the knowledge into the model itself.

Most systems today rely almost entirely on the first two.

Full context: simple, expensive, and fragile

The most naive solution is to put everything into the prompt.

prompt = f"""
You are an assistant with access to our internal documentation.

{internal_docs}

Question:
Why does service X fail under load?
"""

For small documents, this works. It is easy to implement and requires no additional infrastructure.

However, as context grows, several issues appear at once. Token costs increase linearly. Latency increases significantly. Most importantly, reasoning quality degrades as more weakly relevant information is added.

This is not an implementation issue. It is a consequence of how transformer models work.

The transformer bottleneck and context degradation

Transformers rely on self-attention, where every token attends to every other token. This leads to quadratic complexity with respect to input length.

Even though modern models can technically accept very large context windows, there is an important difference between:

not crashing with long input, and
reasoning well over long input.

Empirically, performance degrades as context grows, even when the relevant information remains the same. The model continues to produce fluent text, but its ability to connect the right pieces of information deteriorates. This phenomenon is often referred to as context rot.

As a result, simply increasing the context window is not a viable long-term solution.

RAG: external memory via embeddings

To avoid pushing everything into the prompt, the industry converged on Retrieval-Augmented Generation (RAG).

The idea is to store documents externally, retrieve the most relevant ones using embeddings, and inject only those into the prompt.

A minimal Python example looks like this:

from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings

embeddings = OpenAIEmbeddings()
vector_store = Chroma.from_documents(
    documents=docs,
    embedding=embeddings
)

results = vector_store.similarity_search(
    query="Why does the CI pipeline fail?",
    k=5
)

RAG is popular because it is flexible, relatively cheap, and easy to deploy. Today, it is the default solution for adding memory to LLM-based systems.

Why RAG is fundamentally limited

RAG retrieves information, but retrieval is not reasoning. Selecting a few relevant chunks does not guarantee that the model can correctly combine them, especially when the answer depends on implicit relationships or multi-step reasoning across documents.

Embeddings also encode a single global notion of similarity. They are not adaptive to local domain semantics. In practice, documents that should never be confused often end up close together in vector space.

Finally, embeddings are not inherently secure. With enough effort, large portions of the original text can be reconstructed from them. This makes vector databases unsuitable as a privacy-preserving abstraction.

These limitations suggest that RAG is powerful, but incomplete.

The naive fine-tuning trap

At this point, it is tempting to fine-tune the model directly on internal data.

In practice, naive fine-tuning almost always fails. Training directly on small, specialized datasets causes the model to overfit, lose general reasoning abilities, and forget previously learned knowledge. This phenomenon is known as catastrophic forgetting.

The result is a model that memorizes patterns but loses its ability to generalize and reason beyond the training data.

Synthetic data as the missing link

The key insight that changes the picture is synthetic data generation.

Instead of training on raw documents, we generate a large and diverse set of tasks that describe the knowledge contained in those documents. These can include question–answer pairs, explanations, paraphrases, and counterfactuals.

A simplified example in Python:

def generate_qa(doc):
    return {
        "instruction": f"Explain the key idea behind: {doc.title}",
        "response": doc.summary
    }

synthetic_dataset = [generate_qa(doc) for doc in internal_docs]

This approach teaches the domain, not the surface text. Surprisingly, it works even when the original dataset is small, as long as the synthetic data is sufficiently diverse.

Training into weights without destroying the model

To avoid catastrophic forgetting, modern systems rely on parameter-efficient fine-tuning. Instead of updating all weights, only a small subset is modified.

One common technique is LoRA (Low-Rank Adaptation):

from peft import LoraConfig

lora_config = LoraConfig(
    r=8,
    lora_alpha=16,
    target_modules=["q_proj", "v_proj"]
)

The key idea is to make small, localized changes that steer the model without overwriting its existing knowledge.

Other approaches, such as prefix tuning or memory layers, follow the same principle with different trade-offs.

A hybrid future: context, retrieval, and weights

None of these techniques replaces the others entirely. The most effective systems combine all three.

Context is useful for immediate instructions. Retrieval is essential for fresh or frequently changing data. Training into weights provides deep, coherent domain understanding that retrieval alone cannot achieve.

The central design question going forward is not whether to train models on private knowledge, but what knowledge deserves to live in weights versus being handled at inference time.

Conclusion

RAG is a pragmatic and powerful solution, and it will remain part of the LLM ecosystem. However, it is fundamentally limited when it comes to deep reasoning over specialized knowledge.

As training techniques become more efficient, training knowledge into weights will no longer be a research curiosity. It will be an engineering decision.

In the long run, the most valuable LLM systems will not be defined by the base model they use, but by what they have been taught — and how carefully that teaching was done.

How Reasoning LLMs Are Challenging Orchestration

Meidi Airouche — Tue, 04 Nov 2025 20:03:35 +0000

I spent most of last year buried in LangGraph.
It felt like engineering telepathy — drawing thoughts as state machines, chaining prompts into something almost alive.
Until one night, at 2 AM, I was staring at a 15-node graph just to summarize a document.
Every retry, every validation, every branch was on me.
That’s when it clicked: I was orchestrating cognition that the model could have handled itself.

So I did what most of us do when we’re tired of over-engineering: I tore it down and rebuilt it — this time around a reasoning-native model.

The usual way: Manual Orchestration with LangGraph

LangGraph made sense when models couldn’t plan or reason.

Here’s a minimal example of what my early pipelines looked like:

from langgraph.graph import StateGraph
from langchain_openai import ChatOpenAI
from langchain.schema import SystemMessage, HumanMessage

llm = ChatOpenAI(model="gpt-4-turbo")

def summarize(state):
    result = llm([
        SystemMessage("Summarize briefly and clearly."),
        HumanMessage(state["doc"])
    ])
    return {"summary": result.content}

def verify(state):
    summary = state["summary"]
    result = llm([
        SystemMessage("Return OK if factual, else ERROR."),
        HumanMessage(summary)
    ])
    return {"verified": result.content.strip() == "OK"}

graph = StateGraph()
graph.add_node("summarize", summarize)
graph.add_node("verify", verify)
graph.add_edge("summarize", "verify")
graph.set_entry_point("summarize")

result = graph.run({"doc": open("manual.txt").read()})
print(result)

What we can state :

It’s explicit and predictable — but verbose.
Every new condition means another node.
Every correction means editing a graph.
You become the conductor instead of letting the model compose the music.

The New Approach: Reasoning Models + MCP Tools

When I switched to Claude 4.5 (and later GPT-5), I stopped describing steps and started describing goals.

The model could plan, call tools, and validate its own results through MCP.

from mcp import MCPClient, tool

@tool
def search(query: str) -> str:
    """Search internal docs."""
    return f"Search results for {query}"

@tool
def summarize(text: str, max_words: int = 200) -> str:
    """Summarize text."""
    return text[:max_words] + "..."

@tool
def validate(summary: str) -> str:
    """Return 'OK' if factual."""
    return "OK"

client = MCPClient(model="claude-4.5", tools=[search, summarize, validate])

prompt = """
You are a reasoning agent.
Goal: Summarize and fact-check 'LangGraph framework'.
1. Search relevant data.
2. Summarize it.
3. Validate results; retry if not OK.
Return only the final validated summary.
"""

print(client.run(prompt))

The trace looked like this:

[Plan] Step 1 → search("LangGraph framework")
[Plan] Step 2 → summarize(results)
[Plan] Step 3 → validate(summary)
[Reflection] Validation OK → returning summary

That’s one reasoning session instead of three separate LLM calls:

Latency dropped from 2.3s to ~1.1s.
Tokens halved.
And my orchestration code disappeared.

Reasoning Traces as Your New Logs

Reasoning-native models emit structured traces — JSON instead of plain text logs.

{
  "plan": ["search", "summarize", "validate"],
  "confidence": 0.94,
  "tokens_used": 540,
  "duration_ms": 1180,
  "outcome": "validated_summary"
}

I store these in SQLite and diff them like code.

When a model’s plan drifts or confidence drops, my CI flags it.

def test_reasoning_behavior(client, baseline_trace):
    result = client.run("Summarize and validate: LangGraph")
    trace = result.trace
    assert trace.confidence >= baseline_trace["confidence"]
    assert len(trace.plan) == len(baseline_trace["plan"])

It’s not deterministic — it’s bounded variance, and that’s testable.

Observing Cognition in Production

Each reasoning session becomes a span in OpenTelemetry.

I track average token usage and confidence in Grafana:

SELECT avg(tokens_used), avg(confidence)
FROM traces
WHERE created_at > NOW() - INTERVAL '1 day';

When confidence dips, we investigate prompts — not servers.

Monitoring cognition feels weird at first, but it’s the only way to scale non-deterministic intelligence safely.

What You Trade (and Gain)

Aspect	LangGraph	Reasoning + MCP
Control	Explicit nodes	Emergent planning
Debugging	Stack traces	Cognitive traces
Determinism	High	Bounded
Adaptability	Low	High
Maintenance	Tedious	Lightweight
Creativity	Predictable	Expansive

LangGraph still shines where compliance or determinism rule.

But when your system needs flexibility and learning-like behavior, reasoning-native wins.

Lessons (and Mistakes) from the Field

Reasoning drift — identical input, different answers. Use baseline scoring.
Token bloat — models love to overthink. Set session budgets.
Trace chaos — vendor formats differ. Normalize JSON.
Compliance audits — sign and retain traces.
Team culture — teach prompt design as system design.

When AWS Gets It Right with AgentCore

The most interesting thing about AWS AgentCore isn’t that it’s another managed service — it’s that its design choices perfectly align with where reasoning-native orchestration is headed.

AgentCore treats reasoning as a first-class runtime concern, not a framework problem.

You don’t define workflows. You define intent and tools, and the runtime handles retries, observability, and tool invocation policy for you — all inside a managed cognitive environment.

from strands import Agent, tool
from strands.models import BedrockModel
from strands_tools import http_request

@tool
def summarize(text: str, max_words: int = 200) -> str:
    return text[:max_words] + "…"

@tool
def validate(summary: str) -> str:
    return "OK" if "important" in summary else "ERROR"

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-20250514-v1:0",
    region_name="eu-west-3",
    client_args={"api_key": "*********"},
    params={"temperature": 0.3}
)

agent = Agent(
    model=model,
    tools=[summarize, validate, http_request]
)

prompt = """
Summarize the key points of the LangGraph framework and then validate the summary.
"""

response = agent(prompt)
print(response)

That’s it — no DAGs, no state machines, no manual recovery logic.
AgentCore hosts your agent, tracks its reasoning trace, and automatically replays or retries failed tool calls.

In practice, it embeds orchestration inside reasoning, instead of wrapping reasoning inside orchestration.
That inversion is exactly what this whole post argues for.

The fact that AWS — arguably the most conservative player in cloud architecture — built AgentCore this way tells me this isn’t a niche trend.
It’s the industry quietly acknowledging that reasoning is the new orchestration layer.

Finally

LangGraph taught me structure.
It forced me to make my thinking explicit — every state, every branch, every validation. But it also showed me the limits of explicitness: when you draw too much of the reasoning, the system stops thinking for itself.

Reasoning models flipped that.
They brought back uncertainty — and with it, adaptability.Instead of engineering every step, I started describing outcomes and letting the model figure out how to get there. That shift didn’t remove orchestration; it changed what orchestration means.

And now, when I look at frameworks like AWS AgentCore, I see the industry catching up. They didn’t rebuild the LangGraph paradigm. They embedded it inside the runtime — where reasoning, recovery, and policy coexist naturally. It’s orchestration without the scaffolding, cognition without the chaos.

So here’s what I’ve learned: the future of orchestration isn’t about bigger graphs or smarter DAGs. It’s about trusting the reasoning layer to do what the graph used to. And whether that reasoning runs in your own loop, or inside a managed runtime like AgentCore, the principle stays the same:

The system no longer needs to be told how to think,
it just needs to be given the space to reason.

Cloud Is No Longer a Specialty — It’s the Operating System of Modern Engineering

Meidi Airouche — Fri, 05 Sep 2025 12:43:30 +0000

Walk into almost any engineering org today and you’ll notice the same pattern: the places where code runs, where data lands, where models are trained and served, and where controls are enforced have mostly moved to the cloud. That move didn’t just change our tooling; it rewired how teams work, what “good” looks like, and which skills actually move the needle. This isn’t hype. It’s budget, platform design, and regulation all pointing the same way. Analyst forecasts put 2025 public-cloud end-user spend around $723B and we're on track to reach it.

Why this became inevitable

Economics changed first. Elastic infrastructure beat capacity planning spreadsheets. Managed services outpaced hand-rolled clusters. And once finance teams could see clear unit costs—per request, per job, per model hour—the conversation shifted from “can we?” to “is it worth it?” Cloud stopped being a cost center and became a lever.

Platformization followed. To keep speed and governance from fighting, many orgs built internal platforms and developer portals: golden paths, paved roads, templates, and policy baked into CI/CD. This is the heart of platform engineering—product-managing the internal experience so teams can move fast without leaving a compliance crater. The cloud-native community has documented this shift for years, and adoption keeps climbing in larger orgs because complexity demands it.

Regulation sealed it. In Europe especially, rules now expect traceability, resilience, and portability as a baseline—not a sticker you add later. The EU AI Act applies obligations to general-purpose models starting August 2, 2025; DORA has applied across financial services since January 17, 2025; and the Data Act becomes applicable September 12, 2025, bringing switching and portability into the mainstream. Meeting those obligations is dramatically easier when identity, logging, lineage, and deployment are first-class cloud capabilities—auditable by design.

Sovereignty raised the bar, not the walls. Europe isn’t rolling back cloud; it’s demanding more control. That’s why you see sovereign offerings—EU-operated, EU-resident stacks with stricter controls. For architects, that means designing for residency, autonomy, and reversibility—not retreating to the basement.

What actually changes in the roles

Software engineers stop treating “infrastructure” as someone else’s problem. The platform is an API surface: you ship to it, observe through it, and live with the reliability and cost that follow. Knowing how traffic enters, how secrets are granted, how rollouts can be reversed, and how your service shows up on the bill is no longer “nice to have”—it’s part of building a product.

Data engineers and analytics folks inherit “data as a product.” Contracts, SLOs for freshness, lineage, and lifecycle rules move from slideware to everyday work. Elastic compute is a superpower until you lose track of it; cost-aware designs become a craft. Portability and exit duties under the Data Act make schema choices and platform coupling strategic, not just technical.

AI/ML engineers are broadening from model concerns to system concerns. As training and inference live deeper in production, the work naturally spans data contracts, storage classes and vector indexes, event-driven orchestration, GPU/SKU choices, and access-control patterns. In Europe, the AI Act doesn’t point fingers; it codifies practices many teams already value—reproducibility, evaluation, and risk management. In practical terms, that means keeping auditable logs, dataset/feature lineage, and evaluation reports alongside model artifacts, so accuracy, latency, cost, and risk can be governed together.

Security engineers become identity and supply-chain specialists. The shared-responsibility line is clear: providers secure the substrate; you secure identities, configurations, data paths, and the software supply chain. In practice, this means policy-as-code, strong KMS habits, least privilege, and proofs (attestations, SBOMs) embedded in pipelines—because auditors now read YAML. DORA made this non-optional for finance; everyone else is following.

Architects shift from diagram authors to platform product managers. Your job is curating guardrails that make good choices the easiest ones: standard templates, default policies, sovereign patterns when required, and a small number of blessed paths that cover most work. You measure adoption, lead time, and incident burn, not just conformance.

The new baseline

Nobody needs to be an expert in every managed service. You do need to be conversant in the handful of concepts that show up in every design review:

How the app is packaged and rolled out; how it rolls back.
Where it lives on the network, and what “private by default” means here.
Which identities it uses, which keys guard data, and who can rotate them.
What it emits (logs/metrics/traces), which SLOs it’s held to, and how alerts tie to action.
How it will be audited: data lineage, deployment history, model evaluations if there’s AI in the loop.
How the costs map to units the business cares about.

These are the muscles that translate architecture to outcomes. They make you portable across providers, because the patterns rhyme even when service names don’t. If you’ve ever switched from one framework to another, you know the feeling: a week of vocabulary, then you’re home.

Market direction: more cloud, more accountability

Spending is still rising because the work moved there: applications, analytics, and AI. That ~$723B 2025 forecast reflects not just growth but consolidation of strategy—organizations are building on a smaller set of managed capabilities and demanding better economics from them. Community surveys show cloud-first and cloud-native practices are no longer outliers; they’re the default in many environments. The cultural follow-through is visible: FinOps disciplines to keep the bill honest, and platform-engineering to keep speed and safety from arguing.

At the same time, Europe’s regulatory cadence and sovereignty projects point to a world where cloud proficiency includes governance proficiency: knowing how to prove where data lives, who touched it, how a model was evaluated, and how fast you can exit or fail over. That’s not a step backward—it’s the maturity curve technologies go through when they become infrastructure.

Where this doesn’t fully apply (yet)

Reality is messy. Plenty of orgs are mid-migration or still discovering their platform identity. Some workloads—industrial/OT, defense, certain HPC or ultra-low-latency use cases, deeply embedded stacks—will stay hybrid or on-prem for good reasons. There’s also a visible current of “repatriation” and cost-driven hybridization. None of that contradicts the thesis. It raises the bar on discipline: good identity, IaC, policy-as-code, and supply-chain hygiene travel well between clouds, regions, and data centers. Sovereign setups add necessary constraints; they don’t erase the need for cloud-literate engineering.

What to do with this

Own the path from code to value. If you’re a software engineer, be able to explain your rollout, identity, SLO, and unit cost without phoning a friend. If you’re in data or ML, treat datasets and models like products—with owners, contracts, and budgets. If you’re in security, bring policy-as-code and supply-chain proofs into development early. If you’re an architect, act like a platform PM: choose a few defaults, measure adoption, and invest in governance that developers can feel—not paperwork they ignore.

Cloud isn’t a badge anymore. It’s the operating system of the modern engineering org. Learn to speak it fluently and you won't just keep up, you'll lead.

Conclusion: where seniority now comes from

As AI weaves itself into every product, seniority isn’t measured by stack trivia or how many models you can fine-tune. It’s measured by your ability to connect the pieces—platform, data, security, compliance—and to set sane defaults so teams can ship safely at scale. That redefinition of roles is the value add: the software engineer who speaks IAM and SLOs as naturally as APIs; the data/ML engineer who treats datasets and models as governed products; the security engineer who codes policy and supply-chain proofs; the architect who product-manages the platform.

Call it end-to-end ownership with judgment. When you can explain where the data lives, how the system fails, what it costs, and why a decision is acceptable under the AI Act or DORA, you’re not just keeping up—you’re raising the bar. That’s the kind of engineering AI rewards—not more heroics, but better guardrails, clearer trade-offs, faster learning loops. That’s what senior looks like now.

Sources :

ciodive.com
tag-app-delivery.cncf.io
info.getport.io
digital-strategy.ec.europa.eu
wsj.com
esma.europa.eu

How to Create a Web Search AI Agent with AWS Bedrock

Meidi Airouche — Fri, 25 Jul 2025 16:32:50 +0000

Amazon Bedrock Agents let you build autonomous agents powered by LLMs that can reason, act, and interact with APIs, data sources, and users. Based on the ReAct paradigm, they break down tasks, perform API calls, and integrate with knowledge bases—all without needing to manage underlying infra.

By combining Bedrock Agents with web search APIs, you can extend your chatbot with real-time access to internet content. This unlocks:

Live web queries in-chat – Keep users in the conversation while retrieving up-to-date info.
Context-aware actions – Use CoT prompting to decide when to call APIs or search the web.
Smarter responses – Blend internal knowledge and external data for more relevant replies.
Fast setup – Add dynamic search with minimal config, and deploy via CloudFormation or CDK.

This integration gives your AI apps richer, more accurate responses while keeping UX simple. Ideal for building more helpful, responsive chatbots—without reinventing the wheel.

Global Solution

An Amazon Bedrock agent acts as the central orchestrator between the user and external web search APIs. It manages the conversation flow, handles optional memory, and the web search.

Search logic is offloaded to an AWS Lambda function, which is responsible for calling a third-party search provider and formatting the results.

We rely on Serper API for the web search. It provides up-to-date, real-time information

API keys for these services are securely stored and accessed via AWS Secrets Manager.

Amazon Bedrock foundation models (Claude 3 Haiku for celerity) handle natural language generation, crafting final answers based on the retrieved content.

Prerequisites

An AWS account
AWS CLI configured with your AWS account

Configure the Serper API

Serper API offers a web search service that integrates easily with Amazon Bedrock agents via RESTful calls from a Lambda function. It supports multiple search engines like Google, Bing, and Yahoo, and gives control over query parameters and result types—such as organic results, featured snippets, images, or videos.

This makes Serper a solid choice when you need access to specific search engine features or want results aggregated from multiple sources.

For this example, we’re using Serper API exclusively, with API keys securely stored in AWS Secrets Manager and accessed from the Lambda function during execution. You can use this AWS CLI command to create the secret :

aws secretsmanager create-secret \
--name SERPER_API_KEY \
--description "The API secret key for Serper." \
--secret-string "<SERPER_API_KEY>"

Now that the API is configured, we can start building the web search Amazon Bedrock agent.

Web search AWS Bedrock agent using the console

Create a web search agent

To create a web search agent using the console, complete the following steps:

1) On the Amazon Bedrock console, choose Agents in the navigation pane.
2) Choose Create agent.
3) Enter a name for the agent (such as websearch-agt) and an a description, then choose Create.

We are now in the new agent builder screen, where we can access and edit the configuration of an agent.

4) For Agent resource role, leave the default Create and use a new service role
5) For the model, we choose Anthropic and Claude Haiku 3 (if not available, you can claim access in the model access menu of Bedrock)

6) Here are the instructions for the agent. You can enhance it if you feel comfortable enought to do so :

You are an agent that can help users do research and finding up-to-date information. For up-to-date information always uses web search. Web search uses Google Search - this is great for looking up up-to-date information and current events.

7) Choose Add button in Action groups. Those groups enable us to trigger the lambda function when needed.
8) For Enter action group name, enter action-group-websearch.
9) For Action group type, select Define with function details so you can specify a function and its parameters as JSON instead of providing an Open API schema.
10) For Action group invocation, set up what the agent does after this action group is identified by the model. Because we want to call the web search APIs, select Quick create a new Lambda function.
With this option, Amazon Bedrock creates a basic Lambda function for your agent that you can later modify on the Lambda console for the use case of calling the web search API. The agent will predict the function and function parameters needed to fulfil its goal and pass the parameters to the Lambda function.

11) Now, configure the Serper API Google search function for the action group with name google-search and the description of your choice.
12) Add a query parameter of type String for the search query.
13) Choose Create to complete the action group creation.

14) Choose Save to save the agent configuration

Lambda function configuration & code

1) On the Lambda console, look for the function with the name action_group_websearch-<code>.
2) Edit this function and replace the existing code with this one :

import json
import logging
import os
import http.client
import boto3

# Logging setup
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Environment config
AWS_REGION = os.environ.get("AWS_REGION", "us-east-1") # change with your region
ACTION_GROUP_NAME = os.environ.get("ACTION_GROUP", "action-group-websearch")
SERPER_API_KEY = os.environ.get("SERPER_API_KEY")

# Fallback to Secrets Manager if key not in env
if not SERPER_API_KEY:
    secrets = boto3.client("secretsmanager", region_name=AWS_REGION)
    SERPER_API_KEY = secrets.get_secret_value(SecretId="SERPER_API_KEY")["SecretString"]

# Extracts query parameters
def extract_search_params(event):
    if event["actionGroup"] != ACTION_GROUP_NAME:
        logger.error("Invalid action group")
        return None, None

    params = {p["name"]: p["value"] for p in event.get("parameters", [])}
    return params.get("search_query"), params.get("target_website", "")

# Calls Serper API
def google_search(query, target_site=""):
    if target_site:
        query += f" site:{target_site}"

    payload = json.dumps({"q": query})
    headers = {"X-API-KEY": SERPER_API_KEY, "Content-Type": "application/json"}

    conn = http.client.HTTPSConnection("google.serper.dev")
    conn.request("POST", "/news", payload, headers)
    res = conn.getresponse()
    return res.read().decode("utf-8")

# Lambda entry point
def lambda_handler(event, _):
    query, site = extract_search_params(event)
    if not query:
        return {"error": "Missing query"}

    results = google_search(query, site)

    return {
        "response": {
            "actionGroup": event["actionGroup"],
            "function": event["function"],
            "functionResponse": {
                "responseBody": {
                    "TEXT": {
                        "body": f"Here are the top search results for '{query}': {results}"
                    }
                }
            },
        },
        "messageVersion": event["messageVersion"],
    }

3) Click on Deploy to deploy the code.

By default, the Lambda's default resource policy already has the right premissions to be called from the agent since we created it from the agent action group.
But since we use Secret Manager in the lambda, we need to add this permission to the lambda's role :

{
  "Action": "secretsmanager:GetSecretValue",
  "Resource": [
    "arn:aws:secretsmanager:<REGION>:<ACCOUNT_ID>:secret:SERPER_API_KEY*"
  ],
  "Effect": "Allow",
  "Sid": "GetSecretsManagerSecret"
}

Don't forget to replace REGION and ACCOUNT_ID with yours.

Test the agent

You’re now ready to test the agent.

1) On the Amazon Bedrock console, on the websearch-agt details page, choose Test.
2) Choose Prepare to load the agent.
3) Ask a question to your agent. Example : "Who won the latest Champions League ?" (yes, I'm french ;D)
4) You should now be able to recieve the answer from your agent. You can now click on Show trace to understand the decision and sources of the agent.

Final thougts

Here we are : we are now able to do a web search in our agentic architectures. This is a powerful and an anovoidable feature that you will obviously need to have.

AWS Kiro: Another AI-Powered IDE Challenger or a Game Changer?

Meidi Airouche — Tue, 15 Jul 2025 14:15:37 +0000

AWS has released Kiro, a new AI-powered IDE with built-in agentic workflows, specification generation, and cloud integration. But how does it compare to established tools like GitHub Copilot, Google Gemini Code Assist, or Cursor?

As AI coding assistants evolve from simple autocomplete tools into fully agentic systems, a new category of IDEs is emerging — ones that help you plan, structure, test, and ship code end-to-end.

This article provides a deep, technical comparison between AWS Kiro, GitHub Copilot Agent Mode, Google Gemini Code Assist, and Cursor, focusing on their features, workflows, and usage in real-world developer contexts.

What is AWS Kiro?

Kiro is an AI-native IDE developed by AWS, built as a customized fork of VS Code (based on Code-OSS). It focuses on specification-driven development and provides out-of-the-box support for:

Agent-assisted task decomposition,
Automatic generation of technical specifications (requirements.md, design.md, etc.),
Integration of infrastructure as code (AWS CDK, SAM, Terraform),
Built-in hooks for tests, documentation, and security checks.

Kiro works locally and integrates with AWS services (Bedrock, IAM...), but it can also be used in other environments (e.g., with GitHub or local repos).

Feature Comparison

Feature Category	Kiro (AWS)	Copilot Agent (GitHub)	Gemini Code Assist (Google)	Cursor (Anysphere)
Spec Generation	✅ Automatic `requirements.md`, `design.md`, `tasks.md`	❌ No automatic spec generation	❌ Manual via chat	⚠️ Prompt-based only
Code Agent	✅ Plans and implements across multiple files	✅ Handles multi-file context	✅ Assisted actions, test generation	✅ Contextual refactoring and commands
Pre-Commit Hooks	✅ Built-in test, lint, doc, security checks	❌ Manual setup or external tooling	❌ Reactive suggestions only	⚠️ Partial automation
Infrastructure Gen	✅ Supports AWS CDK, SAM, Terraform	⚠️ Requires separate configuration	⚠️ No infra scaffolding features	❌ Not infra-oriented
IDE Integration	✅ Native VS Code fork	✅ Official VS Code extension	✅ VS Code, IntelliJ, Android Studio	✅ Custom VS Code fork
Cloud Alignment	🌩️ AWS-native (IAM, Bedrock)	☁️ GitHub + Azure	☁️ Google Cloud oriented	☁️ Cloud-agnostic
Steering/Rules	✅ `.kiro/steering` for project coding norms	⚠️ Prompt-defined preferences only	⚠️ No native steering	⚠️ Custom plugins or config
MCP Support	✅ Yes	❌ No	✅ Yes	❌ No

Workflow differences

A key difference between these IDEs is how much structure they impose or support.

Kiro:

You define a goal or description.
Kiro generates structured specs (requirements, design).
It decomposes tasks and assigns them to agents.
On save or commit, it can run tests, linting, documentation generation, and security scanning.
Optionally scaffolds infrastructure code with IaC tools.

GitHub Copilot Agent Mode:

You prompt it in chat or command mode.
It generates code and can make edits across multiple files.
It’s highly reactive but requires manual steering.

Gemini Code Assist:

Offers code suggestions, test generation, and chat interface.
CLI (Gemini CLI) supports shell commands and task automation.
It’s focused on augmenting the developer rather than enforcing structure.

Cursor:

Focused on large-scale code refactoring, search, and editing.
Excellent for legacy or unfamiliar codebases.
Less opinionated — leaves decisions to the developer.

Pricing

Plan	Kiro	Copilot Pro	Gemini Free	Cursor
Free	50 agent tasks/month	❌	✅ ~180k completions	❌
Pro	\$19/month (1k tasks)	\$10/month	–	\$20–\$30/month
Pro+	\$39/month (3k tasks)	Enterprise pricing	Enterprise plans	Enterprise pricing

Do You Need to Pay for AWS Bedrock Separately?

No, unless you configure Kiro to use your own Bedrock models:

✅ Default setup (e.g. Claude Sonnet) → included in Kiro’s pricing
⚠️ Custom models via .kiro/agents.yaml → billed separately by AWS
⚠️ External Bedrock calls via CLI/plugins → also billed by AWS

👉 For most users, there's no extra Bedrock cost unless you opt into advanced configurations. Beware with this.

When to Use Which Tool

Use Case	Best Fit	Reasoning
Structured app development	Kiro	Provides specs, infra scaffolding, QA hooks
Rapid prototyping / GitHub-native	Copilot Agent	Integrated in GitHub and VS Code, great for agile teams
Personal or lightweight usage	Gemini	Free, minimal setup, multiplatform
Legacy code or refactoring	Cursor	Advanced context navigation and editing capabilities

Pros and Cons of Kiro

Pros :

Structured dev flow (design → tasks → code → deploy)
Agentic hooks (test, lint, scan on save/commit)
Infrastructure-as-code support
Ideal for production environments

Cons :

Currently in preview; evolving rapidly
Requires AWS Builder ID / IAM role for full integration
Interaction quotas tied to pricing tiers

How to Use Kiro Effectively ?

Kiro introduces a workflow that differs from traditional IDEs. To get the most out of it, it's worth adapting your habits slightly to embrace its agentic, spec-driven model.

Installation & Setup

Kiro is currently in public preview and can be installed locally:

brew install aws/tap/kiro  # macOS
kiro login                 # authenticate via AWS Builder ID, IAM, or GitHub

You can also download platform-specific installers from kiro.dev.

For the authentication, Kiro supports:

AWS Builder ID
IAM roles
GitHub or Google accounts

If you're deploying or using Bedrock models (e.g., Claude Sonnet), you’ll need AWS credentials configured locally via aws configure.

Project Bootstrapping

You can start from scratch or use an existing codebase. In either case, run:

kiro init

This command:

Sets up the .kiro/ directory (for agent config and steering rules)
Creates empty spec files (requirements.md, design.md, etc.)
Connects your repo to Kiro's agent backend

Using Agents to Build Features

With Kiro running, press Cmd+K (or via Command Palette) and describe a feature:

"Build a CRUD REST API for invoices with validation and automated tests."

Kiro will:

Generate a plan (tasks.md)
Write or scaffold relevant code across files
Propose tests, docs, and infra (if enabled)
Apply your .kiro/steering coding standards

You can refine behavior via config:

# .kiro/steering/rules.yaml
rules:
  - prefer_lib: zod
  - enforce_test_coverage: true
  - infra: terraform

Pre-Commit Quality Hooks

Kiro can automatically:

Run unit tests (npm test, pytest, etc.)
Lint your codebase
Check security rules (via integrated scans)
Regenerate documentation

By default, these hooks run on:

File save
Git commit

Configure hook behavior in .kiro/config.yaml.

Infrastructure Integration

Kiro supports scaffolding with:

AWS CDK
AWS SAM
Terraform

Example :

kiro infra add dynamodb-table --stack invoice-db

Kiro can then deploy the stack using your local AWS credentials or CloudFormation pipeline.

Continuous Agent Workflows

Kiro agents aren't just for code generation, they can:

Monitor task progress
Keep specs up to date
Detect stale or undocumented changes
Suggest updates when your code diverges from the plan

Use:

kiro sync

To refresh your spec and design files based on recent code edits.

Tips

Start every feature with a description, not just code — Kiro thrives on intent.
Use .kiro/steering to define how your team writes code.
Let agents run tests and scans early — they'll prevent issues from escalating.
Adopt it gradually — it plays nicely with existing tools, including Git, VS Code, and AWS CLI.

Final Thoughts

Kiro isn’t trying to replace Copilot — it’s targeting a different layer of software engineering. Where Copilot and Gemini are productivity tools, Kiro is a structure enforcer. It brings planning, design, QA, and infra together in a single, AI-supported loop.

For teams building long-lived, production-grade applications — especially in AWS environments — Kiro offers strong value.

That said, if your needs are exploratory, fast-paced, or centered on legacy code, tools like Copilot or Cursor may remain more flexible.

What Do You Think?

Have you tested Kiro? Planning to?

Feel free to share your thoughts in the comments — real-world feedback is essential to evaluate how tools like this actually change development workflows.

How to become a Staff Software Engineer

Meidi Airouche — Mon, 12 May 2025 07:57:14 +0000

I didn’t set out to become a Staff Engineer. It wasn’t part of some grand plan. But over time, I realized that the most important problems I could work on weren’t on my team’s backlog, and sometimes weren’t even clearly defined. What follows isn’t a formula, just a reflection of the kinds of shifts that made a difference for me and for others I’ve learned from along the way.

The Nature of Impact Changes

As a Senior Engineer, you're valued for your ability to deliver. You own features end-to-end, manage technical complexity, and often mentor others along the way. You’re fast, autonomous, and reliable.

At the Staff+ level, the work shifts from execution to enablement. Your job becomes helping others deliver more effectively across teams, across quarters, and often without directly writing the code yourself.

You might spot a flaw in a planned architecture that avoids months of rework. You might introduce a pattern or internal tool that quietly makes onboarding smoother for every new hire. You might remove a blocker between two teams who didn’t even realize they were misaligned.

In a way, your success becomes more abstract and often less visible. But its effects compound.

Scope Becomes Organizational

One clear shift is the expansion of scope. Not in terms of technical breadth for its own sake, but in the number of people and systems your decisions touch.

Instead of focusing on “how we build this feature well,” you start asking questions like:

Should this system even be built?
If we do this, how will it affect other teams six months from now?
Who’s responsible for maintaining this? Will they still be here?

At this level, you’re expected to think in systems: not just technical systems, but organizational ones. And your ability to navigate those systems starts to matter as much as your ability to write code.

At Meta, Staff Engineers are frequently brought into projects not because of their domain expertise, but because they can identify how choices made today will affect infrastructure, team autonomy, and platform stability a year from now.

Ambiguity Becomes the Default

Staff+ engineers gravitate toward poorly scoped, high-risk, politically sensitive problems, because they’re often the only ones in a position to handle them.

Sometimes it’s technical: “This legacy system is a mess and no one owns it, but we’re scaling fast and it’s now a bottleneck.”

Sometimes it’s organizational: “Two teams are solving the same problem in parallel. Their solutions don’t align. Leadership hasn’t noticed.”

These problems don’t come with tickets. They don’t even always come with permission. But solving them creates space for others to move faster, more safely, and more clearly.

At Stripe, a Staff engineer once took on standardizing observability tooling, not because it was glamorous, but because dozens of engineers were wasting time reinventing similar dashboards in different ways. No one owned the problem. She did. And in doing so, she cleared a path for dozens of teams.

You Lead Without Authority

Staff Engineers often lead projects where no one reports to them. Influence happens through clarity, credibility, and trust: not hierarchy.

That means:

Asking better questions than giving perfect answers
Offering direction without dismissing opposing views
Getting buy-in not because you’re senior, but because your logic holds

In many tech companies (Google, for example) some of the most impactful engineers are those who can walk into a messy, cross-team situation and bring calm, technical reasoning to the table. They don’t push harder. They create alignment.

This work can be frustrating. You’ll spend more time in conversations than in code. But when you do it well, entire teams move more effectively.

Technical Depth Still Matters

Being Staff doesn’t mean giving up technical skill. In fact, your credibility often hinges on it.

But instead of being deep in everything, you’re expected to be deep in something and fluent in how it connects to everything else.

You might be the person who understands caching and latency behavior better than anyone else on the platform. Or the one who can anticipate failure modes in distributed systems before they hit production. Or maybe you’ve earned trust by consistently cleaning up architectural debt in a pragmatic way.

At Netflix, Staff+ engineers are often seen jumping into highly focused technical deep dives when they matter most, during incident response, during a high-stakes redesign, or when no one else knows quite where to start. Their expertise is a scalpel, not a hammer.

Writing Is a Core Part of the Job

Staff-level engineers are expected to scale their thinking beyond themselves. That means communicating ideas in ways that last across time zones, org charts, and reorgs.

Design docs. Technical strategies. Memos. Decision records. Naming proposals. Postmortems. Lessons learned...

If you can't explain the “why” behind a decision or the trade-offs that were considered, you're not operating at Staff level yet.

You Create Leverage, Not Velocity

One of the toughest transitions is letting go of individual productivity as your core identity.

It can feel uncomfortable to spend an entire week:

Unblocking another team’s architecture
Mentoring three engineers through design reviews
Refactoring a strategy doc for clarity

But that work, while not “productive” in the traditional sense, creates leverage. It increases the speed and quality of decision-making across the org. And that’s far more valuable than a few extra commits.

At Google, Staff Engineers are frequently evaluated not on how much they shipped but on how much shipping they made possible.

You Don't Wait for Permission

Many of the highest-impact things you’ll do at Staff level won’t be assigned to you.

You’ll see something broken or inefficient something that slows teams down, causes confusion, or erodes confidence and instead of walking past it, you’ll stop. You’ll dig. You’ll propose a fix. And you’ll carry it through.

You don’t do this for credit. You do it because it’s necessary.

Often, the clearest indicator that someone is ready for a Staff title is that they're already doing the work, without waiting for the role to make it official.

What Didn’t Work

Along the way, some instincts that served me well at the Senior level turned out to be limiting:

Trying to scale impact by coding more hours
Accepting every request instead of focusing on what truly moves the needle
Assuming good work would always be recognized without communicating it

Letting go of those reflexes, especially the drive to “just do it myself”, was uncomfortable, but necessary.

Finally

Becoming a Staff+ Engineer isn’t about being faster, louder, or smarter than your peers. It’s about changing your relationship to impact, scope, and responsibility.

It’s about becoming the person who:

Brings clarity where there’s confusion
Sees risk where others see progress
Connects dots others didn’t realize were connected
Makes other people better by how they think and work

Clarity, trust, and long-term thinking.

That’s what made the difference for me and what I look for when I see others growing into this kind of role.

There’s no single path to get there. But if you're already showing up like that, your title will probably catch up eventually.

Supercharge Your Spring Boot App with Java 21 and Native Image

Meidi Airouche — Tue, 06 May 2025 08:00:05 +0000

TL;DR: We migrated a classic Spring Boot microservice to Spring Boot 3 + Java 21 + GraalVM Native Image + Virtual Threads. We dropped cold starts from 3.4s to 75ms and cut memory usage by 4x — without rewriting the world. Here's how we did it.

A few months back, our invoice-service was what you'd call "classic enterprise Java service"... it worked fine, until it didn’t.

Many alerts because of too long startup times. Memory usage kept creeping up. Scaling wasn't instant. We were paying for warm-up time on Kubernetes like it was 2015.

We knew something had to change.

This is the story of how we made that service native, fast, and cloud-ready.

The Service: What We Started With

invoice-service handles:

Invoice persistence (via JPA)
PDF generation (Apache PDFBox)
Calling an external payment API
Sending out emails

Basically: I/O, I/O, and more I/O.

Here’s the old stack:

Java 11
Spring Boot 2.7
RestTemplate
Fat JAR Docker build (~250MB)
Cold start in K8s: ~3.4 seconds
Memory: ~220MB idle

It ran, sure — but it was sluggish. Not exactly cloud native friendly.

Java 21 + Spring Boot 3

We bit the bullet and upgraded. Honestly, the Jakarta EE namespace migration was more annoying than hard:

javax.persistence -> jakarta.persistence
javax.servlet -> jakarta.servlet

Painful? A little. But manageable.

Once we were on Spring Boot 3.2 + Java 21, we got:

Hibernate 6 with improved performance
Out-of-the-box observability
Support for virtual threads
AOT and native image support baked in

Already, startup dropped to ~2.1 seconds — not bad for zero code change.

Virtual Threads to the Rescue

Here’s where things got spicy.

We noticed that invoice creation was bottlenecked by thread pool saturation. It had to:

Save to the DB
Generate a PDF
Call payment API
Send an email

All mostly I/O. We had been using @Async + thread pools. It worked, but the tuning was fragile.

With Java 21’s virtual threads, we rewrote it like this:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<Invoice> saved = scope.fork(() -> invoiceRepository.save(request.toEntity()));
    Future<File> pdf = scope.fork(() -> pdfService.generatePdf(request));
    Future<Void> payment = scope.fork(() -> paymentClient.callApi(request));
    Future<Void> mail = scope.fork(() -> emailService.sendMail(request));

    scope.join();
    scope.throwIfFailed();

    return new InvoiceResponse(saved.resultNow(), pdf.resultNow());
}

No CompletableFuture, no custom ExecutorService. Just readable, parallel logic with safe cancellation and error propagation.

Under load testing, throughput jumped by ~40%, and CPU dropped ~15%.

Going Native with GraalVM

We always talked about GraalVM like it was a mythical beast: powerful, but dangerous. Turns out, with Spring Boot 3, it’s shockingly tame.

We added this to our build:

./mvnw -Pnative -DskipTests spring-boot:build-image

Result:

Native binary ~60MB
Cold start: ~75ms
RAM usage idle: ~48MB

Yes, you read that right — a real Java microservice, starting faster than some Go apps.

Deploying this in our cluster felt like cheating.

Observability Still Works in Native

Here’s the cool part: tracing, metrics, and logs kept working after the native build.

With Micrometer Tracing and OTEL, we added:

management:
  tracing:
    enabled: true
    sampling:
      probability: 1.0
    otlp:
      endpoint: http://otel-collector:4317

No code change.

We got:

DB spans
HTTP client/server spans
PDF generation timing
Distributed trace correlation across services

Spring handled everything. Even in native mode. That was a wow moment.

Before vs After

Metric	Before (JVM)	After (Native + VT)
Cold Start Time	~3.4s	~75ms
Memory Usage (idle)	~220MB	~48MB
Docker Image Size	~250MB	~80MB
Concurrency Performance	Moderate	Great (I/O-scaled)
Observability	Manual setup	Built-in w/ OTEL

Lessons Learned

Virtual threads rock for I/O-heavy services. We didn’t need to switch to WebFlux to scale.
GraalVM is production-ready now, especially with Spring Boot’s AOT engine.
Native apps don’t mean losing Spring magic — metrics, tracing, profiles… all still work.
If you’re using RestTemplate, just don’t. WebClient or nothing.
We didn’t rewrite the service. We just upgraded it intelligently.

Final Thoughts

Spring Boot 3 + Java 21 + GraalVM isn’t just “the latest thing.” It’s a better way to build Java services.

Smaller
Faster
Cloud-native by design

Back in the game to compete with Quarkus ;)

AWS Solution Architect Pro: advice from an AWS Instructor

Meidi Airouche — Fri, 13 Dec 2024 10:25:09 +0000

The AWS Solution Architect Professional certification is probably one of the hardest ones. Unlike some other certifications, working to achieve it provides you with significant and robust knowledge about AWS, as well as the most popular patterns and technologies in the market.

Coupled with practical experience, this certification can help you advance to another level very quickly. At least, that was the case for me.

As an AWS Authorized Instructor since 2019, I have passed many AWS certifications and trained numerous people to achieve the same. I’m writing this article to share my real-life feedback on how to prepare for the exam the right way and the pitfalls to avoid.

The AWS Journey Framework

When I was a consultant, I worked closely with AWS training teams, and we aligned on the observation that even though many people train for the certification and attend classrooms, less than half of them actually register for the exam. Often, this is due to a lack of time because of work, family obligations, etc.

We then built a training framework to support people from start to finish: getting certified.

Here is the framework we developed in 5 steps:

Official Training: If you or your company can afford it, take 5 days of official training for the certification with an AWS Authorized Instructor. These sessions are intense and can save you a lot of time, even though you’ll need to complement them with self-training. They allow you to block dedicated time to dive into the most important topics for the certification. By the end of the 5 days, you’ll only need to cover side topics and will already feel comfortable with the core ones.
AWS Skill Builder: AWS used to offer free training classrooms with instructors to answer questions and conduct practice exams with other certification candidates. Now, AWS Skill Builder has replaced this. However, in my experience, I don’t find it very useful. While it offers a lot of content, it lacks a clear and complete learning path.
Self-Training: A consistent self-training platform is a crucial step.
Practice Tests: Practice tests must be done on a good platform. In the past, I wasted time with irrelevant practice tests sold by AWS.
Exam Registration: Don’t wait to feel “ready” before registering for the certification. Here’s a rule I never break: I always register after my first practice exam. This first attempt gives me an idea of the time I need to prepare. Then, I pick a date. Having a booked exam date keeps me motivated and focused on the objective.

This approach worked for me and, with small variations, for my students. Over the past 5 years, I’ve trained approximately 300 people, and every single one who followed these steps passed.

My advice for the learning

First of all, you need to acquire a significant amount of knowledge about AWS Cloud infrastructure and the many services it offers. I wanted a solid foundation, so I reviewed many videos—even those I had already seen for the Solution Architect Associate certification—to reinforce my understanding. I also needed instructors with good English skills and effective communication to avoid the “Homer Simpson Monkey” effect after 3 minutes.

Recommended self-training platforms

QA (former Cloud Academy) offers good training paths with labs to practice, section tests, final exams, etc. It’s a great way to prepare yourself or complement the 5-day training with an AWS Authorized Instructor.
The Gold Content according to me is the training made by Adrian Cantrill here. This is what I used, and trust me, it’s the best $80 you’ll ever spend. This course not only helped me achieve the certification but also prepared me to manage AWS services with deep and consistent knowledge.

Practice exams platform

The AWS SA Pro exam is notoriously difficult to prepare for because every practice test takes around 3 hours, and you need to complete multiple tests to feel ready. I won’t sugarcoat it—this part is challenging. Even during re-certification, it’s the part I dislike the most. Here’s my routine:

Every day during lunch, I complete 20 questions.
After a few weeks, I take 2–3 full-length exams under real conditions on weekends. This is crucial because practice tests often cover concepts absent from training courses. They also help you familiarize yourself with the question types and answer formats. My favorite platform is Whizlabs, as many of its training questions appear in the actual certification exam.

My advice for the exam

Here is a list of advice that can be very useful the D-Day :

If you’re unsure of the correct answer, try to eliminate the wrong ones.
Look for keywords in the question. For example, questions about IAM (roles) or Kinesis (real-time) are easy to recognize.
Try not to spend more than 2 minutes per question.
Don’t overthink—there are no trick questions.
Don’t stress if you don’t know the answer to the first few questions. The later ones might be simpler..
Don’t anticipate failure. I’ve passed 7 AWS exams, and 6 times I was convinced I’d fail halfway through. I didn’t.

Useful information

Here is a recap of useful information about this certification :

Duration : 180min
Cost : 300$
Number of questions : 75
Average passing score : 75%

If you have questions, feel free to comment this article.

Setup a Micro-Frontend architecture in 15min with Vite!

Meidi Airouche — Tue, 10 Dec 2024 13:06:20 +0000

In a monolithic frontend architecture, a single codebase handles the entire user interface. While this can simplify initial development, it can become complex as the application grows:

Scaling: Large teams working in a monolithic repo may face merge conflicts, slower CI/CD pipelines, and difficulty with dependencies
Independency: sometimes working on shared stuff can impact other teams
Resilience: a failure can bring down the whole application

Micro-frontends can help when you start facing those problems. Unlike Web Components, coming with limited inter-framework communication and lifecycle management challenges, Vite based micro-frontends allow developers to work with differents frameworks. They provide flexibility in tooling, better state management, and more robust integration options. In a real life software growing through years, being able to handle multiple frameworks can be a smooth way to migrate from an old one to a new one whenever it's needed.

In this article, we’ll create a micro-frontend setup using Vite as our build tool and combine Vue.js, Angular, and React components into a unified experience. The example? A modular news portal, where each framework handles a specific section.

Modular News Portal

This modular news portal will have :

a Header made with Vue.js: with a simple navigation bar
a Trending made with React: with the last articles to show
an Highlights made with Angular: with the most popular articles to show

In a real-world example, separating news management across multiple technologies wouldn’t be ideal, but it serves our example well.

Building the Shell

In micro-frontend architecture, the Shell acts as the container for the micro-frontends. It has 3 main features :

Coordination: The Shell is responsible for loading and rendering the different micro-frontends into designated areas of the application
Orchestration: It handles global concerns like navigation, shared styles, shared state, data...
Entry Point: This is what the users loads first in their browser. It can also provide fallbacks if one of the micro-frontends fails to load.

The Shell in our setup will use Vite and load ESM modules dynamically:

host/
├── index.html  # Main entry point
├── main.js     # Loads the micro-frontends
├── vite.config.js
├── package.lock.json
├── package.json
apps/            # Contains individual micro-frontends
├── header/
    ├── src/
        ├── components/
            ├── Header.vue
        ├── main.js
    ├── vite.config.js
    ├── package.lock.json
    ├── package.json
├── trending/
    ├── src/
        ├── components
            ├── Trending.jsx
        ├── main.jsx
    ├── eslint.config.js
    ├── package.lock.json
    ├── vite.config.js
├── highlights/

Let's build it !

We start by initializing a Vite workspace for our host and micro-frontends.

mkdir news-portal && cd news-portal  
npm init vite@latest host --template vanilla

Let’s organize the project to separate each micro-frontend:

mkdir -p apps/header apps/trending apps/highlights

Now, let's create our simple index.html with the components architecture inside our DOM :

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>News Portal</title>
</head>
<body>
  <div id="header"></div>
  <div id="trending"></div>
  <div id="highlights"></div>
  <script type="module" src="./src/main.js"></script>
</body>
</html>

Now, let's create our main.js file that is responsible of mounting the micro-frontends (note that imports won't work until we build our micro-frontends):

// main.js
import { mount as mountHeader } from '../apps/header/dist/header.js';
import { mount as mountTrending } from '../apps/trending/dist/trending.js';
import { mount as mountHighlights } from '../apps/highlights/dist/highlights.js';

mountHeader(document.querySelector('#header'));
mountTrending(document.querySelector('#trending'));
mountHighlights(document.querySelector('#highlights'));

Then, we create the Vite configuration inside vite.config.js to enable the Vite server :

// vite.config.js
import { defineConfig } from 'vite';

export default defineConfig({
  server: {
    port: 3000,
    open: true,
  },
});

Start the Shell to be ready to serve :

cd host
npm install
npm run dev

And here we are : we've successfully created our Shell and it's ready to serve our future micro-frontends. Now, let's create them !

Building the Header with Vue 3

Let's create our Header folder inside apps and navigate into it:

cd apps
npm init vite@latest header --template vue  
cd header  
npm install

Inside src/components/Header.vue, create a simple header with navigation and for example a search bar:

<template>
  <header class="header">
    <nav>
      <ul>
        <li><a href="#">Home</a></li>
        <li><a href="#">World</a></li>
        <li><a href="#">Tech</a></li>
        <li><a href="#">Sports</a></li>
      </ul>
    </nav>
    <input type="text" placeholder="Search news..." />
  </header>
</template>

<script>
export default {
  name: 'Header',
};
</script>

<style scoped>
.header {
  display: flex;
  justify-content: space-between;
  padding: 1em;
  background: #333;
  color: white;
}
nav ul {
  display: flex;
  list-style: none;
}
nav ul li {
  margin-right: 1em;
}
input {
  padding: 0.5em;
}
</style>

We need a src/main.js to mount the component :

import { createApp } from 'vue';
import Header from './components/Header.vue';

export function mount(el) {
  createApp(Header).mount(el);
}

Configure vite.config.js to expose this app as a library :

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

// https://vite.dev/config/
export default defineConfig({
  plugins: [vue()],
  build: {
    lib: {
      entry: './src/main.js',
      name: 'Header',
      fileName: 'header',
    },
  },
})

Finally, build the micro-frontend to generate the dist folder :

cd apps/header
npm run build

You should now be able to see your Header served in your Shell. It happens because we told to our Shell to serve the dist folder of our Header and we generated it with the npm build command.

Building the Trending section with React 18

Let's create our Trending folder inside apps and navigate into it:

cd apps
npm init vite@latest trending --template react  
cd trending
npm install

Add a Trending component in src/components/Trending.jsx

import React from 'react';

const Trending = () => {
  const articles = [
    { id: 1, title: "React 18 Released", summary: "Learn what's new in React 18." },
    { id: 2, title: "AI Revolution", summary: "How AI is transforming industries." },
  ];

  return (
    <section className="trending">
      <h2>Trending News</h2>
      <ul>
        {articles.map((article) => (
          <li key={article.id}>
            <h3>{article.title}</h3>
            <p>{article.summary}</p>
          </li>
        ))}
      </ul>
    </section>
  );
};

export default Trending;

We need a src/main.jsx to mount the component :

import React from 'react';
import ReactDOM from 'react-dom/client'; 
import Trending from './components/Trending';

export function mount(el) {
  const root = ReactDOM.createRoot(el); 
  root.render(<Trending />); 
}

Configure vite.config.js :

import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    lib: {
      entry: './src/main.jsx',
      name: 'Trending',
      fileName: 'trending',
    },
  },
});

Build to generate the dist folder :

npm run build

And here we are ! We now have our second micro-frontend served inside our Shell, under our Header.

Building Highlights with Angular 19

Edit: I haven't been able to make Vite works with Angular 19 without module federation, custom element or widget yet. I'm currently trying to find the best approach between the 3 to propose you the most efficient in a later edit of this post.

Bonus: Runtime Federation with Vite

While the approach described above focuses on combining microfrontends during the build step, for production, you might want to embrace runtime federation. This approach offers true independence for microfrontends, allowing each module to be deployed separately and updated independently.

Each microfrontend can be hosted on its own server or domain. For example:

https://header.news-portal.com for Header
https://trending.news-portal.com for Trending

Dynamic Loading in the Shell Application

The shell application dynamically loads microfrontends at runtime using import() or similar methods. Here’s how the shell could dynamically load both the Header and Trending modules from their respective URLs, listed in a microfrontend manifest json document, in the Shell main.js :

Manifest of microservices (ex: https://news-portal.com/microfrontends.json) :

[
  {
    "name": "Header",
    "url": "https://header.news-portal.com/dist/header.js"
  },
  {
    "name": "Trending",
    "url": "https://trending.news-portal.com/dist/trending.js"
  }
]

Shell main.js :

export default {
  data() {
    return {
      modules: [],
    };
  },
  async mounted() {
    try {
      const response = await fetch('https://news-portal.com/microfrontends.json');
      const microfrontends = await response.json();

      for (const mfe of microfrontends) {
        const module = await import(mfe.url);
        this.modules.push({
          name: mfe.name,
          component: module.default,
        });
      }
    } catch (error) {
      console.error('Failed to load microfrontends:', error);
    }
  },
  template: `
    <div>
      <h1>Shell App</h1>
      <div v-for="module in modules" :key="module.name">
        <component :is="module.component" />
      </div>
    </div>
  `,
};

Sharing Dependencies

To avoid duplicating common dependencies like Vue, we could use peerDependencies in our package.json and externalize them in the Vite build process. We can configure it in vite.config.js :

import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    rollupOptions: {
      external: ['vue'], // Prevent bundling Vue with the module
    },
  },
});

This ensures that the Shell provides the dependency (e.g., Vue), and both Header and Trending modules rely on the same instance.

Benefits of Runtime Federation

Independent Deployments: Each module can be updated without redeploying the entire application.
Scalability: Teams can work on different microfrontends autonomously.
Dynamic Composition: New modules can be added or updated without touching the shell or other microfrontends.

Common pitfalls

Port Conflicts

Assign a unique port to each micro-frontend in vite.config.js or angular.json to avoid conflicts

Shared Libraries

Use a shared CDN for common libraries to reduce duplication and bundle sizes
Ensure version compatibility to avoid runtime errors

CORS problems

During local development, micro-frontends hosted on different ports may face CORS issues due to browser security policies

For production, configure your web server to allow cross-origin requests:

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Origin, Content-Type, Accept';

Minimize CORS requirements by deploying all micro-frontends and the Shell under the same domain or subdomain structure (e.g., https://news-portal.com/header, https://news-portal.com/trending).

Github link

Github to the code : Code Repository

Conclusion

Congratulations, you've setup your first MicroFrontend architecture with Vite. For those who already used web components in the past, you may find it really simpler and useful. I hope it will be a good help to set up your first MFE projects whenever you'll need to decouple the development of multiple front parts of your software.

Using CDC or Outbox pattern in microservices for decentralized data propagation

Meidi Airouche — Mon, 04 Nov 2024 23:13:30 +0000

Introduction

When it comes to Event Driven Architectures, people use to think about Fan-Out pattern, maybe Event-Sourcing... But there are numerous patterns that are working well with events.

When you're having multiple microservices with each their own database, you may face data propagation challenges.

Data propagation challenge in microservices

Let's take a simple example with a blog:

User microservice: handle user's stuff and have basic information about registered users with its own users database.
Article microservice: is responsible of CRUD on published articles.

But here is the thing : an article is written and edited by a user. So if my user is updating some information, like, for example, his username, every articles have to be updated to match the new name and not the old one.

This is where data propagation may occur. There are other solutions to tackle this problem but data propagation is a popular one.

The purpose of data propagation is to be able to detect data changes and to inform interested microservices with this change to properly handle it their way. In our example, we simply wanna update our username in article microservice whenever updated in uses microservice as follows.

1 - User create an article

2 - User change his username calling only user microservice

3 - Username update must be propagated to article

Common approaches

A pretty common, but not optimal approach I often see, is to use Fan-out pattern to fire multiple events from the business logic or data layer of microservices and to publish it into a topic. The problem with this approach is that it makes you write code to fire events whenever a data change occur and add complexity in those layers.

So, how do CDC pattern helps us to do it in a better way ?

The concept of Change Data Capture

CDC consist in being able to determine what changed in a database and to react to this change.
In Event Driven Architectures, CDC react to changes with events through topics, queues or streams.

A good example of CDC oriented database is AWS DynamoDB. With the DynamoDB Stream option activated, every change in every item of the database is sent through a stream as a shard. Each shard contains the nature of the change and a previous and new state.

You can natively react to shards with AWS lambdas for example but also, within any of your applications using AWS SDK with the programing language you're using.

The outbox pattern alternative

Also, if you are in a relational context and work wih an SQL database, you have to be aware of the Outbox pattern. The Transactional Outbox pattern consist in sending events only whenever a RDBMS transaction is fully achieved assuming that there are no desync of data across the distributed system.

A well known technology that is implemeting this pattern id Debezium. It's watching the transactions within a RDBMS to send events into a Kafka topic anytime the data is changing.

Using Outbox pattern with Debezium in our context

In our first example, we have an SQL database so Debezium should be a good fit to achieve our data propagation.

The user name is updated in his own database
The change is detected by Debezium
Debezium fires an event into a topic with the previous usernmae and the new userName
Article microservice is subscribed to the topic and react to the event by triggering an update of all of the articles written by the previous userName setting the authorName to new userName.

Conclusion

Finally, we saw that there are several ways to achieve data propagation in a distributed system. Fan-out can bring some extra code and complexity that could be handled by some technologies using CDC or Outbox pattern like DynamoDB Streams, Debezium, Redis pub/sub...

As always, those methods must be used whenever you feel it's answering the problem you're facing and not applied everywhere without consideration. But it's good to know that it exists to avoid introducing unnecessary complexity into the code.

High-performance Chat with TypeScript, Websockets & Redis in 10min !

Meidi Airouche — Tue, 06 Aug 2024 14:50:17 +0000

The purpose of this article is to understand the basics of websockets and cache with a common known example : a Chat.

Usually, a Chat have to be really reactive with very good performance. There are many ways to achieve different levels of performance.

In this article, we'll build a basic sample high-performance Chat together with Typescript, Redis and Websockets. I'll guide you step-by-step as if I was doing it with you.

First, let's take a look at our architecture.

Architecture

To the keep things simple, we'll be doing the frontend in plain HTML/JS without framework
The Nodejs server will be written with express as it's most known.
A Redis server to cache messages

Tips : If you wanna enhance performance further, you can opt for another framework like fastify, websocket.io, uWebSocket or whatever you want. We'll stay with express as it's well commonly known.

Backend

Project structure

.
├── docker-compose.yml
├── Dockerfile
├── src
│   ├── index.ts
│   ├── server.ts
│   ├── redisClient.ts
│   └── types.ts
├── tsconfig.json
└── package.json

Create the nodejs project

npm init

and feed the package.json file with the following configuration :

{
  "name": "chat-app",
  "version": "1.0.0",
  "main": "dist/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  },
  "dependencies": {
    "express": "^4.17.1",
    "redis": "^4.0.0",
    "ws": "^8.0.0"
  },
  "devDependencies": {
    "@types/node": "^16.0.0",
    "@types/ws": "^8.0.0",
    "typescript": "^4.0.0"
  }
}

Install dependencies into your project

npm install express ws redis 
npm install --save-dev typescript @types/node @types/ws @types/express @types/redis

If not already done, don't forget to configure your tsconfig.json :

{
  "compilerOptions": {
    "target": "ES6",
    "module": "commonjs",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  }
}

Coding

Redis client configuration

Let’s create our Redis configuration in a dedicated file ./src/redisClient.ts. Here, we're connecting the client to Redis and we listen for errors to raise it in the console.

import { createClient } from 'redis';

const client = createClient({
  url: 'redis://redis:6379' // we'll create the docker image later
});

client.on('error', (err) => {
  console.error('Redis Client Error', err);
});

client.connect();

export default client;

Message type or interface

We’ll be creating an interface (create a type if you prefer) to structure our Chat messages in ./src/chatMessage.ts. Let’s keep it simple and have only 3 attributes :

username: the name of the message author
message: the content of the message
timestamp: date and hour of the message as a timestamp

export interface ChatMessage {
  username: string;
  message: string;
  timestamp: number;
}

Http & Websocket servers

Here, we’ll be creating two servers in ./src/server.ts :

HTTP server with express to handle http calls
Websocket server to handle websocket messages

import express from "express";
import { WebSocketServer } from "ws";
import redisClient from "./redisClient";
import { ChatMessage } from "./chatMessage";

const app = express();
const port = 3000;

app.get("/", (req, res) => {
  res.send("Chat server is running");
});

const server = app.listen(port, () => {
  console.log(`Web server is running on http://localhost:${port}`);
});

const wss = new WebSocketServer({ server });

wss.on("connection", (ws) => {
  console.log("Client connected");

  // Send chat history to new client
  redisClient.lRange("chat_message", 0, -1).then(
    (messages) => {
      messages.forEach((message) => {
        ws.send(message);
      });
    },
    (error) => {
      console.error("Error retrieving messages from Redis", error);
      return;
    }
  );

  ws.on("message", (data) => {
    const message: ChatMessage = JSON.parse(data.toString());
    message.timestamp = Date.now();
    const messageString = JSON.stringify(message);

    // Save message to Redis
    redisClient.rPush("chat_messages", messageString);
    redisClient.lTrim("chat_messages", -100, -1); // Keep only the last 100 messages

    // Broadcast message to all clients
    wss.clients.forEach((client) => {
      if (client.readyState === ws.OPEN) {
        client.send(messageString);
      }
    });
  });

  ws.on("close", () => {
    console.log("Client disconnected");
  });
});

console.log("WebSocket server is running on ws://localhost:3000");

So, what are we doing here :

First, we setup the Web and WebSocket servers.
Second, on the websocket connection, we pull the Chat history from redis
Third, we listen for new messages and record them in redis, keeping only the 100 last message anytime
Fourth, we broadcast each messages to all the connected clients of the Chat

If you wanna go further, you can implement an observer pattern where each websocket client is an observer. But for now, let's keep the things simple.

For barrels fans, don’t forget to add your app entrypoint in ./src/index.ts :

import './server';

You can launch the server with :

npm run build
npm start

Frontend

As we said it previously, we'll build a simple example which does not take account of best practices for the article. Create a single index.hml with the following code :

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Chat</title>
</head>
<body>
  <div id="chat">
    <ul id="messages"></ul>
    <input id="username" placeholder="Username">
    <input id="message" placeholder="Message">
    <button onclick="sendMessage()">Send</button>
  </div>
  <script>
    const ws = new WebSocket('ws://localhost:3000');
    const messages = document.getElementById('messages');

    ws.onmessage = (event) => {
      const message = JSON.parse(event.data);
      const li = document.createElement('li');
      li.textContent = `[${new Date(message.timestamp).toLocaleTimeString()}] ${message.username}: ${message.message}`;
      messages.appendChild(li);
    };

    function sendMessage() {
      const username = document.getElementById('username').value;
      const message = document.getElementById('message').value;
      ws.send(JSON.stringify({ username, message }));
    }
  </script>
</body>
</html>

So what are we doing here :

We setup the html document to have the needed fields and button to send a message
We setup the websocket connection with the server
We publish every message to the websocket anytime the button is pressed calling the function sendMessage()

All together with docker compose

Create a Dockerfile for the server

# Use official Nodejs image
FROM node:18

# Work directory
WORKDIR /usr/src/app

# Copy package.json & package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy sources files
COPY . .

# Compile Typescript
RUN npm run build

# Expose web server port
EXPOSE 3000

# Start the server
CMD ["npm", "start"]

Create a Docker compose file to assemble

Let's assemble the web server and Radis server inside a docker-compose.yml file.

version: '3.8'

services:
  redis:
    image: redis:latest
    container_name: redis
    ports:
      - "6379:6379"

  app:
    build: .
    container_name: chat-app
    ports:
      - "3000:3000"
    depends_on:
      - redis
    volumes:
      - .:/usr/src/app
    command: npm start

Building and starting the whole stack

To build and run the whole backend stack with docker images, use :

docker-compose up --build

Open your index.html file and start sending messages. We're done ! A high-performance chat with websocket and Redis !

Sources

Link : GitHub Repository

Hope it helps to understand basics. After that, you might be willing to take a look at Observer pattern and framworks like socket.io. Enjoy !

DEV Community: Meidi Airouche

Multi-Agent Platform with A2A, Python, Strands & AWS AgentCore

What we are building

Components

Runtime request flow

1 — Configuration (env vars)

HR Agent env

IT Agent env

Orchestrator env

2 — HR Agent handler (AgentCore Runtime + RAG)

Why os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID?

What “RAG” means here

3 — IT Agent handler (AgentCore Runtime + RAG)

Why separate agents instead of one big agent with two KBs?

4 — Orchestrator handler (AgentCore Runtime + A2A tools)

Orchestrator key behaviors

Why implement HR/IT calls as tools?

5 — A2A call parsing

6 — Lazy initialization (production detail that matters)

7 — How routing actually happens

8 — Failure modes and debugging

Missing URL

Network/A2A issues

9 — Practical hardening ideas (optional)

Why this architecture scales

Final thoughts

RAG Works — Until You Hit the Long Tail

Why Training Knowledge Into Weights Is the Next Step Beyond RAG

The real problem is not the knowledge cutoff

Three ways to give knowledge to a language model

Full context: simple, expensive, and fragile

The transformer bottleneck and context degradation

RAG: external memory via embeddings

Why RAG is fundamentally limited

The naive fine-tuning trap

Synthetic data as the missing link

Training into weights without destroying the model

A hybrid future: context, retrieval, and weights

Conclusion

How Reasoning LLMs Are Challenging Orchestration

The usual way: Manual Orchestration with LangGraph

The New Approach: Reasoning Models + MCP Tools

Reasoning Traces as Your New Logs

Observing Cognition in Production

What You Trade (and Gain)

Lessons (and Mistakes) from the Field

When AWS Gets It Right with AgentCore

Finally

Cloud Is No Longer a Specialty — It’s the Operating System of Modern Engineering

Why this became inevitable

What actually changes in the roles

The new baseline

Market direction: more cloud, more accountability

Where this doesn’t fully apply (yet)

What to do with this

Conclusion: where seniority now comes from

How to Create a Web Search AI Agent with AWS Bedrock

Global Solution

Prerequisites

Configure the Serper API

Web search AWS Bedrock agent using the console

Create a web search agent

Lambda function configuration & code

Test the agent

Final thougts

AWS Kiro: Another AI-Powered IDE Challenger or a Game Changer?

What is AWS Kiro?

Feature Comparison

Workflow differences

Pricing

When to Use Which Tool

Pros and Cons of Kiro

How to Use Kiro Effectively ?

Installation & Setup

Project Bootstrapping

Using Agents to Build Features

Pre-Commit Quality Hooks

Infrastructure Integration

Continuous Agent Workflows

Tips

Why `os.environ["KNOWLEDGE_BASE_ID"] = KNOWLEDGE_BASE_ID`?