DEV Community: Lu Han

A Harnessed LLM Agent Is More Than Four Circles

Lu Han — Sat, 14 Nov 2026 08:07:51 +0000

Why a Runtime-Centric Architecture Is a Stronger Model for Agent Engineering

A reply to The Harness Behind Reliable LLM Agents, the post that introduced the diagram A Harnessed LLM Agent.

The diagram A Harnessed LLM Agent makes an important point: a capable agent is more than an LLM connected to a collection of tools. It needs reusable skills, memory, interaction protocols, execution controls, and mechanisms for evaluating its behavior.

That is a useful conceptual overview. But a conceptual overview is not automatically a sound reference architecture.

The diagram presents four ideas—Skills, Harness, Memory, and Protocols—as its main categories. The problem is that these ideas describe different architectural dimensions. Skills describe capabilities; Memory describes retained information; Protocols define interaction contracts; and Harness concerns execution and control. They are related, but they are not equivalent building blocks.

My argument is not that the four categories are wrong or unimportant. It is that listing them as four top-level categories obscures the relationships that make an agent work. For engineering purposes, a Runtime-Centric Agent Architecture is a more coherent starting point: the runtime coordinates the model, capabilities, state, protocols, and environment within a controlled execution lifecycle.

1. The Four Categories Do Not Belong to the Same Architectural Level

The original diagram groups four concepts that are useful to distinguish:

Concept	What it describes	The question it answers
Skills	Reusable capabilities and procedures	What can the agent do?
Harness	Execution and control mechanisms	How is the agent run and managed?
Memory	Retained information and knowledge	What does the agent remember?
Protocols	Communication contracts	How does the agent interact with users, other agents, and tools?

These are different dimensions, not four interchangeable subsystems.

Consider a coding agent asked to fix a bug. A skill may describe how to investigate a failure and modify code. Memory may provide repository conventions and relevant past findings. A protocol may define how the agent requests a tool operation. The runtime decides when to invoke the model, which action to dispatch, whether that action is allowed, how to capture its result, and whether the task should continue.

The distinction matters because the four concepts do not have symmetrical responsibilities. A skill does not own the task lifecycle. A protocol does not execute an operation merely by defining message formats and interaction rules. Memory does not decide which information is authoritative for the current task. The runtime coordinates these mechanisms as part of one execution process.

A useful architecture should make those relationships explicit rather than flatten them into a list of neighboring concepts.

2. Harness Should Be Understood as the Agent Runtime

The diagram presents the Harness as a collection of components around an agent: sandbox provisioning, sub-agent orchestration, observability, compression, evaluation, and approval loops. That arrangement is reasonable. However, Harness should mean more than a collection of utilities grouped around an agent.

It is better understood as the runtime and control infrastructure that manages the agent's execution lifecycle.

The model provides inference: it interprets context and proposes decisions or actions. The runtime turns those proposals into managed execution. It validates proposed actions, applies policy, dispatches operations, collects observations, updates state, and determines what happens next.

For example, when a model proposes a shell command, the runtime may need to:

Validate the proposed tool call and its arguments.
Check whether the agent is authorized to perform the operation.
Select an appropriate execution environment, including a sandbox where needed.
Execute the operation and capture its output.
Associate the result with the correct task and execution step.
Evaluate the result against the current step and the overall objective.
Continue, retry, request approval, or terminate the task.

The model can propose an action, but it should not be the ultimate authority on whether that action is permitted or whether it actually succeeded. Those guarantees belong to the runtime and the systems around it.

A concise definition is therefore:

Definition. Harness is the runtime and control infrastructure around an LLM. It manages the agent's lifecycle: assembling context, orchestrating actions, dispatching operations, transitioning state, processing feedback, enforcing policy, evaluating results, and supporting recovery.

The runtime coordinates these responsibilities; it does not own every policy or quality function it relies on. This definition also clarifies that Harness is not necessarily one deployable service or one monolithic process. It is a logical responsibility that may be implemented by several cooperating components.

3. The Execution Loop Is the Missing Architectural Center

The most important property of an agent is not that it contains several categories of components. It is that it can pursue an objective through repeated cycles of decision, action, and observation.

A simplified execution loop looks like this:

                 User Goal / Trigger
                         |
                         v
                 Context Assembly
            Inputs: Skills + Memory + Task State
                  + Relevant Policy
                         |
                         v
                  Model Inference
              Reasoning / Decision
                         |
                         v
             Policy & Authorization Check
                         |
                         v
                   Action Dispatch
                Tools / Skills / Agents
                         |
                         v
                   Environment
                         |
                         v
              Observation and Evaluation
                         |
                         v
                State and Context Update
                         |
                         +-----------> Next inference

                  Or: Complete / Escalate

The runtime manages this loop.

This makes the difference between a one-shot model interaction and an agent system clearer:

One-shot interaction:
Input -> Model -> Response (or one tool call)

Managed agent execution:
Goal -> Context -> Inference -> Action -> Observation
     -> Evaluation -> State Update -> Next Decision -> ...

The first produces a response or a single action; the second manages a task over time.

This is why planning, tool dispatch, evaluation, checkpointing, cancellation, retries, and recovery should be understood as parts of the runtime's execution responsibilities—not merely as a collection of optional features around a model.

4. Memory, State, and Context Are Different Things

The original diagram identifies Working Context, Episodic Experience, Semantic Knowledge, and Personalized Memory—roughly, working context, episodic memory, semantic knowledge, and user profile. These are useful ideas, but they mix different classification criteria.

Working Context is primarily about what is assembled for a particular inference step. Episodic and semantic memory describe types of retained information. A user profile describes information from the perspective of a particular user. These categories can overlap: a user's preference, for example, may be stored as a semantic fact and also appear in a user profile.

A more precise design separates operational state from persistent memory—and distinguishes both from context.

Operational state

Operational state represents what is happening in the current execution:

Task status and objective
Current plan and completed steps
Pending actions and tool calls
Intermediate results
Sub-agent assignments and results
Approval status
Checkpoints needed for resumption

This state is part of the execution record. It must remain authoritative even when the model's context is shortened or reconstructed.

Persistent memory

Persistent memory contains information that may be useful beyond the current execution:

Type	Examples
Episodic	Previous tasks, events, outcomes, and feedback
Semantic	Facts, concepts, entities, and relationships
Procedural	Methods, strategies, and learned ways of performing tasks
Profile	User preferences, project conventions, and organizational context

A second distinction matters as much: state versus context. Operational state is the underlying record of the execution. Context is the selected information assembled for a particular model call. Context can be compressed or reconstructed; omitting a fact from the prompt must not delete it from state.

Skills and procedural memory are related but should not be conflated. Procedural memory retains knowledge about how to perform a task. A skill is an engineered, reusable package—instructions, resources, constraints, and sometimes executable logic—that exposes a procedure through an interface the runtime can invoke.

5. Protocols Define Contracts; They Do Not Provide Execution by Themselves

The diagram groups Agent–User, Agent–Agent, and Agent–Tools under Protocols. This is a reasonable way to classify interaction patterns, but it can blur the boundary between communication and execution.

A protocol fixes message formats and interaction rules, but it leaves authorization, dispatch, and result correlation unspecified.

A tool interaction, for example, may involve several distinct responsibilities:

Model
  -> Tool-calling contract
  -> Tool dispatcher
  -> Authorization and policy checks
  -> Tool runtime
  -> External environment
  -> Result capture and correlation

The protocol defines the contract. The dispatcher routes the request. Authorization determines whether the operation is allowed. The tool runtime performs the operation. The environment produces the actual effects.

The same distinction applies to agent-to-agent collaboration. A communication protocol can standardize message exchange or task descriptions, but it does not automatically solve delegation, scheduling, ownership, timeout management, conflict resolution, or result verification. Those are runtime concerns.

In short: protocols define how components communicate; the runtime determines how those interactions participate in an executable workflow.

6. The Environment Deserves an Explicit Place

An agent does not act in an abstract space made only of prompts, memory, and tools. It acts in an environment: filesystems, browsers, databases, APIs, shells, development environments, and external services.

It is useful to separate the concepts involved:

Concept	Responsibility
Skill	Packages a reusable procedure or capability
Tool	Exposes an operation that can be invoked
Protocol	Defines the interaction contract
Runtime	Coordinates and controls execution
Environment	Hosts resources and produces observable effects

For example, a browser tool is an interface for interacting with a browser environment. A database connector exposes operations against a database; it is not the database itself. A sandbox is an execution environment that the runtime may provision, not a skill. The original diagram shows sandbox provisioning as a harness utility, but it does not give the sandboxed environment an explicit place.

Making the environment explicit improves reasoning about isolation, permissions, side effects, reproducibility, and recovery.

7. Governance Is Cross-Cutting

The original diagram includes normative constraints under Skills and an approval loop within Harness. Both are relevant, but neither is a sufficient home for governance. A skill can declare task-specific constraints, and the runtime can enforce them; system-wide policy, however, must remain authoritative independently of any individual skill or model-generated guidance.

Security, identity, authorization, policy, audit, and human approval affect multiple stages of execution:

Which skills may be loaded?
Which memories may be retrieved?
Which models and endpoints may be used?
Which tools may be invoked?
Which resources may be read or modified?
Which actions require human approval?
Which outputs may be returned or persisted?

Governance is therefore best represented as a cross-cutting responsibility. The runtime provides enforcement points, while policy ownership, identity, audit, and organizational controls may be implemented in separate services or infrastructure.

8. A Runtime-Centric Reference Architecture

These distinctions lead to a more coherent architecture. The following decomposition organizes the system by responsibility rather than treating every concept as a peer component.

The proposed architecture still has four outer domains—skills, memory, environment, and protocols. The difference is that they are arranged around a runtime rather than presented as four equivalent categories.

8.1 Interaction layer

Defines interfaces, communication contracts, and event sources:

User interaction
Agent-to-agent communication
Tool interaction protocols
Events and external triggers

8.2 Agent runtime / Harness

Coordinates the execution lifecycle:

Goal intake and task initialization
Scheduling and plan execution
Context assembly
Tool dispatch
Sub-agent coordination
State transition management
Feedback processing
Timeouts, cancellation, retries, and idempotency
Checkpointing and resumption

8.3 Cognitive layer

Provides reasoning and decision functions:

LLM inference
Reasoning
Decision-making
Task decomposition and plan generation

8.4 Capability layer

Provides reusable and executable capabilities:

Skills
Tools
Sub-agents
Retrieval
Code execution

8.5 State and memory layer

Provides durable state and reusable information:

Durable operational state
Episodic memory
Semantic knowledge
Procedural memory
User and project profiles

The runtime owns state transitions; this layer owns the durable record those transitions operate on.

8.6 Environment layer

Provides the resources and systems with which the agent interacts:

Filesystem
Browser
Databases
Network and APIs
Compute and sandbox infrastructure
External services

Cross-cutting governance and quality

Applies across the architecture:

Security and identity
Access control
Policy and compliance
Human approval
Observability and audit
Evaluation and quality assurance
Reliability and recovery policy

These functions set policy, standards, and audit requirements; the runtime implements the corresponding mechanisms. The layers are logical, not a mandate to deploy a separate service for each one. A small agent may implement several responsibilities in one process. A larger platform may distribute them across services. The purpose of the decomposition is to make ownership, interfaces, and invariants explicit—not to prescribe a deployment topology.

9. Why This Model Is More Useful for Engineering

A runtime-centric approach offers several practical advantages.

Model independence. Separating inference from runtime orchestration allows the system to change models or inference providers without redesigning task management, tool execution, and recovery.

Explicit failure semantics. Timeouts, cancellation, retries, idempotency, checkpointing, and resumption have clear architectural owners. They do not depend on the model remembering what happened.

Reliable state management. Operational state remains distinct from retrieved memory and prompt context. Context can be compressed or reconstructed without silently becoming the source of truth.

Composable capabilities. Skills and tools can evolve behind stable interfaces while orchestration, authorization, and observability remain consistent—making the system easier to maintain.

Enforceable security boundaries. Policy checks can be applied at relevant execution points. A model-generated tool request is a proposal, not proof of authorization.

Scalable multi-agent coordination. Delegation, concurrency, ownership, result aggregation, timeout handling, and failure propagation become explicit runtime responsibilities rather than being mistaken for protocol features.

10. A Fair Assessment of the Original Diagram

The criticism deserves precision. If the original diagram is intended as an introductory concept map, its four categories are useful: they remind readers that agents need capabilities, memory, execution control, and communication mechanisms.

The problem arises when the diagram is treated as a reference architecture. Its categories mix different levels of abstraction, the execution loop remains implicit, operational state is absent, Working Context is treated as a kind of memory, and the environment is not given an explicit layer.

A better architecture does not need to discard the original concepts. It needs to reorganize them around their actual responsibilities and relationships.

The four concepts still matter:

Skills belong to the capability model.
Memory belongs to the retained-information model; operational state belongs to the runtime.
Protocols belong to the interaction model.
Harness is the runtime and control layer.

They are all essential, but they do not occupy equivalent architectural positions.

Conclusion: Design Around Execution, Not Around a Collection of Components

The original diagram captures an important truth: a production-grade agent is much more than an LLM with tools. But its four-part classification is better understood as a conceptual checklist than as a rigorous system architecture.

For engineering, the more useful starting point is the execution lifecycle. The runtime coordinates inference, context, capabilities, state, protocols, and the environment. It manages actions and observations, preserves execution state, enforces policy, evaluates results, and supports recovery.

Memory should distinguish operational state from persistent knowledge. Skills should be treated as reusable capabilities. Protocols should be treated as communication contracts. The environment should be explicit. Governance should cross architectural boundaries.

The central question is therefore not simply “What components should an LLM agent have?” It is:

“How do we build a runtime that allows an intelligent system to pursue objectives over time, preserve state correctly, act within defined boundaries, use observations to adjust its behavior, and recover from failure?”

That is the harder engineering problem—and the reason a Runtime-Centric Agent Architecture is a stronger foundation for reliable, scalable, and maintainable agent systems.

Dynamic Loading Mechanisms in 10 Popular Programming Languages

Lu Han — Sat, 07 Jun 2025 17:36:17 +0000

Dynamic loading is a crucial technique in modern software development. It allows programs to load and use code modules at runtime, rather than having all dependencies fixed at compile time. This enables plugin systems, modular architectures, hot updates, and more.

In this article, we’ll explore how 10 mainstream programming languages implement dynamic loading, using a simple calculator project as a running example. We’ll cover the core principles, code samples, and best practices for each language.

What Is Dynamic Loading?

Dynamic loading refers to loading code modules or libraries at runtime and creating object instances in memory as needed. Unlike static linking, where all dependencies are resolved at compile time, dynamic loading offers:

🔥 Hot-swapping: Update features without restarting the program
🎯 On-demand loading: Reduce memory usage and startup time
🔧 Plugin architecture: Support third-party extensions
🚀 Modular design: Lower coupling and improve code reuse

Project Architecture

All examples implement the same interface for a calculator with four basic operations: addFn(a, b), subFn(a, b), mulFn(a, b), and divFn(a, b) (with zero-division checks).

The architecture consists of:

Application: Calls a unified interface
Dynamic Loader: Manages loading logic
Implementation Module: Provides actual functionality

1. Python – `importlib` Dynamic Module Import

Python uses the importlib module for dynamic loading. It can import modules and instantiate classes at runtime.

import importlib

class DynamicCalculatorLoader:
    def load_calculator(self, calculator_type):
        module = importlib.import_module(f"calculator_{calculator_type}")
        calculator_class = getattr(module, f"{calculator_type.capitalize()}Calculator")
        return calculator_class()

Highlights: No compilation needed, module cache via sys.modules, dynamic typing.

2. Java – Reflection and ClassLoader

Java leverages reflection and class loaders to load classes dynamically, even from external JARs.

URLClassLoader classLoader = new URLClassLoader(new URL[]{jarUrl});
Class<?> clazz = classLoader.loadClass("com.example.Calculator");
Calculator calculator = (Calculator) clazz.getDeclaredConstructor().newInstance();

Highlights: Bytecode loading, security sandbox, runtime inspection.

3. Rust – Dynamic Library Loading (`libloading`)

Rust uses the libloading crate to load dynamic libraries (.so, .dll, .dylib) and call functions via C ABI.

let lib = Library::new("libcalc.dylib")?;
let func: Symbol<unsafe extern fn() -> i32> = lib.get(b"addFn")?;

Highlights: Zero-cost abstractions, memory safety, system-level performance.

4. C++ – System Dynamic Library APIs

C++ uses platform APIs (dlopen/dlsym on Unix, LoadLibrary/GetProcAddress on Windows) for dynamic loading.

void* handle = dlopen("libcalculator.so", RTLD_LAZY);
auto addFn = (int(*)(int, int))dlsym(handle, "addFn");

Highlights: Low-level control, cross-platform, high performance.

5. C# – Reflection and Assembly Loading

C# uses reflection and Assembly.LoadFrom to load assemblies and create instances.

Assembly assembly = Assembly.LoadFrom("Calculator.dll");
Type type = assembly.GetType("Calculator.BasicCalculator");
object instance = Activator.CreateInstance(type);

Highlights: Managed code, rich metadata, automatic memory management.

6. Go – Interfaces and Reflection

Go doesn’t support traditional dynamic libraries, but achieves similar results via interfaces and factory patterns.

var calc calculator.Calculator = &calculator.BasicCalculator{}
result := calc.AddFn(a, b)

Highlights: Static typing, interface-based polymorphism, native concurrency.

7. Swift – Protocols and Type System

Swift uses protocols and type casting for dynamic invocation.

let calculators: [Calculator] = [BasicCalculator(), AdvancedCalculator()]
for calc in calculators {
    print(calc.addFn(a, b))
}

Highlights: Protocol-oriented, type safety, performance optimizations.

8. TypeScript – Dynamic `import()` and Factory Pattern

TypeScript uses ES6 dynamic import() and factory patterns for module loading.

const module = await import('./calculator');
const calculator = new module.BasicCalculator();

Highlights: Async loading, type safety, flexible module system.

9. Dart – Factory Pattern and Reflection

Dart uses factory constructors and reflection APIs for dynamic instantiation.

var calculator = CalculatorFactory.create('BasicCalculator');

Highlights: Event loop concurrency, JIT/AOT compilation, cross-platform.

10. Kotlin – Reflection API and Factory Pattern

Kotlin uses reflection and factory patterns, similar to Java but with more concise syntax.

val clazz = Class.forName("BasicCalculator").kotlin
val instance = clazz.createInstance() as Calculator

Highlights: Java interoperability, null safety, coroutine support.

Performance Comparison

Language	Load Speed	Memory	Type Safety	Learning Curve
C++	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
Rust	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐
Go	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
Java	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
C#	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Kotlin	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Swift	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
TypeScript	⭐⭐	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
Python	⭐⭐	⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Dart	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐

Best Practices

Interface Design: Define clear contracts.
Error Handling: Robust exception management.
Version Compatibility: Plan for backward compatibility.
Security: Validate module sources.
Performance Monitoring: Track load times and memory usage.

Conclusion

Dynamic loading is vital in modern software architecture. Each language offers unique mechanisms:

Low-level languages (C++, Rust): Maximum performance and control
Managed languages (Java, C#): Balance of usability and safety
Scripting languages (Python, JavaScript): Maximum flexibility
Modern languages (Go, Swift, Kotlin): Blend of traditional strengths

Choose the right approach based on your project’s needs, team expertise, and performance requirements.

References:

Project Source Code
Official documentation for each language
Best practices for dynamic loading

If you found this article helpful, follow for more deep dives into programming language internals and architecture!

A2A Protocol with Local LLMs: A Comprehensive Guide for Developers

Lu Han — Thu, 05 Jun 2025 19:05:58 +0000

Introduction

The Agent2Agent (A2A) Protocol is an open communication standard that enables AI agents built on different frameworks to communicate and collaborate effectively. While Google’s official examples rely on cloud services like Google AI Studio and Vertex AI, this guide demonstrates how to run the entire A2A ecosystem using local language models through Ollama and LM Studio, making it accessible to developers worldwide, especially those in regions with limited cloud access.

Today, I'm sharing my journey building a complete Agent-to-Agent (A2A) ecosystem where five different AI frameworks collaborate using local LLMs - no cloud APIs required!

🎯 What We're Building

This project demonstrates real cross-agent communication using:

Travel Agent (Semantic Kernel) - Orchestrates complex trip planning
Currency Agent (LangGraph) - Provides real-time currency conversion
YouTube Agent (AG2/AutoGen + MCP) - Extracts video content for research
Reimbursement Agent (Google ADK) - Handles expense workflows with forms
File Chat Agent (LlamaIndex) - Enables document conversations with file uploads

All powered by local LLMs (Ollama/LM Studio) and connected via A2A JSON-RPC protocol! 🔥

🛠️ Core Technologies

Local LLM Infrastructure

Ollama: Download from ollama.com
LM Studio: Download from lmstudio.ai

AI Frameworks Integration

Framework	Agent	Purpose	Port
LangGraph	Currency Agent	Real-time currency conversion	10000
AG2 (AutoGen)	YouTube Agent	Video transcript analysis	10010
Google ADK	Reimbursement Agent	Expense processing with forms	10020
Semantic Kernel	Travel Agent	Trip planning orchestration	10030
LlamaIndex	File Chat Agent	Document parsing & Q&A	10040

💻 Quick Start Guide

1. Setup Environment

# Create virtual environment
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate

# Install dependencies
pip install -r requirements.txt

2. Start Local LLM Service

# Option 1: Ollama
ollama serve

# Option 2: LM Studio
# Download and run LM Studio, load your preferred model

3. Launch Agents

# Currency Agent (LangGraph)
./start_remote_agent.sh langgraph --host localhost --port 10000 --llm-provider ollama --model-name qwen2.5:7b

# YouTube Agent (AG2 + MCP)
./start_remote_agent.sh ag2 --host localhost --port 10010 --llm-provider ollama --model-name qwen2.5:7b

# Travel Agent (Semantic Kernel)
./start_remote_agent.sh semantickernel --host localhost --port 10030 --llm-provider ollama --model-name qwen2.5:7b

# Reimbursement Agent (Google ADK)
./start_remote_agent.sh google_adk --host localhost --port 10020 --llm-provider ollama --model-name qwen2.5:7b

# File Chat Agent (LlamaIndex)
./start_remote_agent.sh llama_index_file_chat --host localhost --port 10040 --llm-provider ollama --model-name qwen2.5:7b

4. Start Host Interface

# Web UI Host
./start_host_agent.sh
# Visit http://localhost:12000

# Or CLI Host
./start_cli.sh --agent http://localhost:10000

🔧 A2A Protocol Implementation

Each agent exposes a standardized Agent Card via .well-known/agent.json:

{
  "name": "Currency Agent",
  "description": "Helps with exchange rates for currencies",
  "version": "1.0.0",
  "url": "http://localhost:10000/",
  "capabilities": {
    "pushNotifications": true,
    "streaming": true
  },
  "skills": [
    {
      "id": "convert_currency",
      "name": "Currency Exchange Rates Tool",
      "description": "Helps with exchange values between various currencies",
      "examples": ["What is exchange rate between USD and GBP?"],
      "tags": ["currency conversion", "currency exchange"]
    }
  ]
}

Communication happens via JSON-RPC 2.0:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "message/send",
  "params": {
    "sessionId": "test-session",
    "message": {
      "messageId": "msg-01",
      "role": "user",
      "parts": [{
        "type": "text",
        "text": "Convert 100 USD to CNY"
      }]
    }
  }
}

🎮 Real-World Demo: Multi-Agent Travel Planning

Here's where the magic happens! Let's see how agents collaborate:

# User request to Travel Agent
curl -X POST http://localhost:10030 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "message/send",
    "params": {
      "message": {
        "role": "user",
        "parts": [{
          "text": "Plan a 7-day Seoul trip with $5000 budget, include currency conversion"
        }]
      }
    }
  }'

What happens behind the scenes:

Travel Agent receives the request
Automatically calls Currency Agent to get USD→KRW exchange rate
Plans detailed itinerary with converted budget
Returns comprehensive travel plan with real currency data

Response:

# 📍 Seoul 7-Day Travel Plan

## 💰 Budget & Exchange Rate
- **Total Budget**: 5000 USD  
- **Current Rate**: 1 USD = 1376.78 KRW
- **Korean Won Budget**: ~6,883,900 KRW

## 🗓️ Detailed Itinerary
### Day 1: Arrival Seoul (Budget: 800,000 KRW)
- **Accommodation**: Myeongdong Hotel (120,000 KRW/night)
- **Transport**: Incheon Airport Express → Myeongdong (9,000 KRW)
- **Dinner**: Myeongdong street food (30,000 KRW)
...

🔥 Advanced Features

1. Multi-Framework Integration

Each agent uses its native framework:

LangGraph: Graph-based workflow for currency conversion
Semantic Kernel: Plugin architecture for travel planning
AG2 + MCP: Multi-agent collaboration with Model Context Protocol
Google ADK: Form-based workflows for reimbursements
LlamaIndex: RAG pipeline for document chat

2. Form-Based Interactions

The Reimbursement Agent demonstrates complex form workflows:

{
  "status": {
    "state": "input-required",
    "message": {
      "parts": [{
        "data": {
          "form": {
            "type": "object",
            "properties": {
              "date": {"type": "string", "format": "date"},
              "amount": {"type": "string", "format": "number"},
              "purpose": {"type": "string"}
            }
          },
          "form_data": {
            "amount": "500",
            "purpose": "Business trip transportation"
          }
        }
      }]
    }
  }
}

3. File Upload & Processing

File Chat Agent handles multiple formats:

{
  "parts": [
    {
      "type": "text",
      "text": "Analyze this document"
    },
    {
      "type": "file",
      "file": {
        "name": "report.pdf",
        "mimeType": "application/pdf",
        "bytes": "base64-encoded-content"
      }
    }
  ]
}

🎯 Key Benefits

🔒 Privacy First

100% Local: No data sent to cloud APIs
Your LLMs: Use any model you prefer
Full Control: Complete ownership of your AI pipeline

🧩 Framework Flexibility

Best of Both Worlds: Use each framework's strengths
Easy Integration: Standardized A2A protocol
Modular Design: Add/remove agents independently

🚀 Production Ready

Streaming Support: Real-time responses
Error Handling: Robust error recovery
Monitoring: Built-in logging and debugging

🔗 Resources & Links

🎉 Conclusion

Building a multi-agent AI ecosystem doesn't have to be complex. With the right architecture and standardized protocols, different AI frameworks can collaborate seamlessly.

The future of AI is collaborative - where specialized agents work together to solve complex problems. This project shows it's not just possible, but practical with today's tools!

Enjoy 👇

hello-a2a-python