Experience Pack (XP) Architecture

• Experience Pack (XP) is a structured memory subsystem that captures, validates, and recycles experience fragments using WHY, HOW, and CHECK protocols.
• The architecture employs layered memory (STM, EM, LTM) and protocol-driven inter-agent coordination to enable continual learning and efficient task decomposition.
• Empirical results demonstrate reduced LLM calls and faster planning through high fragment reuse rates, boosting operational efficiency and scalability.

The Experience Pack (XP) architecture in GoalfyMax constitutes a layered, protocol-driven memory subsystem dedicated to capturing, validating, and operationalizing structured experience fragments across multi-agent workstreams. The XP mechanism encodes both the underlying rationale (“WHY”) and the procedural methodology (“HOW”) of task-solving episodes, imparts robust memory reuse and continual learning, and integrates safety-centric validation at multiple transit points. This facilitates efficient collaboration and planning in autonomous agent collectives managing complex, open-ended enterprise tasks (Wu et al., 13 Jul 2025).

1. Design Objectives and Core Concepts

The XP architecture is intended as GoalfyMax’s structured memory backbone, engineered to collect, assess, and recycle experience fragments emerging from user–agent interactions. Its stated purposes are:

• Continual Learning: Experience accumulation over extended timeframes to curtail redundant user prompts and agent queries.
• Task Decomposition: Retention and exposure of subtask rationales and plans to enable on-the-fly assembly of new strategies.
• Inter-Agent Coordination: Shared, queryable repository for solution fragments, accessible across independent autonomous entities.
• Safety and Trust Propagation: Rigorous fragment validation and ongoing trust score maintenance to enforce safe operational memory (Wu et al., 13 Jul 2025).

2. Layered Memory Organization

XP memory in GoalfyMax is structured into three principal layers, each tied to both data structure and storage backend:

Layer	Primary Scope	Data Structure & Storage
Short-Term Memory (STM)	Dialogue state and recent execution steps	In-RAM circular buffer (deque)
Episodic Memory (EM)	Completed session rationales and execution logs	Document store (MongoDB/SQLite)
Long-Term Memory (LTM)	Generalized, trusted, reused experiences	Vector DB (FAISS/PGVector) + meta

2.1 Short-Term Memory (STM)

STM maintains the current multi-turn dialogue state and most recent execution steps in an in-process, size-trimmed Python deque of tuples: $$(\text{turn\_id}, \text{user\_input}, \text{agent\_response}, \text{step\_trace}, \text{errors})$$ It serves as a high-throughput transient buffer, limited to $K=50$ turns by default.

2.2 Episodic Memory (EM)

EM captures entirety of individual task-oriented episodes. Its structure consists of:

• WHY fragment:

$(G, C, T_c)$ $G$ = goal string, $C$ = list of constraint clauses, $T_c$ = contextual metadata (e.g., timestamp, user ID)

• HOW fragment:

$$[s_1, s_2, \ldots, s_n] \text{ with each } s_i \in \text{AtomicActions}$$

• CHECK fragment:

$\text{Check}(F) = \land r_i(F)$ Conjunctive validations upon the HOW steps.

• Parameterized Procedures:

$P = \{ (e_i, p_i) \}$ EM is stored in a queryable JSON/NoSQL document store, indexed by tags, embeddings, and trust.

2.3 Long-Term Memory (LTM)

LTM comprises highly trusted and frequently reused fragments—only those with trust$> \tau$ and usage_count$> \mu$—mirroring EM schema. LTM supports large-scale, embedding-based similarity queries via a vector database (FAISS/PGVector) and maintains metadata tables for fast eligibility lookups.

3. Inter-Agent Protocols and Communication Mechanisms

3.1 Model Context Protocol (MCP)

The MCP provides agents with standardized access routines for XP:

• Retrieval of candidate HOW steps,
• Execution of validation functions $\text{Check}(F)$,
• Trust score updates and dynamic safety gatekeeping.

MCP operates over JSON-RPC and is tightly integrated into agent core logic.

3.2 Agent-to-Agent (A2A) Layer

The A2A layer governs all XP-related inter-agent dataflow using a structured message schema:

{ "msg_type": "xp_query" | "xp_update", "agent_id": "...", "payload": { ...WHY..., ...HOW..., ...tags..., "query_text": "...", "trust_delta": +0.1 } }

The typical transactional pipeline is:

1. SchedulerAgent completes planning $\to$ xp_update(WHY, HOW)
2. ExecutorAgent pushes execution traces $\to$ xp_update(HOW, CHECK)
3. ExperienceAgent evaluates trust; migrates to LTM if threshold met
4. Any agent issues xp_query for fragments (e.g., “How to validate web elements?”), routed by A2A to XP store; top-K matching fragments are returned.

4. Mathematical Framework

4.1 Experience Embedding and Retrieval

• Encoding: Each fragment $x$ is embedded as:

$$E(x) = \text{LMEmbed}(\text{serialize}(x)) \in \mathbb{R}^d$$

• Retrieval: Given query $q$,

$$R(q) = \text{TopK}\{E_i : \cos(E(q), E_i)\}_{i=1}^K$$

4.2 Memory Consolidation and Forgetting

• Trust-weighted update (upon usage at time $\tau$):

$$\Delta \text{trust}_i = \alpha \cdot \text{sim}(q, i) - \beta \cdot \Delta t$$

$$\Delta t = \text{current\_time} - \text{last\_use}_i$$

• Forgetting via Age-based Decay:

$$M_i(t+\Delta t) = M_i(t)\exp\left(-\lambda \Delta t\right)$$

where $\lambda$ is a decay hyperparameter.

4.3 Performance Utility Metric

Let $N_{\text{reuse}}$ denote XP fragment reuses that avoid a new LLM call, and $N_{\text{tasks}}$ total tasks:

$$U = \frac{N_{\text{reuse}}}{N_{\text{tasks}}} \quad \in [0,1]$$

Higher $U$ values reflect superior XP-driven memory reuse and planning efficiency.

5. Concrete Fragments and Exemplary Scenarios

Stored XP fragments operationalize both rationale and validated procedures. For example:

• Scenario 1: Validation System
  • WHY:

  $$\{\text{Build robust validation for dynamic DOM elements}, [\text{Cross-browser support}, \text{Traceability}], T_c\}$$ - HOW:

  $$[\text{open\_url}(…), \text{locate\_element}(\text{selector}), \text{assert\_visible}(\text{elem}), \text{log\_result}()]$$ - CHECK:

  $$r_1 = \text{exists}(\text{elem}), r_2 = \text{is\_visible}(\text{elem}) \implies \text{Check}(F) = r_1 \wedge r_2$$

• Scenario 2: Experience Enhancement

  • If XP store lacks a "CHECK" for a validation workflow, the system auto-generates HOW validate_screenshot(), and the CHECK rule $$r_3 = \text{eq}(\text{size\_before}, \text{size\_after})$$, subsequently surfacing these in future agent queries on validation.

This systematic approach enables subsequent agents or workflows to inherit and refine best practices and validations without repeated prompt engineering.

6. Integration with Dialogue, Safety, and Adaptive Scheduling

Integration occurs at several operational touchpoints:

• Multi-turn Dialogue: Each user utterance is mapped to $(G, C, T_c)$ and buffered in STM; this enables immediate experience capture at dialogue inception.
• Dynamic Safety Validation: After HOW suggestions, MCP’s check_function() screens for safety, filtering out unsafe or low-trust fragments prior to LTM admission (e.g., blocking destructive SQL steps).
• Adaptive Scheduling: During dynamic workflow planning, the SchedulerAgent queries XP for previously successful dependency graph templates, reusing and parametrizing these as scaffolds for current needs.

7. Empirical Results and Operational Impact

In multi-domain orchestration benchmarks (10 tasks, 5 domains), activating XP delivered:

• 35% reduction in total LLM calls, attributable to high hit-rates in fragment reuse.
• 28% decrease in plan generation latency, with SchedulerAgent XP hit-rate increasing from 12% to 54%.
• Utility $U$ improved from $0.18$ to $0.62$ over 100 sessions.
• Inter-agent coordination, measured by message count per successful task, improved by 22% (Wu et al., 13 Jul 2025).

This demonstrates XP’s efficacy in reducing computational overhead, increasing planning throughput, and fostering scalable, experience-driven collaboration.

---

The Experience Pack architecture in GoalfyMax establishes a robust foundation for structured, validated, and continually improving memory across heterogeneous agent collectives, supporting compositional planning, high-trust automation, and long-run enterprise adaptability (Wu et al., 13 Jul 2025).