Stuff about Software Engineering

Month: November 2025

Understanding Agentic Architectures and Why They Differ Fundamentally from Event-Driven Design

Introduction

In recent months, an increasing number of vendors and practitioners have begun describing event-driven architectures (EDA) as the foundation for agentic systems.

While both paradigms involve distributed and asynchronous systems, they address entirely different architectural concerns:

  • Event-driven design enables reliable data movement and temporal decoupling across systems.
  • Agentic design enables autonomous reasoning, coordination, and adaptive decision-making.

This post clarifies these differences through the lens of established architectural literature and pattern theory, helping distinguish between data-flow infrastructure and cognitive control-flow systems.

Pattern Lineage and Conceptual Heritage

Software architecture has evolved through distinct, well-documented pattern families—each solving a different class of problems:

DomainCanonical SourceArchitectural Concern
Software Design PatternsGamma et al., Design Patterns (1994)Structuring software components and behaviour
Enterprise Integration PatternsHohpe & Woolf, Enterprise Integration Patterns(2003)Asynchronous communication and integration
Pattern-Oriented Software ArchitectureBuschmann et al., Pattern-Oriented Software Architecture (1996–2007)Component interaction, brokers, and coordination
Agent-Oriented SystemsWooldridge, An Introduction to MultiAgent Systems(2009)Reasoning, autonomy, and collaboration

Each of these domains emerged to address a specific layer of system complexity.
Event-driven architectures belong to the integration layer.

Agentic architectures operate at the reasoning and control layer.

Event-Driven Architecture: Integration and Temporal Decoupling

Event-driven architecture decouples producers and consumers through asynchronous communication. Common patterns include Publish–SubscribeEvent Bus, and Event Sourcing.

Its core strengths are:

  • High scalability and throughput
  • Loose coupling and resilience
  • Near-real-time responsiveness

EDA is therefore ideal for information propagation, but it does not address why or how a system acts. It transports information; it does not interpret or decide.

Agentic Architecture: Reasoning and Adaptation

Agentic systems focus on autonomous goal-directed behaviour. They implement a cognitive control loop:

Observe → Plan → Act → Learn

This structure—present since early multi-agent research—now underpins modern frameworks such as LangGraph, AutoGen, and Microsoft’s Autonomous Agents Framework.

Core principles include:

  • Control Flow: deciding what to do next based on context
  • Memory and Context: maintaining state across reasoning cycles
  • Tool Use: interacting with APIs or systems to execute plans
  • Collaboration: coordinating with other agents to achieve shared goals

Agentic architectures are thus control-graph frameworks, not messaging infrastructures.

Why “Event-Driven Agentic Architecture” Is a Conceptual Misstep

Confusing event-driven integration with agentic reasoning conflates communication with cognition.

Common AssertionCorrect Interpretation
“Agents communicate through Kafka topics.”That describes data transport, not reasoning or collaboration.
“Event streaming enables autonomy.”Autonomy arises from goal-based planning and local state, not from asynchronous I/O.
“Event mesh = Agent mesh.”An event mesh routes bytes; an agent mesh coordinates intent.
“Streaming platforms enable multi-agent collaboration.”They enable message exchange; collaboration requires shared semantic context and decision logic.

EDA can support agentic systems—for example, as a trigger or observation channel—but it does not constitute their architectural foundation.

Maintaining Conceptual Precision

Architectural vocabulary should map to the corresponding canonical lineage:

ConcernCanonical Reference
Integration, routing, replayHohpe & Woolf, Enterprise Integration Patterns
Reasoning, autonomy, coordinationWooldridge, An Introduction to MultiAgent Systems
System decomposition, blackboard, broker stylesBuschmann et al., Pattern-Oriented Software Architecture
Modern control-flow frameworks for AI agentsLangGraph, Microsoft Autonomous Agents Framework (2024–2025)

Anchoring terminology to established pattern families preserves conceptual integrity and prevents marketing-driven drift.

Practical Implications

  1. Use event-driven design for system integration, data propagation, and observability.
  2. Use agentic design for autonomy, reasoning, and goal-oriented workflows.
  3. Keep a strict separation between data flow (how information moves) and control flow (how decisions are made).
  4. Evaluate vendor claims by tracing them back to canonical architectural literature.
  5. Foster literacy in software and integration pattern theory to maintain shared architectural clarity across teams.

Recommended Reading

  • Wooldridge, M. (2009). An Introduction to MultiAgent Systems (2nd ed.). Wiley.
  • Hohpe, G., & Woolf, B. (2003). Enterprise Integration Patterns. Addison-Wesley.
  • Buschmann, F. et al. (1996–2007). Pattern-Oriented Software Architecture Vols 1–5. Wiley.
  • Gamma, E. et al. (1994). Design Patterns. Addison-Wesley.
  • LangChain / LangGraph Documentation (2024–2025). “Agentic Design Patterns.”
  • Microsoft Autonomous Agents Framework (Preview 2025).

Conclusion

Architectural precision is not academic—it determines how systems scale, adapt, and remain intelligible.

Event-driven architectures will continue to serve as the backbone of data movement.

Agentic architectures will increasingly govern how intelligent systems reason, plan, and act.

Understanding where one ends and the other begins is essential for designing systems that are both well-connected and truly intelligent.

Making Sense of LLM Training

Introduction

We often talk about training large language models (LLMs) as if it’s one thing — but it really isn’t.

There are several distinct types of training, each with its own purpose, cost, and level of control.

Understanding the difference helps clarify what’s realistic to do in practice, and what should be left to the model labs with thousands of GPUs and power budgets larger than small towns.

Here’s a simple breakdown.

Base Training — Learning Language from Scratch

This is where it all begins.

The model learns to predict the next word in a sentence across trillions of examples. It’s how it develops a general understanding of language, reasoning, facts, and relationships between concepts.

Purpose: Build a general-purpose foundation.

Data: Huge, diverse datasets (Common Crawl, Wikipedia, code, books).

Cost: Astronomical — only done by major labs.

Analogy: Teaching a child how to speak and read.

Once complete, this produces what’s called a base model — capable, but not polite, safe, or even particularly helpful.

Post-Training — Teaching Behavior and Alignment

After base training, the model needs to learn how to behave.

This phase adjusts it to follow instructions, respond helpfully, and align with human preferences and safety policies.

It typically involves:

  • Supervised Fine-Tuning (SFT): The model learns from curated examples of correct input/output pairs.
  • Reinforcement Learning from Human Feedback (RLHF): Humans rank several model responses, and the model learns to prefer the higher-ranked ones.
  • Reinforcement Learning from AI Feedback (RLAIF): The same, but with AI systems acting as evaluators.

Purpose: Make the model cooperative and safe.

Analogy: Teaching manners, ethics, and social intelligence after language is learned.

All commercial models — GPT-4, Claude 3, Gemini, Llama 3 — go through this step before they ever reach users.

Fine-Tuning — Specializing for a Domain

Fine-tuning takes a general model and teaches it domain-specific knowledge: medicine, law, brewing, internal documentation — whatever your niche may be.

There are a few variants:

  • Full fine-tuning: retraining all model weights (rare and expensive).
  • Parameter-efficient fine-tuning (LoRA, QLoRA, PEFT): training small adapter layers on top of the frozen base model — vastly cheaper and reversible.

Purpose: Adapt to a domain or style.

Analogy: Sending a fluent speaker to medical school.

In practice, fine-tuning makes sense only if you have high-quality, well-structured data and a clear purpose — for example, improving factual recall in a specific knowledge domain or matching a company’s tone of voice.

Reinforcement Fine-Tuning — Teaching Preferences and Optimization

A newer development combines reinforcement learning with fine-tuning to optimize specific, measurable outcomes — such as factuality, brevity, or computational efficiency.

OpenAI’s Reinforcement Fine-Tuning (RFT) of the o1 model is one recent example: instead of relying on humans to rate outputs, the process automatically scores model responses using well-defined reward functions.

Purpose: Optimize behavior using measurable rewards.

Analogy: Practicing until performance metrics improve, rather than memorizing answers.

Retrieval-Augmented Generation (RAG) — Adding Knowledge Without Training

RAG isn’t training at all — it’s a retrieval technique.

The model stays frozen but is connected to a search index, database, or vector store.

When asked a question, it first retrieves relevant information and then generates an answer grounded in that content.

Purpose: Keep models current and connected to external knowledge.

Analogy: Looking something up rather than memorizing it.

RAG is ideal when data changes frequently, or when you can’t or shouldn’t embed sensitive data into the model itself.

Prompt Tuning — Lightweight Personality Shaping

The lightest-weight form of adaptation is prompt tuning, sometimes called soft prompting.

Here, a small vector (or a few tokens) is trained to steer the model’s behavior without modifying its core weights.

Purpose: Adjust tone or persona without retraining.

Analogy: Giving the same person a new job description — “today you’re the legal assistant.”

Prompt tuning is useful when you want to offer multiple personalities or roles from a single model.

What’s Reasonable to Do (and What Isn’t)

To make this practical, here’s how the different kinds of training align with the Four Categories of AI Solutions from simple Copilot-style automation to custom AI systems built from scratch.

GoalTechniqueCost & EffortCategory (from “Four Categories of AI Solutions”)Typical Use
General chatbot or CopilotNone (use aligned base model)🟢 LowCategory 1 — Copilot / built-in AI featuresOffice copilots, internal Q&A bots
Domain expertiseLoRA / adapter fine-tuning🟠 MediumCategory 2 — Configured / composable solutionsIndustry copilots, internal assistants
Keep knowledge freshRAG or hybrid RAG + fine-tuning🟠 MediumCategory 3 — Integrated or extended AI systemsResearch assistants, customer-facing search
Optimize measurable outputReinforcement fine-tuning🔴 HighCategory 4 — Custom AI / in-house LLMsScientific computing, advanced R&D
Create new model familyBase training🚫 ExtremeBeyond Category 4Reserved for foundation model labs

Summary

  • Base training — teaches language.
  • Post-training (SFT/RLHF) — teaches behavior.
  • Fine-tuning — teaches domain knowledge.
  • Reinforcement fine-tuning — teaches optimization.
  • RAG / Prompt tuning — extend without retraining.

LLMs aren’t trained once — they’re trained in layers.

Each layer shapes a different aspect of intelligence: from raw linguistic intuition to helpful conversation, domain expertise, and ongoing adaptability.

Knowing which layer you’re working with isn’t just a technical detail — it’s the difference between using AI and building with it.

© 2026 Peter Birkholm-Buch

Theme by Anders NorenUp ↑