A result that looks better
You tell an agent to include the actual source behind every product claim. The next answer includes three citations and reads more carefully. It feels like the agent learned. But perhaps the new task already contained better references, the prompt was clearer, or a different model produced the answer. A better result alone does not identify the cause.
Calling every improvement learning makes the word useless. An honest loop must preserve enough structure to ask what changed and whether that change contributed. Meraki reduces the claim to four parts: evidence, a proposed guidance change, a later comparison, and a rollback path.
Four parts, in order
Evidence is the observed correction or outcome with its source and task. It is immutable because rewriting the record would rewrite the reason for the change. A candidate is the smallest guidance proposal that might explain the miss. It remains inactive until a person or an explicit policy approves its wording and scope.
Retrieval applies the approved guidance only to matching work. The run records exactly which profile version and pack it received. Evaluation then compares the result with alternatives: no profile context, raw memory, the scoped MerakiPack, and a targeted-removal run where the particular guidance is absent.
The targeted removal is the uncomfortable test. If the output remains equally good without the new rule, the rule may not deserve credit. If the rule helps one task but harms another, the scope is wrong. Evaluation can support, weaken, rescope, replace, or revoke guidance rather than converting every success into permanence.
Why determinism matters
Agent outputs are probabilistic, but the learning machinery around them does not need to be mysterious. Given the same profile state, task context, and policy, Meraki Core aims to build the same pack. Profile updates create versions. Approval decisions and rollback paths are recorded.
Determinism does not guarantee a good result. It makes a bad result diagnosable. A person can distinguish between a poor model response, an irrelevant retrieval, an overbroad approved rule, and weak evidence. Without that separation, every failure becomes another chat message asking the agent to try harder.
The same principle bounds claims. Passing local tests proves that the machinery follows its contract. It does not prove that people prefer the outputs. A hosted beta and independent human comparison are needed before Meraki can claim reliable improvement across real work.
Why the loop should stay small
A learning system can become an architecture diagram that no user can operate. The product experience should remain simple: show the correction, show the suggested change, show where it will apply, and show the next comparison. Technical vocabulary belongs in the docs and audit trail, not in the moment of giving feedback.
The current Core repository demonstrates the local evidence-to-rollback path and connected runtime mechanics. Live PostgreSQL and pgvector proof, invited-user hosting, and independent evaluation remain unfinished. Those gaps define the next work rather than invalidating the loop.
The unresolved question is what comparison is sufficient in ordinary use. Four-way evaluation is informative, but it may be too expensive for every correction. Meraki needs to discover when a quick check is honest, when a targeted removal is necessary, and when no learning claim should be made at all.