Multica Agent Context Sharing

Multica agent context can be shared through workspace guidance, attached Skills, Project Resources, and issue history. Those native surfaces coordinate work, but they are not one semantic memory of the repository. Keep stable instructions in the appropriate Multica surface, put current code relationships in a read-only external layer, and keep each agent’s plan, branch, credentials, and unverified conclusions isolated.

The useful distinction is between shared policy, shared pointers, shared facts, and task-local state. Collapsing them into “memory” makes conflicts hard to diagnose. A stale Skill is not the same failure as a stale dependency edge. An issue comment is not the same authority as source code. A resumed provider session is not evidence that another agent sees the same conclusions.

This article reflects Multica v0.4.10 and the public documentation checked on July 24, 2026. The proposed repository layer below is external to Multica; the product does not document a built-in code graph or automatic cross-agent summary reconciliation.

Before Sharing Context Across Agents

Multica agent context should be separated by authority and lifecycle before it is shared among planning, coding, testing, and review roles.

Start by naming the job of each context surface. A useful inventory has five columns: content, owner, consumer, refresh trigger, and authority.

Multica provides several native shared surfaces:

• Workspace context is guidance injected into agent runs. It is appropriate for stable team conventions, escalation rules, and common constraints.
• Workspace Skills are Agent Skills-compatible packages attached to selected agents and copied into provider-native discovery locations when a task starts.
• Repository Skills remain in the checked-out repository and can travel with its revision.
• Project Resources provide typed pointers to repositories or directories and a structured .multica/project/resources.json manifest.
• Issue comments, status, and history preserve collaboration state around a work item.

These mechanisms are more precise than a vague shared coding agent memory promise. They also have different lifecycles. An edited workspace Skill reaches newly created tasks, not a running task that already received its copy. A resource fetch can fail without blocking the task. A provider session belongs to one task or conversation rather than becoming shared memory for every agent.

Before adding another layer, define what must remain local: branch state, intermediate reasoning, temporary patches, destructive credentials, personal notes, and uncertain hypotheses. Sharing all of that creates more conflict, not more understanding.

Define a Read-Only Repository Knowledge Layer

A trustworthy shared coding agent memory layer is read-only to task agents and binds every structural claim to source evidence and a repository revision.

Use the repository itself as primary evidence, then generate a bounded, queryable view of relationships that agents repeatedly need. The layer can be structured files, a search index, or a code knowledge graph. Its storage choice matters less than provenance and access control.

Include facts such as:

• module and package boundaries;
• symbol definitions, direct references, registrations, and event flows;
• generated-code sources and build commands;
• schema, API, queue, and database relationships;
• test-to-feature and test-to-symbol mappings;
• architecture records, owners, and deprecations;
• indexed commit, excluded paths, failed parses, and extractor version.

Every material result should cite a source path and revision. An agent should be able to ask, “Why does the layer say service A consumes event B?” and receive the source location or derivation that supports the edge.

The official Multica GitHub repository and product docs do not expose a native graph ingestion or query API. Treat this integration as your architecture. Expose a read-only query command through the mechanism supported by the underlying provider. Multica’s MCP field is provider-specific; some providers will need a CLI, Skill wrapper, or other adapter instead.

Do not let task agents mutate the index they query. Index writes should run in a separate identity, produce an audit record, and require review for schema or manual-fact changes.

Separate Planning, Coding, Testing, and Review Needs

The current Multica GitHub repository documents the coordination implementation; it does not turn one role's task summary into shared repository truth for every other role.

Different roles need different slices of the same repository truth.

Role	Shared input	State that stays local	Required output
Planner	module map, decisions, likely dependencies	alternative plans and uncertainty	bounded plan with cited evidence
Coder	approved plan, definitions, callers, write scope	worktree changes and experiments	patch plus changed-contract notes
Tester	behavior contracts, test index, risk paths	test fixtures and temporary diagnostics	results, gaps, and reproduction steps
Reviewer	base revision, patch, evidence trail, test results	independent review notes until submitted	supported findings and merge decision

The shared layer should answer repository questions, not dictate every role’s procedure. Put role workflow in Skills and workspace context. Put structural claims in the source-attributed layer. Put work-item decisions in the issue. This separation makes a disagreement traceable: agents can disagree about a plan while still consulting the same definition and callers.

Project Resources help each role reach the same repository family, but the checkout revision can still differ. Record the resource identifier and actual commit in every task result. If two agents analyze different commits, their summaries should not be merged as if they describe one state.

Reduce Duplicate Scanning

Do not solve repeated search by dumping a giant repository summary into every prompt. Build a small retrieval contract.

1. Pin the task’s repository and commit.
2. Classify the question: locate, call path, change impact, test coverage, or design constraint.
3. Retrieve a bounded set of paths and relationships with provenance.
4. Ask the agent to verify high-impact edges in its checkout.
5. Persist only reusable, reviewed facts; keep task conclusions in the issue.
6. Measure file reads, retrieval misses, review corrections, and evidence age.

This pattern reduces duplicate scanning while preserving freshness checks. A graph hit is a shortlist, not a verdict. A graph miss is also useful when it records coverage gaps instead of silently implying that no dependency exists.

Track whether the packet actually helps: time to the first evidence-backed plan, number of repeated file reads, missed relationships found in review, and the age of cited facts. A smaller packet is successful only when correctness holds.

Compare those measures by task class rather than averaging unrelated work. A navigation task and a cross-service migration need different evidence depth. Record why an agent widened retrieval so a reviewer can distinguish justified exploration from an ineffective query.

Workspace Skills can standardize this query-and-verify procedure for multiple agents. The Skill should request an indexed revision, cite sources, report unknowns, and stop when the task revision differs. The Skill itself remains workflow memory; it does not become the repository model.

Conflict, Permission, and Drift Risks

Shared context increases the blast radius of a bad fact. A wrong module owner can misroute many tasks. A stale security note can normalize unsafe behavior. A broad graph query can reveal relationships from a repository the assigned agent should not access.

Control the risks explicitly:

• Conflict: define precedence by source type. Current source and approved policy outrank agent summaries. A human resolves architecture or security conflicts.
• Permission: filter facts before retrieval. Multica agent visibility and assignability do not make the returned data read-only or authorized.
• Drift: attach version, source, and expiry metadata. Reject packets built for the wrong commit.
• Provenance: keep file and symbol citations beside relationship claims.
• Supply chain: inspect third-party Skills before attachment; Multica does not sign or sandbox their content.

The underlying coding tool also retains its own execution permissions. Multica’s current Claude daemon handler auto-approves tool-control requests during autonomous execution, so daemon workdirs, credentials, and operating-system identity must carry the real containment. A task board is not a sandbox.

FAQ

What context should agents not share?

Do not share secrets, unrestricted credentials, private reasoning, unreviewed hypotheses, temporary patches, or one task’s write authority. Share the minimum reviewed facts and policies needed for the next role.

Who can update shared memory?

Assign owners per surface. Team leads may own workspace context, Skill maintainers own procedures, issue owners own task decisions, and an index service plus reviewers own repository facts. Ordinary coding agents should query the fact layer read-only.

How should conflicting summaries be resolved?

Compare each summary’s repository revision, cited source, and observation time. Verify the disputed relationship in current source. Escalate architecture, security, ownership, and data-contract conflicts to a human rather than choosing the longer or newer-looking summary.

What is a multi-agent system?

In this workflow, it is a set of agents with distinct roles coordinated around shared tasks and controlled information exchange. Multica supplies coordination surfaces; your repository layer supplies auditable structural evidence.

Conclusion

Use Multica’s native surfaces for shared guidance, reusable procedures, resource pointers, and issue state. Add a read-only, revision-bound layer for current repository relationships. Keep task reasoning and write state isolated. The result is not one magical memory: it is a set of owned context layers whose conflicts can be located, verified, and corrected.