AI-Powered Damaged Baggage Compensation: Building Multi-Agent Workflows with KaibanJS, A2A, and MCP

Automating baggage damage claims with policy-backed compensation offers, real-time market prices, and the Kaiban platform

---

Introduction

Baggage damage is one of the biggest sources of passenger frustration in air travel. The U.S. Department of Transportation reported that the top 10 U.S. airlines mishandled nearly 245,000 bags in January 2025. At an estimated $100+ per damaged bag in compensation, these claims cost carriers millions of dollars every month, and today most are still handled manually by airport staff or third-party vendors, leading to inconsistent payouts, slow resolution, and unnecessary escalations.

This article shows how to build a multi-agent system that automates damaged baggage compensation using KaibanJS (open-source multi-agent framework), the Kaiban.io platform (enterprise workflow and agent orchestration for airlines), the A2A (Agent-to-Agent) protocol, and the Kaiban MCP (Model Context Protocol) server. The result is an implementation that delivers instant, policy-backed compensation offers using airline rules, historical payouts, and real-time product market prices via Tavily, giving staff a clear, defensible offer to communicate to passengers while keeping full auditability on the Kaiban board.

We’ll walk through the use case, the architecture, how MCP differs from using the Kaiban SDK, and the concrete implementation so you can adapt it or extend it for your own airline or travel workflows.

---

The Use Case: Why Damaged Baggage Compensation Matters

The use case is inspired by Kaiban’s “AI Agent for Airlines: Automated Damaged Baggage Compensation”. In practice, airlines face:

• Highly variable compensation – Each case is handled differently; offers often reflect emotion, negotiation, or subjective judgment instead of policy, leading to inconsistency and poor communication.
• No centralized audit trail – Claims arrive via email, forms, and face-to-face. There’s no single place to see how decisions were made, which increases fraud risk and limits process improvement.
• Lack of tools – Policies exist, but agents don’t have reliable, data-backed guidance for baggage valuation, depreciation, or replacement costs.
• Escalations to customer care – Dissatisfied passengers escalate; customer service often pays more to resolve quickly, which raises costs and undermines consistency.

The goal is to automate the flow so that:

1. A claim is submitted (e.g. via web portal, kiosk, or staff creating a card on Kaiban).
2. An AI agent validates the claim and pulls in policy, historical payouts, and real-time market prices for damaged items.
3. A fair, policy-compliant compensation offer is generated and written back to the card.
4. Staff get a clear offer to communicate; if accepted, payment can be triggered; disputes can be escalated with full context.

Our implementation demonstrates this with a KaibanJS team that uses Kaiban MCP for card lifecycle (no Kaiban SDK in the agent code) and Tavily for real-time product prices (up to 5 items per claim).

---

Kaiban.io and KaibanJS: Platforms and Open-Source Tools

Kaiban.io – Enterprise Agent Orchestration for Airlines

Kaiban.io is an enterprise workflow and agent orchestration platform with a strong focus on the airline vertical. It provides:

• Visual Kanban boards – Real-time visibility into agent work; each claim or work item is a card that moves through columns (e.g. todo → doing → done → blocked).
• Card-based workflow – Cards carry context (title, description, result, activities), so both humans and agents can see history and outcomes.
• A2A (Agent-to-Agent) protocol – Standardized way for the platform to send “something happened” events (e.g. card created, card moved to todo) to your agent endpoint.
• MCP server – A Model Context Protocol server that exposes Kaiban operations (get card, move card, update card, create activities) as tools. Agents call these tools instead of using a vendor SDK.

The platform is SDK-agnostic: you can build agents with KaibanJS, LangChain, CrewAI, Mastra, or any framework that can speak A2A and call MCP tools.

KaibanJS – Open-Source Multi-Agent Framework

KaibanJS is an open-source framework for building multi-agent AI systems. You define:

• Agents – Specialized actors with roles, goals, and optional tools (APIs, MCP tools, etc.).
• Tasks – Concrete steps with inputs, expected outputs, and output schemas (e.g. Zod).
• Teams – Orchestration of agents and tasks (e.g. sequential flow) with shared context.

KaibanJS fits well with LLM-based tool use: agents get tools (including those from MCP), and the framework handles task sequencing, passing outputs between tasks, and validation. The damaged baggage compensation example in the kaiban-agents-starter repo shows a full integration with the Kaiban platform via A2A and MCP.

---

Integration: A2A Protocol and Kaiban MCP

A2A – How the Platform Talks to Your Agent

When a card is created or moved on a Kaiban board, the platform can send an A2A message to your agent endpoint. The message includes Kaiban activity data, for example:

• card_id, board_id, team_id
• Activity type, actor, and any field changes

Your A2A executor (we use @a2a-js/sdk and @kaiban/sdk for the activity part) parses this, validates the card (e.g. has description, is in todo), and then starts your KaibanJS team with that context. So “card created in todo” or “card moved to todo” becomes the trigger for “run the damaged baggage compensation pipeline for this card.”

MCP – Tools Instead of SDK

The Kaiban MCP Server exposes platform operations as MCP tools. In our example, agents never call the @kaiban/sdk directly; they only use:

• get_card – Fetch card by card_id (e.g. get description = claim text).
• move_card – Move card to a column (todo, doing, done, blocked).
• update_card – Update card fields (e.g. write the compensation offer into the card result).
• create_card_activities – Log what happened (e.g. “moved to doing”, “moved to done”) for audit.

So card lifecycle is entirely tool-driven: the “Kaiban Card Sync” agent uses these MCP tools in Task 0 (get card, move to doing) and Task 4 (update card with offer, move to done). The executor also uses MCP (via a small client wrapper) to validate the card and, on team failure, to move the card to blocked and log activities.

This MCP-first design is ideal when you want:

• A tool-based agent that naturally fits LLM tool-calling.
• Schema discovery from the MCP server (e.g. JSON Schema → Zod) so the model gets correct parameter definitions.
• One protocol (MCP) for both “platform” and “external data” tools (e.g. Tavily), instead of mixing SDK calls and tool calls.

---

Architecture: Damaged Baggage Compensation Team

The implementation is a sequential team with 5 tasks and 4 agents.

End-to-End Flow

1. Kaiban sends A2A activity (e.g. card created/moved to todo)
         ↓
2. Executor validates card via MCP get_card (description present, column = todo)
         ↓
3. Task 0 – Kaiban Card Sync Agent: get_card → extract description → move_card to "doing" → output userMessage (claim text)
         ↓
4. Task 1 – Claim Extraction & Validation Agent: parse claim, validate required fields (passenger, items, damage description)
         ↓
5. Task 2 – Compensation Calculation Agent: get_airline_policy, get_historical_payouts, search_product_market_price (Tavily, max 5 products) → apply policy → output amount + breakdown
         ↓
6. Task 3 – Compensation Offer Agent: produce final offer text (or “request missing info” note)
         ↓
7. Task 4 – Kaiban Card Sync Agent: update_card with offer → move_card to "done" → create_card_activities

If the team throws at any step, the executor catches, calls MCP move_card to blocked and create_card_activities, so the card is visible for manual review and nothing is lost.

Agents and Tools

• Policy and historical – Implemented as mock tools (get_airline_policy, get_historical_payouts) returning depreciation rules, caps, and historical payouts by damage type/category. In production these would call your real policy and analytics APIs.
• Real-time prices – Tavily via search_product_market_price: one call per product, max 5 products per claim, so the agent can ground compensation in current market values and keep the process defensible and auditable.

---

Implementation Highlights

Kaiban MCP Client (Streamable HTTP)

The client uses @modelcontextprotocol/sdk with Streamable HTTP transport and connects to the Kaiban MCP URL (e.g. https://<tenant>-<env>.kaiban.io/mcps/kaiban/mcp) with a Bearer token. It lists tools from the server and converts each tool’s JSON Schema input to a Zod schema so KaibanJS agents get typed, validated parameters:

export async function getKaibanTools(): Promise<KaibanJSTool[]> {
  const client = await getMcpClient();
  const { tools: mcpTools } = await client.listTools();
  return mcpTools.map((t) => {
    const schema = inputSchemaToZod(t.inputSchema, t.name);
    return {
      name: t.name,
      description: t.description ?? `MCP tool: ${t.name}`,
      schema,
      async invoke(input: Record<string, unknown>): Promise<string> {
        const result = await client.callTool({ name: t.name, arguments: input });
        return stringifyToolContent(result.content);
      },
    };
  });
}

The same client exposes getCard and moveCardToBlocked used by the executor (implemented via MCP callTool under the hood).

Compensation Tools: Policy, Historical, and Tavily

The Compensation Calculation Agent uses three tools:

1. get_airline_policy – No args; returns depreciation (e.g. 20% year 1, 15% year 2, 10% thereafter, max 70%), max per item (e.g. $500), max per claim (e.g. $1500), currency.
2. get_historical_payouts – Optional damageType and productCategory; returns historical average payouts for reference.
3. search_product_market_price – Tavily: one call per product (e.g. “Samsonite 28 inch spinner current price buy USD”). The task description tells the agent to call it for each damaged item, up to 5 items. If TAVILY_API_KEY is missing, the tool returns a mock value so the pipeline still runs.

These are implemented as LangChain DynamicStructuredTool with Zod schemas so they’re compatible with KaibanJS’s tool layer. The agent is instructed to call policy first, then historical payouts, then Tavily for each item; then apply depreciation and caps and output a breakdown.

Task 0 and Task 4 – Card Lifecycle via MCP

Task 0 tells the Kaiban Card Sync Agent to: call get_card, read description (claim text), if column is todo call move_card to doing with the actor, optionally create_card_activities, and return { userMessage: description }. Task 4 takes the final offer text, calls update_card to set the card result, move_card to done, and create_card_activities. So the whole card lifecycle is explicit in natural language and MCP tool calls, no SDK in the agent logic.

Error Handling: Move to Blocked

On any team failure, the executor calls the MCP client’s moveCardToBlocked, which:

1. Calls MCP move_card with column_key: "blocked".
2. Calls MCP create_card_activities with status/column change so the board shows why the card is blocked.

So failed claims don’t disappear; they land in a column where staff can review and retry or handle manually.

---

MCP vs SDK: Two Ways to Integrate with Kaiban

The Kaiban MCP reference and the KaibanJS damaged baggage example page describe two integration styles:

In the damaged baggage example, all Kaiban interaction goes through MCP: the executor uses a thin wrapper that calls MCP under the hood, and the two tasks that touch cards use the same MCP tools as the rest of the agent’s tool set. That keeps the mental model simple for LLM-based agents and aligns with how many practitioners already use MCP for data and APIs.

---

Configuration and Running the Example

Environment

• KAIBAN_MCP_URL – Optional; default can be built from KAIBAN_TENANT and KAIBAN_ENVIRONMENT (e.g. https://<tenant>-dev.kaiban.io/mcps/kaiban/mcp).
• KAIBAN_API_TOKEN – Required for MCP (Bearer).
• OPENAI_API_KEY – For KaibanJS LLM calls.
• TAVILY_API_KEY – For real-time product price search (optional; if missing, a mock value is used).
• A2A_BASE_URL – Public URL of your agent (e.g. for agent card and webhooks).
• KAIBAN_AGENT_ID or KAIBAN_DAMAGED_BAGGAGE_COMPENSATION_AGENT_ID – So the executor can ignore activities triggered by this agent and pass the correct actor to MCP.

Register the Agent on Kaiban

Register the agent in the Kaiban platform using:

• Agent card URL: GET /damagedBaggageCompensation/a2a/.well-known/agent-card.json
• Agent URL: POST /damagedBaggageCompensation/a2a

Then assign the agent to a board. When you create cards with a description (the claim text) in the todo column, the platform sends an A2A activity; your executor runs the team and the card moves doing → done (or blocked on error). A sample claim is available at GET /damagedBaggageCompensation/samples/baggage-claim-example.txt.

Tests

The repo includes tests that mock Kaiban MCP, Tavily, and KaibanJS so you can run them without real API keys or a live Kaiban tenant.

---

Why This Matters for ML and AI Practitioners

• Reproducibility – Open-source stack (KaibanJS, MCP, A2A) and a clear split between policy/historical (mock) and real-time data (Tavily) make it easy to replicate and extend.
• Tool use and real-world data – Combining LLM tool-calling with real-time search (Tavily) and structured policy shows a pattern you can reuse for other domains (e.g. insurance, warranty, returns).
• Observability and control – Every decision is reflected on the Kaiban board (card state, activities); failed runs go to blocked with a clear trail.
• MCP as a single integration surface – One protocol for “platform” (cards, boards) and “data” (Tavily) simplifies agent design and keeps the codebase consistent.

---

Conclusion

Automating damaged baggage compensation with KaibanJS, the Kaiban.io platform, A2A, and Kaiban MCP gives you:

• Instant, policy-backed offers – Policy + historical payouts + real-time market prices (Tavily, up to 5 items per claim).
• Full card lifecycle via MCP – No Kaiban SDK in the agent; get/move/update card and log activities through MCP tools.
• Clear separation – Extraction → validation → calculation (with tools) → offer text → write back to card; errors move the card to blocked for manual review.

You can clone the kaiban-agents-starter repo, open examples/damaged-baggage-compensation-mcp-kaibanjs, configure env vars, register the agent on Kaiban, and run the flow end-to-end. From there, you can swap mocks for real policy and analytics APIs, add more tools, or reuse the same MCP + A2A pattern for other airline or travel workflows.

---

Resources

• Use case: AI-Powered Automated Damaged Baggage Compensation for Airlines (Kaiban)
• Example and docs: Damaged Baggage Compensation with Kaiban MCP (KaibanJS)
• Kaiban MCP reference: Kaiban MCP Server Reference (docs.kaiban.io)
• Code: kaiban-agents-starter – damaged-baggage-compensation-mcp-kaibanjs
• MCP specification: modelcontextprotocol.io

---

Next Steps

1. Run the example – Clone the repo, set env vars, register the agent, create a card with a claim in the description, and watch it move to done (or blocked).
2. Replace mocks – Plug in real airline policy and historical payout APIs for get_airline_policy and get_historical_payouts.
3. Tune Tavily usage – Adjust product description formatting or add more structured parsing from Tavily results for your baggage categories.
4. Reuse the pattern – Use the same MCP + A2A + multi-task team structure for lost baggage, delays, or other claim types.
5. Compare with SDK – Try the revenue management or other SDK-based examples to see when you prefer controller + SDK vs. tool-only MCP.