Conversation
… to Embabel layer Agent-Logs-Url: https://github.com/elasticsoftwarefoundation/akces-framework/sessions/01087ad6-e0f9-4913-a328-ff75494a706e Co-authored-by: jwijgerd <914840+jwijgerd@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR refactors the agentic memory subsystem to remove the StoreMemoryCommand/ForgetMemoryCommand pathway and runtime-layer sliding-window enforcement, shifting memory add/revoke responsibilities fully to the Embabel agent layer (which emits MemoryStoredEvent / MemoryRevokedEvent directly).
Changes:
- Deleted
StoreMemoryCommandandForgetMemoryCommand, and removed controller support for built-in command schemas/control-record publication. - Removed
AgenticAggregatePartition’s post-command sliding-window eviction (andmaxMemorieswiring) from the runtime layer. - Updated tests and documentation to reflect that memory revoke/eviction events are produced by the Embabel layer.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| main/agentic/src/main/java/org/elasticsoftware/akces/agentic/runtime/AkcesAgenticAggregateController.java | Drops built-in command registration/publication and removes maxMemories from construction/wiring. |
| main/agentic/src/main/java/org/elasticsoftware/akces/agentic/runtime/AgenticAggregatePartition.java | Removes runtime-layer sliding-window enforcement after command processing. |
| main/agentic/src/main/java/org/elasticsoftware/akces/agentic/events/MemoryRevokedEvent.java | Updates Javadoc to reflect Embabel-owned memory revocation/eviction. |
| main/agentic/src/main/java/org/elasticsoftware/akces/agentic/commands/StoreMemoryCommand.java | Deleted (built-in memory storage no longer routed via command bus). |
| main/agentic/src/main/java/org/elasticsoftware/akces/agentic/commands/ForgetMemoryCommand.java | Deleted (built-in memory revocation no longer routed via command bus). |
| main/agentic/src/main/java/org/elasticsoftware/akces/agentic/beans/AgenticAggregateBeanFactoryPostProcessor.java | Stops passing maxMemories into the controller constructor. |
| main/agentic/src/test/java/org/elasticsoftware/akces/agentic/runtime/MemorySlidingWindowTest.java | Updates commentary to align with Embabel emitting revoke events (test continues to simulate the window via events). |
| FRAMEWORK_OVERVIEW.md | Updates docs: no built-in memory commands; built-in memory events remain; Embabel owns eviction. |
| // Collect aggregate command types for the service record | ||
| List<AggregateServiceCommandType> allCommands = new ArrayList<>(); | ||
| BUILTIN_COMMAND_TYPES.forEach(ct -> | ||
| allCommands.add(new AggregateServiceCommandType( | ||
| ct.typeName(), ct.version(), ct.create(), | ||
| "commands." + ct.typeName()))); | ||
| aggregateRuntime.getLocalCommandTypes().forEach(ct -> | ||
| allCommands.add(new AggregateServiceCommandType( | ||
| ct.typeName(), ct.version(), ct.create(), |
There was a problem hiding this comment.
In publishControlRecord(), producedEvents is built later by combining BUILTIN_EVENT_TYPES with aggregateRuntime.getProducedDomainEventTypes(). Since AgenticAggregateRuntimeFactory already adds the memory event types (MEMORY_STORED/REVOKED) into the runtime’s produced domain events, this results in duplicate memory event entries in the AggregateServiceRecord. Consider de-duplicating the produced event list (e.g., by (typeName, version)) or removing the built-in add to avoid duplicates in service discovery.
| private void registerBuiltinSchemas() { | ||
| logger.info("Registering built-in agentic schemas for {}Aggregate", | ||
| aggregateRuntime.getName()); | ||
| for (CommandType<?> commandType : BUILTIN_COMMAND_TYPES) { | ||
| try { | ||
| aggregateRuntime.registerAndValidate(commandType, schemaRegistry); | ||
| } catch (IncompatibleSchemaException e) { | ||
| logger.warn("Built-in command schema {} is incompatible — attempting force-register", | ||
| commandType.typeName(), e); | ||
| try { | ||
| aggregateRuntime.registerAndValidate(commandType, schemaRegistry, true); | ||
| } catch (Exception ex) { | ||
| logger.error("Failed to force-register built-in command schema {}", | ||
| commandType.typeName(), ex); | ||
| throw new RuntimeException("Failed to register built-in command schema: " | ||
| + commandType.typeName(), ex); | ||
| } | ||
| } catch (Exception e) { | ||
| throw new RuntimeException("Failed to register built-in command schema: " | ||
| + commandType.typeName(), e); | ||
| } | ||
| } | ||
| for (DomainEventType<?> eventType : BUILTIN_EVENT_TYPES) { | ||
| try { | ||
| aggregateRuntime.registerAndValidate(eventType, schemaRegistry); |
There was a problem hiding this comment.
registerBuiltinSchemas() registers the memory event schemas from BUILTIN_EVENT_TYPES, but registerAggregateSchemas() later iterates aggregateRuntime.getProducedDomainEventTypes(), which (per AgenticAggregateRuntimeFactory) already includes MEMORY_STORED_TYPE and MEMORY_REVOKED_TYPE. This causes redundant registration/validation attempts for the same schemas. Consider registering event schemas from a single de-duplicated source, or explicitly excluding the built-in memory types from one of the passes to avoid duplicate work and confusing logs.
| * Tests the sliding-window memory eviction logic in the state transition layer. | ||
| * The eviction algorithm is exercised by simulating the sequence of events that are | ||
| * produced by the Embabel layer during the agent's memory management process. | ||
| * | ||
| * <p>The partition enforces the limit by issuing {@link org.elasticsoftware.akces.agentic.commands.ForgetMemoryCommand} | ||
| * for the oldest entry (first in the list) until the count drops to the allowed window. | ||
| * Each {@code ForgetMemoryCommand} produces a {@link MemoryRevokedEvent} that updates | ||
| * the state through the built-in event-sourcing handler in | ||
| * <p>Memory revocation is handled by the Embabel agent (via its memory management tools), | ||
| * which produces {@link MemoryRevokedEvent} directly. Each such event updates the | ||
| * state through the built-in event-sourcing handler in |
There was a problem hiding this comment.
The updated class Javadoc says this test covers “sliding-window memory eviction logic in the state transition layer” and that the eviction algorithm is “produced by the Embabel layer”. However the eviction loop is not part of the state-transition code under test; it’s implemented in this test via enforceWindow() by manually generating MemoryRevokedEvents. Consider rewording the Javadoc to clarify that the test validates memory state transitions when the Embabel layer emits revoke events, rather than testing an eviction algorithm in the runtime/state layer.
StoreMemoryCommandandForgetMemoryCommandare no longer needed —MemoryStoredEventandMemoryRevokedEventare now generated directly by the Embabel agent layer (via its memory management tools), bypassing the command bus entirely.Removed
StoreMemoryCommand.javaandForgetMemoryCommand.javadeletedBUILTIN_COMMAND_TYPESconstant removed fromAkcesAgenticAggregateControllerregisterBuiltinSchemas()(now registers only built-in event schemas)Akces-Controltopic inpublishControlRecord()resolveType()Sliding-window eviction removed from runtime layer
AgenticAggregatePartition.enforceMemorySlidingWindow()is deleted along with itsmaxMemoriesfield — the Embabel agent'sLearnFromProcessGoalis responsible for enforcing memory capacity bounds by producingMemoryRevokedEventdirectly.Constructor signatures changed
AkcesAgenticAggregateController—maxMemoriesparameter droppedAgenticAggregatePartition—maxMemoriesparameter droppedAgenticAggregateBeanFactoryPostProcessor— no longer passesagenticInfo.maxMemories()to the controller bean definitionDocumentation updated
FRAMEWORK_OVERVIEW.md— "Built-in commands" row updated; memory section updated to reflect Embabel ownershipMemoryRevokedEvent,MemorySlidingWindowTest, and the affected runtime classes updated