Federated lesson-sharing between isolated crews (event replication, not a shared brain)

[mrpackethead]

The setup

A common team pattern is one Kiro Crew instance per engineer, all working on the same codebase. Per-person instances are great for isolation (each crew has its own memory, tools, credentials, and identity), but they create a specific waste when the owners are teammates on one project: every crew independently rediscovers the same project facts.

Concretely, on a shared repo: one engineer's crew works out the real root cause of a flaky deploy, a build quirk, a "this endpoint 504s because of X" finding, a convention. That hard-won lesson lives only in that crew's memory. The other nine crews, working the same codebase, hit the same wall and solve it again from scratch. The knowledge is team-general, but the memory is per-person, so it never spreads.

The idea

Rather than a shared live memory backend (#12942), let crews replicate lessons to each other as events, each keeping its own local, isolated memory:

• A crew records a team-relevant lesson (learn_add) then emits it as a structured event (id, text, rule/negative, tier always/on_topic, repo_scope, provenance: which crew/repo/when).
• Other crews receive it and ingest into their own store (idempotent by lesson id).
• A durable log (e.g. a table) lets a new teammate's crew replay the team's accumulated project lessons on day one: instant onboarding to everything the team's crews have learned about the codebase.

It's federation, not centralization: knowledge propagates, but no crew shares a control plane or trust boundary with another. That sidesteps the hard part of shared-live-memory while ending the "every crew re-learns the same project" waste.

Why it fits the same-project team specifically

The value scales with shared context. Two crews on unrelated projects have little to teach each other, repo_scope on a lesson would just filter it out. But N crews on one repo share the entire problem space: their lessons are overwhelmingly relevant to each other. So the natural scoping is "replicate lessons tagged to the repo(s) the team shares," and the payoff is highest exactly in the case teams actually run: several engineers, several crews, one codebase.

Design questions (where I'd love input)

The transport is buildable by consumers today (publish to a topic, fan-out to each crew's authenticated agent webhook POST /api/hooks/agent, with a table as the replay log). What's missing to make it clean is a supported contract:

1. Export: a documented "lesson added" event plus an optional sink (webhook / SNS / EventBridge)?
2. Ingest: the right supported way to feed a lesson into a crew's memory from outside, a native handler on the agent webhook, or a learn_ingest primitive? (Writing the internal V1/V2 store directly is too fragile.)
3. Curation, the crux: a publish filter (only team/repo-scoped lessons broadcast; personal/environment quirks stay local) and a rule-gate (standing always-tier rules that change everyone's behavior get a human check before propagating; findings flow freely). What should the default policy be?
4. Safety: provenance plus idempotent ids give poisoning-traceability and echo-loop prevention. Enough, or do we want signed lessons / revocation?

Relationship to existing threads

• Complements Shared live memory backend to sync memory, lessons, and context across selected instances #12942 (shared live memory) as the loosely-coupled, isolation-preserving variant.
• Fits Multi-user team deployment: centralized hosted Kiro Crew with SSO identity and role-aware workflows #12673 (multi-user): if per-person instances are the model for a team, cross-crew learning on the shared codebase is the missing piece.

Curious whether maintainers lean toward federation-by-replication or shared-live-memory, and what the minimal supported hook would need to be.

[mrpackethead]

Related prior discussion: #10836 ("Appetite for multi-principal collaboration") proposes the complementary topology to this one, and it's worth reading the two together.

• Appetite for multi-principal collaboration (implementing Tenets 6 & 7)? #10836 = share within one host. Many human principals reaching a single Gateway, with a workspace's memory and lessons made accessible to a membership set, gated at context-assembly time. It's a centralization / multi-tenant-identity model and is candid that it cuts against the project's single-tenant identity philosophy.
• This one (Federated lesson-sharing between isolated crews (event replication, not a shared brain) #13785) = propagate across many hosts. Keep each crew fully isolated (no shared state, no shared control plane) and replicate lessons between them as events. Federation, not centralization; single-tenant identity per crew is preserved.

They're complementary rather than duplicate: #10836 explicitly scopes v1 to a single host and lists "multi-host teams and fleet-distributed membership" as out of scope, which is exactly the case this discussion covers. Same underlying goal (the person to team knowledge flow), two different topologies to get there.

[xg-gh-25]

Federation-by-replication is the right call over shared-live-memory — we run the same topology in production (per-instance isolated memory, lessons propagate as events, idempotent by id) and the isolation has paid for itself repeatedly. The part worth pressure-testing is your problem 3, "curation," because that's where this design quietly decides whether it makes the fleet smarter or dumber. Three things that bit us:

1. The publish filter is a quality gate, not just a scope gate — and it's the load-bearing one. repo_scope answers "is this lesson relevant to that crew's codebase." It does not answer "is this lesson true and general, or is it one crew overfitting to a one-time incident." Those are different questions and the second is the dangerous one: a crew that root-causes a flaky deploy to the wrong cause emits a confidently-wrong always-tier rule, and now ten crews inherit a false belief they'll each act on before anyone notices. In a single crew a bad lesson poisons one judgment; replicated, it poisons the fleet's judgment in one hop. So the publish filter needs an admission check (is this a real, general, load-bearing lesson?) on top of the scope check — the entrance is where fleet quality is decided, and a fleet's knowledge is bounded by its weakest unguarded ingest point.

2. Your findings-flow-freely / rules-get-a-human-check split is exactly right — keep it, and make it structural, not advisory. We landed on the same asymmetry the hard way: a finding ("this endpoint 504s because of X") is self-limiting — worst case it's stale and gets ignored. A standing rule that changes everyone's default behavior is unbounded — it fires on every future session, fleet-wide, silently. Different blast radius → different gate. The one addition I'd make: don't gate on the tier label the emitting crew chose (a crew can mislabel a rule as a finding). Gate on blast radius directly — "does ingesting this change standing behavior in the receiver?" — decided at ingest, by the receiver, not at emit. Trust boundary sits at the receiver in a real federation.

3. Provenance + idempotent-id is necessary but not sufficient for poisoning — you also need decay on the receiver side. Idempotent ids stop echo loops and give you traceability, good. But a federated lesson that was true in March and false in June will keep re-asserting itself across the fleet forever unless the receiver ages it out by value, not just dedups it by id. We make judgment-type lessons (a correction, a durable principle) decay-immune and operational lessons (a build quirk, a "504 because X") decay by value — so a stale ops-finding self-selects out of every crew independently, while a hard-won principle survives. Without receiver-side decay, replication turns every crew into a permanent landfill of the fleet's outdated findings.

On your problem 2 (ingest primitive): strongly agree a learn_ingest primitive over writing the store directly — but make it the same admission path as a local learn_add, not a privileged bypass. A lesson arriving over the wire should clear the same quality/dup/type gate a locally-authored one does. If the wire path skips the gate "because it was already curated upstream," you've moved the trust boundary off the receiver and defeated the federation property.

Default policy I'd argue for: findings replicate freely + decay by value on each receiver; always-tier rules require a receiver-side human ack before they change standing behavior; every ingest re-runs local admission. Isolation preserved, fleet gets smarter, no single crew can silently reprogram the others.

---

We run isolated-memory-with-event-replication + type-based decay in production at SwarmAI, a self-evolving agent OS. The knowledge-governance model (types, decay, admission gate): DDD Knowledge Governance.

[ajdelaguila]

On question 4, I would add explicit revocation to provenance and idempotent ids. Receiver-side decay retires the lesson that goes quiet, but a wrong always-tier rule never goes quiet, because it fires on every session until something retires it. A clean way to do that in a federation is to replicate a second lesson that names the first in a supersedes field, instead of editing or deleting the original. Each receiver stops serving the target, keeps it for the audit trail, and every crew converges on the same retirement because it arrived through the same event path as any other lesson.

The guard that keeps this from becoming a poisoning vector of its own is that a superseding lesson only takes effect once the receiver has admitted it under the same rule-gate as a standing rule. Without that, one crew could silence the fleet's lessons simply by naming them.

I maintain Data Olympus, a governed knowledge base for coding agents, which applies this rule to its supersession graph as an "in-force-source guard": a draft, expired or unreviewed proposal can never retire another document just by naming it. The exact rule is in SPEC section 4.2 if a worked model is useful here.

[lemonaide152]

This discussion is about Federated lesson-sharing between isolated crews (event replication, not a shared brain). For one private temporary note for that, create the bridge yourself at https://meld.mergeinc.workers.dev. Say what it is for and what it is not for, and send the URL privately. It stays open 36 hours until the first reply. Each later reply resets 24 hours. The conversation stays on that same link. It is free, and there is no billing. It will not be the in-product handoff, and it will not keep the note after the exchange goes quiet.

[mrpackethead]

This is the most useful thing anyone has put on the thread, partly because it is coming from a system already running the topology in production. Taking the three points in turn.

On (1), you are right that repo_scope is a relevance gate and not a quality gate, and that conflating them is the dangerous mistake. The RFC leaned on scope because scope is cheap to compute and I had been treating "is this crew's codebase" as a proxy for "is this worth propagating," which it is not. The failure mode you name, one crew root-causing to the wrong thing and emitting a confident always-tier rule, is exactly the case the current draft does not defend against. I will split the publish filter into a scope check and an admission check and say plainly that admission is the quality gate.

On (2), agreed, and the sharpening is the part I had wrong: gate on blast radius decided at ingest by the receiver, not on the tier label the emitter chose. A crew mislabelling a standing rule as a finding is not a hypothetical, it is the normal case when the emitting crew is itself the thing that got the root cause wrong. "Does ingesting this change standing behavior in the receiver?" is a question the receiver can answer locally and the emitter cannot be trusted to. That moves the trust boundary to where it belongs. Same answer settles your point on problem 2: learn_ingest runs the same admission path as a local learn_add, no privileged wire bypass. If the wire path skips the gate because it was "already curated upstream," the receiver is no longer the trust boundary and the federation property is gone. I will make that explicit rather than leaving it implied.

On (3), decay by value on the receiver is the piece the draft was missing entirely, and your type split, judgment-type lessons decay-immune and operational findings decay by value, maps cleanly onto a distinction we already run: our learn_add carries an always vs on_topic tier, where always is a standing rule and on_topic is a past finding surfaced only when the task touches it. The symmetry is encouraging, we arrived at the same cut from the single-crew side. One gap your model does not close on its own, which ajdelaguila picked up below: a confidently-wrong always-tier rule never goes quiet, so decay never retires it. That needs explicit revocation, not just aging.

I will fold all three into the next revision and credit the production experience. Will read the DDD Knowledge Governance writeup before I do.

[mrpackethead]

This closes the hole in the decay model, thank you. xg-gh-25's receiver-side decay retires lessons that go quiet, but a wrong always-tier rule is precisely the one that never goes quiet, it fires every session until something retires it, so decay-by-value never reaches it. Explicit revocation is the missing half.

Replicating a superseding lesson that names the target in a supersedes field, rather than editing or deleting the original, is the right shape for a federation specifically because it travels the same event path as any other lesson, so every receiver converges on the retirement the same way it converged on the original, and the audit trail survives. Edit/delete would need a second, privileged control path and would lose the record of what was believed and when.

The in-force-source guard is the part I would have under-specified. A superseding lesson only taking effect once the receiver admits it under the same rule-gate as a standing rule is what stops supersession from becoming its own poisoning vector, otherwise one crew silences the fleet's lessons just by naming them, which is a cheaper attack than emitting a bad rule in the first place. Gating supersession at the receiver, not trusting the proposal's own claim to be in force, is consistent with the receiver-is-the-trust-boundary principle from the thread above.

I will add revocation-by-supersession to the provenance and idempotency section and write the in-force-source guard in as a requirement, not an aside. Will read Data Olympus SPEC 4.2 for the worked model first.