How does Bernstein handle knowledge sharing between agents?

[CorellisOrg]

I've been running 8 agents on openclaw and built a governance layer called Corellis for goal decomposition and shared memory. Knowledge sharing between agents has been a tough problem to solve in our setup. I'm curious how Bernstein approaches this, especially in multi-agent scenarios. For context, you can see how we handled it at github.com/CorellisOrg/corellis. Any insights would be helpful.

[chernistry]

@CorellisOrg, the design choice in Bernstein is to avoid the knowledge-sharing problem rather than solve it.

Agents are short-lived. They spawn for one task (or a small batch), do the work, exit. No persistent state, no sessions. If your agents only live five minutes, most of the "shared memory across agents" problem dissolves.

That said, agents still need some coordination. What's actually implemented:

• Bulletin board. Agents POST findings, blockers, status to an HTTP endpoint. New agents get recent bulletins injected into their spawn prompt as team-awareness context. Append-only, 24h TTL, stored in .sdd/runtime/bulletin_board.jsonl.
• Lessons system. File-based memory at .sdd/memory/lessons.jsonl, type-based decay (feedback 7d, project 14d, reference 90d). Lessons matching a task's tags get compressed and injected into the agent's spawn prompt. Agent A discovers "this API returns paginated results", Agent B picks up that lesson on a related task later.
• Knowledge files. Auto-generated docs at .sdd/knowledge/architecture.md (AST-parsed project index) and recent_decisions.md (last 15 decisions). Read-accessible at spawn.
• Semantic cache. Deduplicates similar tasks via cosine similarity. Threshold ≥0.85 for planning, ≥0.95 for responses. Two near-identical tasks: the second reuses the first's result without spawning.
• Cross-model verification. After completion the diff goes to a different model family for review (Claude work reviewed by Gemini, etc.). Quality feedback rather than knowledge sharing, but related.
• Subtask decomposition. Oversized tasks split into 2–5 subtasks, parent context (progress, files touched, discoveries) propagates down.

All state lives in .sdd/: flat files, no database, no message broker. Agents read and write via the task server HTTP API or directly to those files. The orchestrator itself is Python code, deterministic, not an LLM.

Honest gaps. There's delegation and direct-channel infrastructure in the codebase that's underused in practice. No dynamic capability auction or skill-based routing yet. The system handles parallel independent tasks with light coordination well; deep real-time collaboration between agents isn't a design goal.

I read through Corellis. Long-running containerized agents with the Teamind 4-layer memory plus Slack indexing is a different bet, useful where agents need deep ongoing context. Bernstein's bet is statelessness and crash resilience: if an agent dies, respawn it, nothing to recover.

Codebase is Apache-2.0, source at src/bernstein/core/: bulletin in bulletin.py, knowledge in knowledge_base.py, caching in semantic_cache.py. Solo project, pace varies. Issues and PRs welcome.