Meraki Docs

What Meraki is

Meraki is an iterative layer for AI agents. It sits between a person, the agents they use, and the context those agents receive. Its job is not to make a model sound more personal by adding a larger prompt. Its job is to turn explicit corrections and real outcomes into small guidance changes that can be inspected, approved, tested, narrowed, and undone.

The important word is iterative. A useful correction should not disappear after one answer, but it should not silently rewrite every future answer either. Meraki keeps the correction with the task that produced it, proposes the smallest plausible change, and applies an approved change only where its scope matches. The next relevant result becomes a test of that change.

The repeated-correction problem

People repeatedly teach agents the same judgment: do not hide the trade-off, use the actual source, keep this paragraph concrete, do not treat a temporary project constraint as a permanent preference. A normal chat can obey the correction in that conversation and then lose it. A broad memory system can retain the words but still miss the question that matters: which future tasks should this correction affect?

Simply recalling more history does not answer that question. A correction about an investor update should not change a personal note. A preference for concise incident reports should not flatten exploratory research. Meraki treats relevance, scope, time, and evidence as separate decisions. That makes the system more conservative, but it also makes a change explainable.

One correction from beginning to end

1. ObserveStore the correction and the result as immutable evidence. Evidence records what happened; it does not alter guidance.
2. ProposeDerive a candidate change whose wording and scope are narrow enough to review.
3. ApproveA person or explicit policy accepts, weakens, respecifies, or rejects the candidate.
4. RetrieveA matching task receives the approved guidance inside a focused MerakiPack.
5. EvaluateCompare the next result with alternatives, then keep, narrow, replace, revoke, or roll back the change.

Evidence versus a proposed change

Evidence and guidance are deliberately different records. Evidence is an event: a correction, selected output, reference, explicit preference, or observed outcome. It keeps provenance, including the task, source, time, and related result. A proposed change is an interpretation of that evidence. It can be wrong even when the evidence is genuine.

This separation prevents one frustrated edit from becoming a permanent identity claim. Multiple pieces of evidence can support or contradict a proposal. A proposal can remain a candidate, be rejected, or be approved for a small scope. Meraki Core uses lifecycle states so a rule can move from candidate to active, stable, dormant, superseded, revoked, or unsupported without erasing the history that produced it.

Profile facets and temporal horizons

A profile is not one biography. Meraki separates kinds of guidance, called facets, from how long that guidance is expected to matter, called horizons. Facets include facts, current state, goals, identity declarations, behaviors, cognitive patterns, communication, voice, taste, judgment, workflow, exemplars, anti-patterns, modes, and uncertainty.

Horizons are run, temporary, ongoing, and durable. A current launch deadline may be temporary. A project mode may be ongoing. A legal name can be durable. A correction can concern judgment without being an identity declaration, and a goal can expire without erasing a stable taste. Keeping these axes separate lets retrieval use the right guidance without treating every remembered statement as equally permanent.

Scope, project, task, and mode

Scope answers where a change is allowed to travel. Meraki can bind guidance to a project, task family, mode, source, or combination of those boundaries. A rule for public launch copy may match a product announcement in the same project while staying out of an engineering incident review.

A match is deterministic in the current Core work: the same profile state and task context should produce the same selected pack. This is useful for debugging. If guidance leaked into unrelated work, the retrieval decision can be reproduced and the scope can be weakened or respecified. Meraki does not claim perfect relevance. It is building the controls needed to find and repair a bad match.

What a MerakiPack contains

A MerakiPack is the focused context assembled for one agent run. It is not a dump of every stored memory. It contains the approved profile atoms, examples, constraints, uncertainties, and provenance needed for the present task, within a defined token and sensitivity budget.

• The task and mode used to decide relevance.
• Selected guidance with facet, horizon, scope, and lifecycle state.
• Supporting examples or anti-patterns when they are useful.
• Source references so a person can inspect why guidance was included.
• A deterministic manifest that can be compared with later runs.

The pack is the bridge between stored evidence and an agent. That boundary matters for security: untrusted task content should not gain the authority to alter durable profile state, and sensitive atoms should not be retrieved into a context that is not allowed to receive them.

How the four-way comparison works

A good-looking output is not enough to prove a guidance change helped. Meraki Core defines a four-way comparison: a baseline without profile context, raw memory retrieval, the scoped MerakiPack, and a targeted-removal run where the specific guidance being tested is withheld.

The comparison asks a practical causal question. Did the result improve because the proposed guidance was present, or would the task have improved anyway? The targeted-removal run is especially important because it tests the contribution of one change rather than rewarding the whole system for a generally better prompt.

Approval, weakening, rescoping, and rollback

Approval is not a single permanent switch. A person can accept a proposal as written, weaken its confidence, narrow its scope, choose a shorter horizon, or reject it. Later evidence can support it, contradict it, or show that it helps one task family while hurting another.

Every accepted change keeps a version and provenance trail. If it fails, Meraki can revoke it or roll back to an earlier profile version. If it is partly useful, it can be respecified rather than deleted. Reversibility is not an emergency feature. It is part of the everyday definition of learning because iteration without an exit path is only accumulation.

Security and prompt-injection boundaries

Meraki treats retrieved content and profile mutation as different trust boundaries. An instruction inside a document, website, or model output is not allowed to promote itself into durable guidance. New evidence can be recorded, but candidate generation, approval, and activation remain explicit stages.

A MerakiPack should expose only the atoms allowed for the current task and sensitivity level. Provenance makes suspicious guidance traceable. Deterministic manifests make unexpected retrieval reproducible. These are design controls, not a claim of completed security certification. The hosted product boundary, authentication model, and independent security review are still future work.

What works today

Meraki Core is an independent engine under active development. The repository implements a local deterministic loop for evidence, candidate changes, approval policy, scoped retrieval, pack construction, comparison, profile versioning, and rollback. Connected runtime paths and local tests demonstrate the mechanics without requiring the landing page to pretend that a complete hosted product already exists.

What remains unproven

The invited-user hosted flow is not finished. Live PostgreSQL and pgvector proof for Core remains open. The system has not yet been evaluated by independent humans across enough real tasks to show that its changes consistently improve results without harmful leakage. Those gaps are product work, not footnotes.

The beta is meant to test the uncomfortable parts: whether corrections become useful proposals, whether scope is understandable, whether comparisons reveal real improvement, and whether people can recover quickly from a bad change. Until that evidence exists, Meraki describes the loop it has built and the hypothesis it is testing.

Meraki, Meraki Core, and Catalyst

Catalyst asks the broader question: can agents improve through evidence and accountable change? Meraki is the user-facing layer being designed around that question. Meraki Core is the independent engine that implements the evidence, retrieval, evaluation, and rollback mechanics.

Keeping the names separate prevents the landing page from turning research direction into a fake product claim. Meraki should become the experience a person can understand and control. Core should remain inspectable infrastructure. Catalyst should remain honest about the question and the proof still needed.