Running several AI agents? Give them one shared memory — and keep yourself as the only one who decides

Running several AI agents? Give them one shared memory, and keep yourself as the only one who decides

By Mike Schreiber

Imagine a research agent suggesting a simpler signup flow. A drafting agent describes that suggestion as the plan. An implementation agent then removes a required approval step. This is a hypothetical example, but it captures the failure this guide is designed to prevent: a proposal becoming an instruction without a human decision.

The goal of shared memory should not be to preserve every conversation. It should be to give each agent a clear account of what is agreed, what has actually happened, and what still needs review.

Here is a practical workflow for doing that with Hark, including the boundaries that remain your responsibility.

1. Define what counts as a decision

Before connecting agents, establish three categories:

• Human decisions: constraints you explicitly approve, including their scope and rationale.
• Observed work: evidence of activity, such as a commit or a completed test run. This describes what happened, not whether it was the right choice.
• Proposed notes: interpretations, recommendations, inferred status, and suggested changes that have not yet earned approval.

For this workflow, define a decision as something another agent must ask before reversing. Avoid turning every progress update into a decision.

In a hypothetical billing project, “Keep invoice exports backward-compatible” is a decision. “Added an export test” is observed work. “Replace the export format next” is a proposal. Even a passing test does not authorize the replacement.

Hark’s trust settings preserve an important boundary: decisions are never approved automatically at any trust level. Anything conflicting with an accepted decision also goes to review rather than being auto-accepted. Hark: Working with agents

Treat that as an approval boundary, not a guarantee that an agent’s reasoning or implementation is correct.

2. Separate stable instructions from current state

Keep lasting conventions separate from the latest work status. Your build commands and coding standards should not compete with yesterday’s blocker for attention.

Claude’s documentation describes CLAUDE.md as persistent instructions read at session start. It recommends keeping session-wide facts there and moving multi-step procedures or narrowly applicable instructions into skills or path-scoped rules. Claude Code: Memory

Hark’s documented model has three layers: stable context in the repository, living state in Hark, and an agent brief that composes both. Living state includes the Current state card, journal, features, and checklist. Hark: Working with agents

For the hypothetical billing project, use this division:

• Repository instructions: test command, formatting conventions, supported runtime.
• Accepted decision: preserve the existing export contract.
• Current state: compatibility tests underway; a sample invoice is missing.
• Proposed note: investigate whether a new format would simplify integration.

Ask agents to label uncertainty explicitly. “Not checked” is more useful than an unsupported claim that the project is ready.

3. Connect a client and verify the project

Start with a single client and a test project before adding more agents.

For Codex, the documented connection commands are:

codex mcp add hark --url https://harkstudio.io/mcp

codex mcp login hark

The login opens a browser for sign-in and approval. Run codex mcp list to confirm the connection. Hark: Codex connection

Next, ask the agent to list your Hark workspaces. Then ask it to create a project called “Connection test” in the intended workspace. The documented verification expects a new project code and an activity-log source label identifying the client. Delete the test project afterward. Hark: Codex connection

Before real work, confirm the intended project aloud in the prompt. Hark sessions are locked to one venture; moving to another requires switch_venture, and blocked cross-venture attempts are logged. Hark: Working with agents

Still assign responsibilities yourself. A shared brief should not be treated as permission for every agent to edit the same files simultaneously.

4. Start every session by reading the brief

Use a repeatable opening instruction:

Start a session on the intended project. Read the brief before editing. Summarize the accepted constraints, next action, blockers, and unresolved proposals. Ask if the assignment conflicts with an accepted decision.

Hark’s guidance calls for start_session first and get_agent_brief before work. The compact brief includes phase, next action, recent decisions, blockers, and non-goals; depth="full" requests broader project context. Hark: Working with agents

For Claude Code, the early-access Hark mod fetches the compact brief at session start and restores agreed decisions, non-goals, blockers, and the next action after compaction. It requires Claude Code 2.1.287 or newer. Hark: Claude Code mod

Verify understanding rather than merely checking that a tool ran. In the hypothetical billing project, ask: “Which export constraint must remain unchanged?” A vague answer should trigger clarification before implementation.

5. Choose how much non-decision review to delegate

Begin with the least delegation that fits your workload. Hark documents these trust levels:

• Standard: review every agent proposal; repository facts backed by a commit, pull request, or release are accepted as observed.
• Relaxed: also auto-accepts Current state lists and handoff drafts inferred from repository activity. Decisions, non-goals, summary, and phase still require review.
• Autopilot: auto-accepts proposals except decisions, non-goals, and phase changes. It is armed per project and agent tool, switches off after 24 hours, and is unavailable workshop-wide.

Automatically accepted content is labeled “Auto-approved,” including in briefs and handoff views. Conflicts with accepted decisions remain subject to review. Hark: Working with agents

Do not read “Auto-approved” as “approved by me.” Review the evidence appropriate to the claim.

In a hypothetical session, an agent might report that a compatibility test passed and suggest dropping support for an older format. Evaluate these separately: inspect the test evidence, then decide whether the proposed policy change is acceptable.

When replacing an existing decision, Hark’s guidance requires supersede_decision only after the user has said yes in the current chat, using explicit decision IDs. Hark: Working with agents

6. Close with a handoff, then test the next reader

Ask the outgoing agent to separate completed work, evidence, unfinished work, and recommendations. Do not let “implemented” silently become “approved” or “verified.”

Hark’s end_session writes a handoff organized around “What I did,” “What changed,” “What’s next,” and “Watch out for,” and updates Current state. With repository export enabled, it also commits the brief to the repository. Hark: Working with agents

Then open a fresh session or another connected client and ask it to retrieve the brief and repeat a constraint you recorded. This is Hark’s documented handoff test. It demonstrates that the recorded constraint is available to the next reader, not that conversation history was transferred. Hark: Set up from your repo

Troubleshooting and boundaries

The Claude Code mod did not add a brief. Check its key configuration, the repository’s .hark/project or .hark file, and the required Claude Code version. Without a project file or key, the mod stays idle and sends nothing. Hark: Claude Code mod

The decision guard asks too often. Give decisions a relevant area or file-path scope. The documented guard presents Allow or Stop before edits covered by an agreed decision or non-goal. Do not treat this local edit check as universal enforcement across all clients. Hark: Claude Code mod

A session ended without a handoff. Hark documents an automatic draft after 45 minutes of inactivity. Inspect that draft before relying on it; a reconstruction is not proof that every intended task finished. Hark: Working with agents

Sensitive information appears in closing notes. The Claude Code mod sends a handoff summary, not prompts, transcripts, file contents, or diffs. Its closing-note cleaning is best effort, and secrets written in plain prose could be sent. Keep secrets out of notes. Hark: Claude Code mod

FAQs

Does every update need my approval?

No. Hark’s trust levels permit different kinds of non-decision acceptance. Decisions never receive automatic approval. Hark: Working with agents

Is shared memory a replacement for repository instructions?

Use them together. Hark’s brief combines stable repository context with living project state. Hark: Working with agents

How should I judge whether this workflow works?

Audit a handoff. Can the incoming agent distinguish your decisions from observed work and pending recommendations? If not, fix the records before delegating more work.

Sources

• Hark: Working with agents
• Hark: Codex connection
• Hark: Claude Code mod
• Hark: Set up from your repo
• Claude Code: Memory