build_system builds the validator's memory out of another instance's class
tech-debt · raised in review of PR #7
build_system gives the validator its own memory by reaching into the class of the instance it was handed:
self.meta_memory_validator = mas_memory.__class__(
namespace=mas_memory.namespace + "_validator",
global_config=mas_memory.global_config,
llm_model=mas_memory.llm_model,
embedding_func=mas_memory.embedding_func,
)It works, and Phase 4 relies on it — the memory modules carry their prompts as class attributes precisely so this reconstruction keeps them, which is why a functools.partial registry would have been silently broken. But a workflow reconstructing a collaborator by unpicking one it was given is the wrong direction of control: build_system has to know every constructor argument MASMemoryBase takes, and gains a reason to change every time that signature does.
Two ways out.
build_mas supplies both. It already builds the memory module from module_map, so it can build a second one and pass it in. build_system's signature grows an optional validator_memory, and the workflow stops knowing how memories are made.- The memory offers it. A
MASMemoryBase.for_namespace(suffix) returning a sibling instance keeps the knowledge of its own constructor where it belongs, and reads as one line at the call site.
Option 2 is smaller and puts the knowledge in the right place. Option 1 is more thorough and fits the dependency direction the rest of Phase 4 moved toward.
Not urgent. test_a_rebuilt_memory_keeps_its_prompts pins the behaviour either way, so this can be changed without guessing.
Migrated from docs/BACKLOG.md.
build_systembuilds the validator's memory out of another instance's classtech-debt· raised in review of PR #7build_systemgives the validator its own memory by reaching into the class of the instance it was handed:It works, and Phase 4 relies on it — the memory modules carry their prompts as class attributes precisely so this reconstruction keeps them, which is why a
functools.partialregistry would have been silently broken. But a workflow reconstructing a collaborator by unpicking one it was given is the wrong direction of control:build_systemhas to know every constructor argumentMASMemoryBasetakes, and gains a reason to change every time that signature does.Two ways out.
build_massupplies both. It already builds the memory module frommodule_map, so it can build a second one and pass it in.build_system's signature grows an optionalvalidator_memory, and the workflow stops knowing how memories are made.MASMemoryBase.for_namespace(suffix)returning a sibling instance keeps the knowledge of its own constructor where it belongs, and reads as one line at the call site.Option 2 is smaller and puts the knowledge in the right place. Option 1 is more thorough and fits the dependency direction the rest of Phase 4 moved toward.
Not urgent.
test_a_rebuilt_memory_keeps_its_promptspins the behaviour either way, so this can be changed without guessing.Migrated from
docs/BACKLOG.md.