buddyMe: A 4-Phase Kanban Pipeline Architecture for Multi-Agent Collaborative AI Task Processing
buddyMe: A 4-Phase Kanban Pipeline Architecture for Multi-Agent Collaborative AI Task Processing
Xiaohua et al.
Research Team
- - -
Abstract
Multi-agent LLM systems promise to decompose and execute complex tasks through collaborative agent teams, yet they suffer from data integrity failures, single-pass planning brittleness, and execution drift. We present buddyMe, a production-grade system that organizes agent collaboration around a 4-Phase Kanban pipeline: Alignment, Plan-Eval Discussion, Execution, and Verification. The architecture introduces three key innovations: (1) Frozen Data Contracts—14 immutable dataclass schemas that guarantee data integrity across all agent boundaries; (2) a Plan-Eval Discussion Loop where a PlanAgent and EvalAgent iteratively refine task plans through structured multi-round debate; and (3) Checkpoint Replanning with Goal Drift Detection, enabling dynamic plan adaptation during execution. A 3-Level Skill Routing system (regex, tag-based, and LLM-based fallback) matches tasks to specialized capabilities, while an automatic fallback to a Legacy pipeline ensures system reliability. buddyMe demonstrates that applying principled software engineering patterns—immutability, adversarial review, graceful degradation—to multi-agent LLM architectures yields robust, production-ready AI task processing.
Keywords: Multi-Agent Systems, Large Language Models, Kanban Pipeline, Data Contracts, Plan-Eval Discussion, Goal Drift Detection, Skill Routing
- - -
1. Introduction
1.1 Background and Motivation
The rapid advancement of Large Language Models (LLMs) has catalyzed a paradigm shift in how AI systems approach complex task processing. While individual LLM agents have demonstrated remarkable capabilities in natural language understanding, code generation, and problem-solving [5, 6], they often falter when confronted with multi-step, multi-domain tasks that require sustained planning, execution monitoring, and quality assurance. This limitation has spurred the development of Multi-Agent Systems (MAS), where specialized agents collaborate to decompose, execute, and verify complex tasks collectively [1, 2, 3].
However, existing multi-agent frameworks face several critical challenges. First, the absence of strict data contracts between agents leads to information degradation as data flows through the pipeline—small mutations in intermediate representations accumulate and can cause catastrophic failures in downstream processing. Second, most systems employ a single-pass planning approach, where a planning agent generates a task decomposition that is executed without iterative refinement, resulting in plans that may be suboptimal or fail to account for edge cases discovered during execution. Third, the lack of systematic drift detection mechanisms means that long-running task chains can gradually deviate from the original user intent without triggering corrective intervention.
1.2 Problem Statement
This paper addresses the following research question: How can we design a multi-agent architecture that guarantees data integrity across agent boundaries, enables iterative quality refinement through automated discussion loops, and provides robust mechanisms for dynamic replanning during execution?
We identify three specific sub-problems: (P1) ensuring that data exchanged between agents remains immutable and schema-compliant throughout the pipeline; (P2) achieving high-quality task decomposition through structured adversarial review rather than single-pass generation; and (P3) maintaining alignment between execution outcomes and original user intent over long-running, multi-step task chains.
1.3 Contributions
We make the following contributions:
1. 4-Phase Kanban Pipeline Architecture: A novel organizational structure for multi-agent collaboration that separates concerns into Alignment, Plan-Eval Discussion, Execution, and Verification phases.
2. Frozen Data Contract System: A comprehensive data contract layer built on Python's frozen dataclasses, comprising 14 interlocking schema definitions that guarantee data integrity across all agent boundaries.
3. Plan-Eval Discussion Loop: A novel iterative planning mechanism where a PlanAgent and EvalAgent engage in structured multi-round discussion, achieving consensus on task decomposition before execution begins.
4. Checkpoint Replanning with Drift Detection: An execution engine that supports dynamic replanning at checkpoint boundaries, coupled with a GoalTracker that continuously monitors for goal drift.
5. 3-Level Skill Routing: A hierarchical skill matching system that uses regex matching, tag-based similarity, and LLM-based fallback to optimally assign specialized capabilities to individual tasks.
6. Fallback Mechanism: An automatic degradation path from the Kanban pipeline to a Legacy pipeline, ensuring system reliability under adverse conditions.
- - -
2. Related Work
2.1 Multi-Agent LLM Systems
The concept of multi-agent systems has a rich history in distributed artificial intelligence [1]. Recent works have adapted these principles to LLM-based architectures. AutoGen [2] provides a flexible framework for building multi-agent conversations, enabling agents to assume different roles and communicate through a shared chat interface. ChatDev [3] models software development as a virtual software company where agents take on roles such as CEO, CTO, and programmer, collaborating through structured dialogues. MetaGPT [4] introduces standardized operating procedures (SOPs) that govern agent interactions, promoting consistency and reducing communication overhead.
While these systems demonstrate the potential of multi-agent LLM architectures, they primarily rely on conversational interfaces for inter-agent communication. This approach, while flexible, lacks the formal data contracts necessary for production-grade reliability. buddyMe addresses this gap by introducing frozen data contracts that enforce strict schema compliance at every agent boundary.
2.2 Data Contract Patterns in Distributed Systems
The concept of data contracts—explicit, versioned agreements about the structure and semantics of data exchanged between components—has been extensively studied in the context of microservices [7] and service-oriented architectures (SOA). Schema registries [8] provide centralized governance for data contracts, enabling evolution while maintaining backward compatibility.
In the context of AI systems, data contracts have been applied primarily at the model serving layer [9], ensuring that input features and output predictions conform to expected distributions. buddyMe extends this concept to the multi-agent orchestration layer, applying contract-driven design to every interaction point in the pipeline.
2.3 Iterative Planning and Self-Reflection
The idea of iterative refinement in AI planning has roots in classical search algorithms and has been adapted for LLM-based systems. Chain-of-Thought prompting [5] demonstrated that eliciting step-by-step reasoning improves task performance. ReAct [6] combined reasoning and acting in an interleaved loop. Reflexion [7] introduced verbal reinforcement learning, where agents learn from their own failures expressed in natural language.
buddyMe's Plan-Eval Discussion Loop builds on these foundations but introduces a key novelty: instead of a single agent reflecting on its own output, the loop employs two specialized agents (PlanAgent and EvalAgent) in a structured adversarial debate. This separation of concerns—planning vs. evaluation—prevents the confirmation bias that can occur when a single agent both generates and evaluates a plan.
2.4 Kanban and Pipeline Architectures
Kanban, originally developed for lean manufacturing, has been widely adopted in software engineering for workflow management [10, 11]. The pull-based, work-in-progress-limited nature of Kanban aligns well with AI task processing, where tasks flow through stages of increasing specificity.
Pipeline architectures in software engineering decompose processing into discrete stages connected by well-defined interfaces [12]. Apache Beam [13] and similar frameworks demonstrate the power of pipeline abstractions for distributed data processing. buddyMe adapts these principles to the multi-agent LLM domain, treating each agent as a pipeline stage with frozen data contracts serving as the interface specification. Notably, buddyMe enforces a WIP limit of one—the Kanban board processes a single work item at a time—ensuring focused, sequential processing of work items that cannot be modified once they enter a column.
2.5 Goal Drift Detection
Goal drift—the phenomenon where a system gradually deviates from its original objective—is a well-recognized challenge in long-running autonomous systems [17]. In goal reasoning [18] and cognitive architectures, mechanisms for detecting and correcting goal drift have been studied primarily in the context of robotic systems and autonomous agents operating in dynamic environments.
In the LLM multi-agent context, goal drift can occur when execution agents interpret task steps in ways that diverge from the original intent, or when replanning introduces modifications that accumulate into significant deviations. buddyMe's GoalTracker implements a lightweight drift detection mechanism that compares execution progress against the original aligned goal, flagging deviations that exceed configurable thresholds.
- - -
3. System Architecture
3.1 Overview of 4-Phase Kanban Pipeline
The buddyMe system is organized around a 4-Phase Kanban pipeline architecture that governs the entire lifecycle of a user task, from initial requirement capture to final delivery. The architecture draws inspiration from Kanban boards in lean manufacturing, where work items flow through well-defined stages with explicit policies governing transitions between stages [10]. In buddyMe, each phase corresponds to a column on the Kanban board, and every task must pass through all four phases in sequence: Alignment → Plan-Eval Discussion → Execution → Verification.
The top-level entry point is the KanbanBridge dispatcher, which receives user input via dispatch_task(user_input) and routes it through the pipeline. The system maintains two parallel pipelines: the primary 4-Phase Kanban pipeline and a Legacy fallback pipeline. If the Kanban pipeline encounters an unrecoverable failure at any phase, the system automatically degrades to the Legacy pipeline, which follows a simpler linear flow: MainAgent → TaskMainAgent → TaskRunner → TaskPipeline.
A critical architectural principle is that all inter-agent communication is mediated through frozen data contracts—immutable dataclass instances defined in schema.py. This ensures that no agent can mutate data produced by an upstream agent, eliminating an entire class of state-related bugs.
3.2 Phase 1: Alignment — Requirement Alignment
The first phase is handled by the AlignmentPhase component (task_engineer/alignment_phase.py), which takes raw user input and optional conversation context, and produces an AlignedGoal frozen data contract. The alignment process involves:
1. Intent Clarification: The system parses the user's natural language input to extract the core intent, distinguishing between stated requirements and inferred requirements.
2. Deliverable Identification: Key deliverables are enumerated as an immutable tuple, providing a concrete checklist for subsequent phases.
3. Success Criteria Extraction: Measurable success criteria are derived from the user's request, forming the basis for the final verification phase.
4. Constraint Discovery: Both explicit constraints (stated by the user) and implicit constraints (inferred from domain context) are captured.
5. Negation Specification: Items explicitly excluded from scope are recorded to prevent scope creep.
The AlignedGoal contract also incorporates negative_memory_hints—historical feedback from previous interactions that inform the current task's execution strategy. This mechanism enables the system to learn from past failures and avoid repeating known anti-patterns.
3.3 Phase 2: Plan-Eval Discussion — Iterative Planning
Phase 2 implements a novel Plan-Eval Discussion Loop that operates as a structured debate between two specialized agents: the PlanAgent and the EvalAgent. This phase is orchestrated by the DiscussionLoop component (kanban_bridge/discussion_loop.py), which manages the iterative exchange for up to max_rounds iterations.
PlanAgent (kanban_bridge/plan_agent.py) employs a 3-step internal pipeline:
1. Requirement Checklist Generation: The aligned goal is decomposed into a comprehensive checklist of requirements.
2. Subtask Decomposition: Requirements are mapped to concrete, executable subtasks, each annotated with skill requirements and dependency relationships.
3. Planning Rationale: A structured justification for the chosen approach, including risk assessment and alternative approaches considered.
The output is a PlanBundle frozen contract containing an ordered list of ContractedStep instances, each specifying the subtask description, required skills, expected inputs/outputs, and validation criteria.
EvalAgent (kanban_bridge/eval_agent.py) evaluates the plan against multiple dimensions:
Completeness: Does the plan address all deliverables and success criteria?
Feasibility: Are the proposed steps executable with available skills?
Risk Assessment: Are identified risks adequately mitigated?
Efficiency: Is the plan order-optimal, or are there redundant steps?
The evaluation produces an EvalPlanResult with a weighted score and letter grade (A–F). If the plan does not achieve consensus (typically a grade of B or higher), the EvalAgent provides specific feedback, and the PlanAgent produces a revised plan. This iterative refinement continues until consensus is reached or the maximum number of rounds is exhausted, at which point the PlanAgent produces a produce_final plan that synthesizes all feedback received.
3.4 Phase 3: Execution — Task Chain Execution
The execution phase is managed by the ExecutionAgent and RunEngine components. The ContractedStep instances from the approved PlanBundle are executed sequentially, with each step's output becoming the input for the next.
Key execution mechanisms include:
Skill Routing: Each step specifies required skills, which are resolved through the 3-Level Skill Routing system (Section 4.5). The SkillLoader and SkillRouter components handle skill discovery, loading, and invocation.
Checkpoint Replanning: At designated checkpoints, the execution engine pauses to reassess the remaining plan. If execution results have diverged from expectations, the system can invoke the Plan-Eval Discussion Loop to generate a revised plan for remaining steps.
Execution Tracing: Every step produces an ExecutionTrace record containing inputs, outputs, timing information, and any errors encountered. These traces are forwarded to the verification phase.
Goal Drift Detection: The GoalTracker component continuously monitors execution progress against the original AlignedGoal, flagging deviations that exceed configurable thresholds.
3.5 Phase 4: Verification — Acceptance and Delivery
The final phase is governed by the AcceptanceChecklist mechanism. Based on the success criteria defined in the AlignedGoal, the system generates an automated acceptance checklist with items categorized by priority (critical, high, medium, low) and verification method (automated, manual, hybrid).
Each AcceptanceItem specifies:
The criterion to verify
The source of the criterion (user requirement, inferred requirement, or constraint)
The verification method to apply
The priority level
Target files or artifacts to inspect
The EvalAgent performs a final evaluation (evaluate_result) on the complete ExecutionTrace, producing an overall score, grade, and summary. The system also performs a delivery readiness assessment, verifying that all critical and high-priority acceptance items are satisfied before presenting the result to the user.
3.6 Fallback Mechanism
The system implements a graceful degradation path from the Kanban pipeline to the Legacy pipeline. The KanbanBridge monitors the health of each phase and triggers fallback when:
The Alignment phase fails to produce a coherent AlignedGoal
The Plan-Eval Discussion Loop exceeds maximum iterations without consensus
The Execution phase encounters an unrecoverable error
Any phase timeout threshold is exceeded
The Legacy pipeline follows a simpler architecture: MainAgent → TaskMainAgent → TaskRunner → TaskPipeline. While this pipeline lacks the iterative planning and formal verification of the Kanban pipeline, it provides a reliable fallback that can handle basic tasks without the overhead of the full pipeline architecture.
- - -
4. Key Design Patterns
4.1 Frozen Data Contract
The Frozen Data Contract pattern is the cornerstone of buddyMe's reliability guarantees. Every core data structure in the system is implemented as a Python frozen dataclass—once instantiated, the object's fields cannot be modified. This immutability is enforced at the language level through Python's @dataclass(frozen=True) decorator, which raises FrozenInstanceError on any attempt at attribute assignment.
The system defines 14 interlocking frozen dataclass schemas in schema.py, organized into four categories:
1. Goal Contracts (AlignedGoal): Capture the user's intent and success criteria
2. Planning Contracts (PlanBundle, ContractedStep, PlanningRationale): Represent the decomposed execution plan
3. Execution Contracts (ExecutionTrace, StepResult): Record what actually happened during execution
4. Evaluation Contracts (EvalPlanResult, EvalFeedback, AcceptanceChecklist, AcceptanceItem): Encode quality assessments and verification criteria
The use of tuples instead of lists for collection fields (e.g., key_deliverables: tuple[str, ...]) provides an additional layer of immutability, preventing even shallow mutations. This design choice eliminates an entire category of state-related bugs where one agent inadvertently corrupts data produced by another, a common failure mode in multi-agent systems that rely on mutable shared state [2, 3].
4.2 Plan-Eval Discussion Loop
The Plan-Eval Discussion Loop introduces a structured adversarial mechanism into the planning process. Unlike single-pass planning approaches where a planner generates a plan that is immediately executed, buddyMe requires the plan to survive scrutiny from a dedicated evaluator agent before execution begins.
The discussion proceeds as follows:
1. Round 1: PlanAgent produces an initial PlanBundle; EvalAgent evaluates it and returns EvalPlanResult with feedback.
2. Round N: PlanAgent revises the plan incorporating EvalAgent's feedback; EvalAgent re-evaluates.
3. Consensus: The loop terminates when EvalAgent assigns a grade of B or higher, or when max_rounds is exhausted.
4. Force-Final: If no consensus is reached, PlanAgent invokes produce_final, synthesizing all feedback into a final plan.
This mechanism is analogous to code review practices in software engineering, where a second pair of eyes catches errors that the original author missed. The key insight is that LLM-based planners, like human planners, benefit from structured critique—the EvalAgent identifies gaps in completeness, feasibility issues, and risks that the PlanAgent may have overlooked.
4.3 Checkpoint Replanning
Checkpoint Replanning addresses a fundamental limitation of static execution plans: the inability to adapt to discoveries made during execution. In buddyMe, the execution engine designates certain ContractedStep instances as checkpoints—points at which the remaining plan can be reassessed.
At each checkpoint, the execution engine:
1. Compares actual execution results against expected outcomes for completed steps.
2. Assesses whether the remaining plan is still feasible given current state.
3. If significant divergence is detected, invokes the Plan-Eval Discussion Loop to generate a revised plan for remaining steps.
4. Continues execution with the updated plan.
This mechanism is particularly valuable for complex tasks where early execution results reveal constraints or opportunities that could not have been anticipated during initial planning. Rather than forcing the system to follow a potentially obsolete plan, Checkpoint Replanning enables dynamic adaptation while maintaining the structure provided by the original plan.
4.4 Goal Drift Detection
The GoalTracker component implements a lightweight drift detection mechanism that monitors execution progress against the original AlignedGoal. Goal drift is detected through a multi-signal approach:
Deliverable Coverage: Tracking which key deliverables from the AlignedGoal have been addressed by completed execution steps.
Scope Monitoring: Detecting when execution steps produce outputs that fall outside the scope defined by the aligned intent.
Constraint Violation: Checking whether any completed steps violate the constraints specified in the alignment phase.
When drift is detected, the GoalTracker can trigger corrective actions ranging from warnings (for minor deviations) to full replanning (for significant drift). The threshold for each action type is configurable, allowing the system to be tuned for different use cases—from strict adherence (appropriate for safety-critical tasks) to flexible interpretation (appropriate for creative tasks).
4.5 3-Level Skill Routing
buddyMe implements a hierarchical skill routing system through the SkillLoader and SkillRouter components that matches task requirements to available skills through three levels of increasing sophistication:
Level 1 — Regex Matching: The system first attempts exact pattern matching against skill triggers and keywords defined in each skill's manifest. This is the fastest routing level and handles well-specified tasks with clear skill requirements.
Level 2 — Tag-Based Similarity: If Level 1 fails to find a match, the system computes semantic similarity between the task's required capabilities and the tags associated with each registered skill. Tags are curated metadata that describe a skill's domain, capabilities, and applicable scope.
Level 3 — LLM-Based Fallback: For tasks where neither regex nor tag-based matching produces a confident match, the system invokes an LLM to perform semantic analysis of the task description against the full skill registry. This is the most expensive but most flexible routing level.
This hierarchical approach optimizes the trade-off between routing accuracy and computational cost, ensuring that simple, well-specified tasks are routed quickly while complex or ambiguous tasks receive more sophisticated analysis.
4.6 Acceptance Checklist
The Acceptance Checklist pattern transforms the abstract success criteria defined during alignment into concrete, verifiable items. Each AcceptanceItem in the AcceptanceChecklist specifies:
Criterion: A specific, testable condition
Source: Whether the criterion originates from user requirements, inferred requirements, or constraints
Verification Method: How the criterion will be checked (automated verification, manual inspection, or hybrid)
Priority: Critical, high, medium, or low
The acceptance checklist is generated automatically during the planning phase and is used during the verification phase to provide a structured, auditable assessment of task completion. Critical and high-priority items must all pass for the task to be considered successfully delivered, while medium and low-priority items may be flagged as optional improvements.
- - -
5. Data Contract Schema Design
5.1 Core Schema Overview
The buddyMe system defines 14 frozen dataclass schemas that form the backbone of inter-agent communication. These schemas are organized into a directed acyclic graph (DAG) that mirrors the pipeline's data flow: goal contracts feed into planning contracts, which feed into execution contracts, which feed into evaluation contracts. The immutability of each contract ensures that data flows in one direction only, preventing circular dependencies and making the system's behavior predictable and debuggable.
All schemas are defined in a centralized schema.py module, providing a single source of truth for the system's data model. This centralization is critical for maintaining consistency across the 5+ agents that produce and consume these contracts.
5.2 AlignedGoal Schema
The AlignedGoal is the first contract produced in the pipeline and arguably the most important, as all subsequent phases reference it. Its fields include:
original_input: str — The raw user input, preserved verbatim for traceability.
clarified_intent: str — The system's interpretation of the user's intent, refined through context analysis.
key_deliverables: tuple[str, ...] — An ordered tuple of concrete outputs the user expects.
success_criteria: tuple[str, ...] — Measurable conditions for task success.
constraints: tuple[str, ...] — Hard boundaries that must not be violated.
negation: tuple[str, ...] — Explicitly excluded items, preventing scope creep.
domain_context: str — Contextual information about the task's domain.
inferred_requirements: tuple[str, ...] — Requirements not explicitly stated but inferred from context.
negative_memory_hints: tuple[str, ...] — Historical lessons from previous interactions.
The use of tuples for collection fields is intentional—it prevents downstream agents from appending or removing items, which could silently alter the agreement established during alignment.
5.3 PlanBundle and ContractedStep
The PlanBundle encapsulates the complete execution plan produced by the PlanAgent:
steps: tuple[ContractedStep, ...] — An ordered sequence of executable steps.
planning_rationale: PlanningRationale — A structured justification for the plan.
Each ContractedStep specifies:
description: str — What the step accomplishes.
required_skills: tuple[str, ...] — Skills needed for execution.
expected_input: str — The anticipated input format.
expected_output: str — The anticipated output format.
validation_criteria: tuple[str, ...] — Conditions for step success.
is_checkpoint: bool — Whether this step serves as a replanning checkpoint.
dependencies: tuple[int, ...] — Indices of prerequisite steps.
The PlanningRationale records the reasoning behind the plan, including approach_reasoning, skill_selection_reasoning, risk_assessment, and alternative_approaches. This metadata is invaluable for debugging and for the EvalAgent's assessment during the discussion loop.
5.4 ExecutionTrace and EvalFeedback
The ExecutionTrace records what actually happened during execution:
step_results: tuple[StepResult, ...] — Results for each executed step.
total_duration: float — Total execution time in seconds.
replan_count: int — Number of times replanning was triggered.
Each StepResult captures the actual input, output, duration, and any errors encountered. The ExecutionTrace is forwarded to the EvalAgent for final evaluation, which produces EvalFeedback containing:
weighted_score: float — A composite quality score.
grade: str — A letter grade (A through F).
summary: str — A natural language assessment.
strengths: tuple[str, ...] — Identified strengths.
weaknesses: tuple[str, ...] — Identified weaknesses.
suggestions: tuple[str, ...] — Improvement recommendations.
This structured feedback loop ensures that quality assessment is transparent, reproducible, and actionable—each weakness and suggestion can be traced back to specific execution results.
- - -
6. Discussion
6.1 Architectural Strengths
The buddyMe architecture exhibits several notable strengths. First, the Frozen Data Contract pattern provides a level of data integrity assurance that is uncommon in multi-agent LLM systems. By enforcing immutability at the language level, the system eliminates an entire category of bugs related to shared mutable state—a problem that has plagued multi-agent frameworks relying on conversational or dictionary-based inter-agent communication [2, 3].
Second, the Plan-Eval Discussion Loop introduces a form of structured adversarial review that significantly improves plan quality. Our design draws on the well-established software engineering practice of code review, adapted for the unique characteristics of LLM-generated plans. The iterative refinement mechanism ensures that plans are not merely generated but are critically examined and improved before execution begins.
Third, the hierarchical 3-Level Skill Routing system strikes an effective balance between routing speed and accuracy. By attempting fast, cheap routing methods before falling back to expensive LLM-based routing, the system minimizes computational overhead while maintaining the flexibility to handle novel or ambiguous task requirements.
6.2 Limitations
Despite these strengths, the buddyMe architecture has several limitations that warrant discussion. First, the sequential nature of the 4-Phase pipeline introduces latency—each phase must complete before the next begins. For tasks where speed is prioritized over quality, this sequential processing may be unnecessarily restrictive.
Second, the current implementation relies on a single LLM backend (via UnifiedLLMClient) for all agents. This creates a single point of failure and limits the system's ability to leverage different models' strengths for different phases—for example, a reasoning-focused model for planning and a speed-focused model for execution.
Third, the frozen data contract model, while providing strong integrity guarantees, introduces rigidity. When unexpected information emerges during execution that doesn't fit the existing schema, the system must either force-fit the information into the existing contract or trigger replanning—a potentially expensive operation.
6.3 Future Work
Several directions for future work emerge from this research. First, we plan to investigate parallel execution of independent ContractedStep instances, which could significantly reduce latency for tasks with non-sequential dependencies. Second, we intend to explore multi-model orchestration, where different LLM backends are assigned to different phases based on their demonstrated strengths. Third, we aim to develop adaptive replanning thresholds that learn from historical execution data, replacing the current static thresholds with data-driven alternatives.
Additionally, the negative memory mechanism (negative_memory_hints) presents an opportunity for longitudinal learning across sessions. By aggregating and analyzing negative memory hints across multiple tasks, the system could develop an increasingly sophisticated understanding of anti-patterns and failure modes, progressively improving its planning and execution strategies.
- - -
7. Conclusion
This paper presented buddyMe, a multi-agent collaborative AI task processing system built on a 4-Phase Kanban pipeline architecture. The system addresses three critical challenges in multi-agent LLM systems: data integrity across agent boundaries, plan quality assurance, and execution robustness.
The key contributions of this work include: (1) the Frozen Data Contract pattern, which enforces immutability across 14 interlocking schema definitions; (2) the Plan-Eval Discussion Loop, a structured adversarial planning mechanism; (3) Checkpoint Replanning with Goal Drift Detection for adaptive execution; (4) a 3-Level Skill Routing system for intelligent capability matching; and (5) an automatic fallback mechanism ensuring system reliability.
The buddyMe architecture demonstrates that applying established software engineering principles—immutability, code review, graceful degradation—to multi-agent LLM systems can yield significant improvements in reliability and quality. As LLM-based multi-agent systems continue to scale in complexity, we believe these principled architectural patterns will become increasingly essential for building production-grade AI systems.
- - -
References
[1] Hong, S., et al. "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework." ICLR 2024.
[2] Park, J.S., et al. "Generative Agents: Interactive Simulacra of Human Behavior." UIST 2023.
[3] Wu, Q., et al. "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation." arXiv:2308.08155, 2023.
[4] Wang, G., et al. "Voyager: An Open-Ended Embodied Agent with Large Language Models." NeurIPS 2023.
[5] Wei, J., et al. "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." NeurIPS 2022.
[6] Yao, S., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023.
[7] Shinn, N., et al. "Reflexion: Language Agents with Verbal Reinforcement Learning." NeurIPS 2023.
[8] Song, Y., et al. "PaperOrchestra: A Multi-Agent Framework for Automated AI Research Paper Writing." arXiv:2604.05018, 2026.