The useful rule that became a trap
An agent is corrected for producing vague launch copy. The resulting rule works: “Name the concrete limitation before the benefit.” A month later, the same guidance makes early brainstorming defensive and flat. The rule was not false. It travelled beyond the work where it was useful.
A normal memory system gives you two bad options. Keep the memory and tolerate the leak, or delete it and lose the cases where it helped. An iterative system needs a richer response: narrow the task family, shorten the horizon, weaken confidence, replace the wording, or return to the profile version before the change.
Reversibility is part of the definition
Teams often treat rollback as an operational safety net added after a feature works. For learning, rollback belongs inside the core model. If guidance can change future behavior, its source, approval, scope, and version need to remain attached. Otherwise the system accumulates influence without accountability.
Meraki Core records profile updates as versions rather than editing an invisible prompt in place. A rule can move through lifecycle states such as candidate, active, stable, dormant, superseded, revoked, or unsupported. The evidence remains even when the guidance is revoked, because the historical event is still true.
That distinction allows recovery without amnesia. You can stop using a rule while preserving why it was proposed and what happened when it was active. Later evidence may justify a narrower replacement. The system can learn from the failed scope instead of erasing the episode.
Undo is more than a button
A visible undo action is necessary, but it is only the surface. Real reversibility requires deterministic retrieval, versioned packs, provenance, and evaluation records. A person needs to know which results received the guidance and whether any later profile change depends on it.
Meraki uses actions with different levels of force. Weaken reduces confidence. Rescope changes where the rule can travel. Replace creates a new interpretation while preserving history. Revoke stops future use. Rollback restores an earlier profile version. The right choice depends on whether the rule itself was wrong or merely overbroad.
This is also a psychological design choice. People give more honest feedback when correction does not feel permanent. A reversible proposal invites experimentation. A hidden profile rewrite encourages caution because one impatient edit may echo through every future agent.
What is built and what is open
The independent Meraki Core repository implements versioned profile state and rollback in its local deterministic loop. It also connects guidance to evidence and comparison records. Those capabilities make reversible learning technically concrete rather than a slogan.
The hosted product experience is not finished. Meraki has not yet shown that ordinary users can understand the difference between weakening, rescoping, revoking, and rolling back without confusion. It has not completed independent evaluation of how often undo prevents a bad result from recurring.
The unresolved question is how visible history should be. Too little history hides cause and effect. Too much turns the product into a database console. The best undo experience may show one clear sentence about what changed, one preview of affected work, and a deeper audit trail only when someone needs it.