Multica Multi-Agent Context Consistency

Multica multi-agent context stays consistent only when every shared item has a source, version, owner, scope, and expiry rule. Workspace context, Skills, Project Resources, issue history, provider sessions, and external repository facts move on different clocks. Do not merge them into one “memory.” Detect version skew, show conflicts to the next agent, and require human review for architecture, security, ownership, and data-contract decisions.

Multica coordinates tasks across agents and providers, but coordination does not semantically reconcile what each agent believes. The product’s documented behaviors make several concrete drift cases predictable: running tasks keep an older Skill copy, resource preparation can fail without blocking a task, and provider-session resume continues one conversation rather than merging knowledge among agents.

This guide was verified against Multica v0.4.10 on July 24, 2026. The governance controls below are team recommendations. Multica does not document an automatic context-consistency engine or a native code knowledge graph.

Why Agent Teams Drift Apart

Multica multi-agent context stays consistent only when every shared item carries an owner, source, version, audience, and expiry rule.

Parallel agents rarely receive identical context. One task may start before a Skill update. Another may run from a newer branch. A third may lack the Project Resource section because a best-effort fetch failed. Even when the prompts match, agents can inspect different files and produce incompatible summaries.

An agent context conflict becomes dangerous when the system hides the difference. Typical examples include:

• one agent says a package owns authentication while current routing points elsewhere;
• two attached Skills use the same concept but prescribe different commands;
• an issue comment records a decision that never reached workspace context;
• a resumed session relies on a file removed in a later commit;
• a graph packet describes the base branch while the task runs on a feature branch;
• a provider-specific permission assumption does not transfer to another provider.

The goal is not perfect agreement. Independent agents should be allowed to disagree. The goal is traceable disagreement: reviewers can see which source, version, and scope produced each conclusion.

Sources of Conflicting Context

An agent context conflict is observable when the task records which context surfaces, revisions, and Skill versions each run actually received.

Multica’s actual context surfaces have distinct failure modes.

Workspace context is shared guidance injected into runs. It can drift from repository policy or become overly broad. Give it a named owner and use it only for stable organization guidance.

Workspace Skills are copied into provider-native locations at task start. Editing a Skill affects newly created tasks; existing runs keep the old copy. Record a Skill version or content hash in every task so review can reproduce what the agent received.

Repository Skills travel with the checkout. If a workspace Skill collides with a repository Skill directory, Multica writes the workspace copy into a collision-free sibling. That avoids overwriting files, but the provider may discover both copies. Directory safety is not semantic reconciliation.

Project Resources supply typed repository or directory pointers. Their preparation is best-effort, so one task can start without the project section or manifest. Treat presence, resource revision, and preparation errors as explicit task metadata.

Provider sessions can resume supported task conversations. Resume preserves that conversation’s state; it does not reconcile summaries between agents or update old conclusions for a new commit.

Searches such as Multica Codex reflect the platform’s multi-provider surface, but provider choice introduces another boundary. Different tools load context files, Skills, MCP configuration, and permissions differently. A shared Markdown file does not guarantee identical enforcement.

Version, Source, and Expiry Rules

The Multica Codex pairing still requires explicit provenance: provider choice does not reconcile stale summaries, divergent Skills, or mismatched repository revisions.

Use a small envelope for every shared context item:

id
type
source
source_revision
content_hash
owner
audience
created_at
expires_at or refresh_trigger
authority
verification_status

The fields do not make a fact correct. They make the fact inspectable.

Choose refresh rules by context type:

• stable workspace conventions: review on policy change and quarterly ownership check;
• Skills: review on provider changes, command changes, permission changes, or failed fixture tests;
• repository facts: rebuild on commit movement relevant to indexed paths;
• task summaries: expire when the branch or acceptance criteria change;
• security and data contracts: require explicit owner approval rather than passive expiry.

Define authority explicitly. Current source and executable behavior support implementation claims. Approved policy controls workflow and security requirements. Architecture records explain intentional constraints. Agent summaries remain interpretations, even when several agents repeat them.

Record timezone and clock source for volatile operational events so ordering can be reproduced across local daemons and the managed service.

Avoid copying entire provider transcripts into the consistency layer. Preserve evidence, decisions, and unresolved questions in a compact task record. Transcripts are useful for debugging, but they carry noise, sensitive data, and model-specific state that should not become shared authority.

Review Workflows for Shared Memory

Run consistency checks at three points.

Before assignment: verify required resources, base revision, Skill hash, and provider adapter. If the task depends on missing context, block it rather than allowing a best-effort run to improvise.

During handoff: require the agent to list evidence inspected, context mismatches, unresolved claims, and any instruction collision. Persist this in the issue, not only the provider session.

Before merge: compare the patch against the task’s recorded context envelope. Re-run affected tests and re-query high-impact repository relationships if the base moved.

A useful conflict workflow is:

1. Preserve both claims and their provenance.
2. Classify the conflict as instruction, source fact, task decision, permission, or ownership.
3. Check revision and scope before judging content.
4. Verify source-fact conflicts in current code or executable behavior.
5. Ask the named owner to resolve policy or architecture conflicts.
6. Record the resolution, affected context IDs, and replacement version.

Do not use voting among agents as an authority mechanism. Agreement can come from a shared stale input. Also avoid “latest timestamp wins”; a newer agent summary may rely on an older repository checkout.

Risks and Escalation Paths

Consistency controls can become bureaucracy if every low-risk observation requires approval. Use risk tiers.

• Low risk: navigation hints and non-authoritative search leads can be refreshed automatically and verified by the consumer.
• Medium risk: module ownership, test mappings, and workflow procedures require source citations and named maintainers.
• High risk: security boundaries, destructive operations, data contracts, compliance rules, and cross-repository write authority require human approval.

Permissions also need independent controls. Workspace roles, agent assignability, personal access tokens, daemon tokens, and underlying tool permissions are not interchangeable. In the current source, Multica’s Claude daemon handler auto-approves tool-control requests for autonomous execution. Contain the daemon with a least-privilege operating-system identity, scoped credentials, and restricted workdir. Do not assume the task queue enforces the coding tool’s filesystem boundary.

When a conflict cannot be resolved before execution, reduce the task to read-only analysis, preserve unknowns, and escalate. Stopping is a valid consistency outcome.

FAQ

Who decides which memory wins?

The authority owner decides after reviewing source, revision, and scope. Current code resolves implementation facts; policy owners resolve organization rules; architecture owners resolve intentional boundaries. An agent summary does not win merely because it is newer.

How should old Skills be retired?

Mark the Skill deprecated, detach it from agents, replace references, and wait for or explicitly stop tasks that still carry the old copy. Archive its hash and migration note so reviews can reproduce historical runs.

What conflicts require human review?

Escalate security, permissions, data contracts, destructive commands, architecture ownership, cross-repository writes, and any material claim that remains unresolved after source verification. Minor navigation hints can be corrected by the consuming agent with evidence.

Is ChatGPT a multi-agent system?

That label depends on the implementation behind a product experience and is outside this article’s scope. The relevant point is operational: in a Multica team, several assigned agents are distinct task actors, and their context must be versioned even if some use the same model provider.

Conclusion

Consistent context is not identical prose in every prompt. It is a controlled set of facts, instructions, and task decisions whose versions and authority are visible. Record the context envelope, detect skew before execution, preserve conflicting claims, and escalate material disagreements. That gives Multica teams a reviewable consistency model without inventing a native shared-memory feature.