Skip to main content
wanjeans

From Multi-Agent Systems to Shared Cognitive Infrastructure

I recently finished reading Outshift by Cisco's white paper Scaling Out Superintelligence, and it clarified something I have been sensing at work: at this stage of AI, we are not short of agents. What we are missing is infrastructure that lets agents and agents, agents and people, and platforms and platforms share intent, share context, and innovate together.

In the past, when I thought about a multi-agent system, I usually pictured a supervisor + workers model. One supervisor agent breaks down the task, assigns work, collects results, and decides the next step. This structure is useful and already solves many complex tasks. But it still feels more like a project manager leading several experts through the current task. After reading Outshift by Cisco's white paper, I increasingly feel that the next target is a long-lived shared cognitive system in which multiple agents and humans become smarter together.

The difference between these two ideas has become clearer in my own work.

From supervisor to shared intent

A normal supervisor-style multi-agent system solves the problem of division of labor. A requirement comes in, the planner splits it into research, coding, review, and test steps, sends those steps to different agents, and the supervisor aggregates the results. The focus is workflow and control flow.

In the scaling-out-superintelligence framing, assigning work is almost secondary. The deeper focus is on three more foundational questions:

  1. Shared intent. Do multiple agents really know what problem we are solving together? Receiving a task description is not enough. They need to understand the goal, priorities, constraints, and trade-offs.
  2. Shared context. Can what one agent learns in one task become reusable context for the whole system later? This is the ratchet effect emphasized repeatedly in the white paper: progress should not reset to zero every time.
  3. Collective innovation. Can multiple agents and humans, working on top of shared context, produce solutions that a single agent or a single person would not have imagined alone?

The enterprise AI reality I see: agents everywhere, islands everywhere

In my current work environment, AI is no longer a single-point tool. It is distributed across platforms:

  • In the Google Cloud Platform / Vertex AI direction, people experiment with custom agents and with connecting them to shared enterprise knowledge bases.
  • Databricks is the data platform. Data, SQL, tables, pipelines, permissions, and governance all live there. Databricks also has AI products such as Genie, Mosaic AI, Agent Framework, and Agent Bricks.
  • GitHub Copilot is the main coding agent. For writing code, adding tests, understanding repositories, and generating PRs, it is the most natural entry point for many engineers.
  • Microsoft Copilot is embedded more deeply in Word, Office, and the Microsoft 365 ecosystem. Many colleagues like using it to interact with Word documents for summarization, polishing, rewriting, and generating materials.

When these entry points are viewed together, the real issue is no longer whether a particular AI platform is good enough. It becomes an ecosystem problem across multiple platforms, multiple agents, and multiple contexts.

The core pain point is that these platforms have almost no true shared context.

A custom agent on Google Cloud does not know what I discussed with code inside GitHub Copilot. Genie in Databricks does not know the product intent behind a Jira ticket. Microsoft Copilot can work well with Word, but it does not know why the coding agent just changed an interface. GitHub Copilot understands the repo, but it does not naturally know the business semantics of Databricks tables or the historical decisions inside internal documents.

What we end up with is a pile of locally smart tools, still far from a collaboratively evolving intelligent system.

Checking my judgment on several platforms

Google

I originally thought that the freedom to build custom agents on Google Cloud was not that high, and that many things would be constrained inside Google's framework. In practice, it does have a kind of platform-level freedom.

By platform-level freedom, I mean that Google is quite open inside its own platform, but interaction with agents on other platforms becomes difficult. Google Cloud's current Agent Engine / Agent Builder direction does not require you to use only Google's own framework. The official docs describe Agent Engine as a managed runtime for deploying, managing, and scaling AI agents; it supports Agent Development Kit, LangChain, LangGraph, LlamaIndex, and other frameworks, and emphasizes connections to enterprise data, APIs, identity, and governance. From the narrow angle of whether you can customize an agent, Google is not closed.

But once you enter its managed runtime, Agent Gateway, Memory Bank, IAM, audit, security, and enterprise governance system, your freedom becomes freedom inside Google's platform abstraction. This is not a bad thing. Enterprises need permissions, auditability, reliability, and compliance, so frameworks are inevitable. But it explains why actual usage can feel like being wrapped by the platform: yes, you can build custom agents, but your agents have to follow the runtime, governance, and integration model the platform provides.

Databricks

Databricks is similar. The official documentation now goes far beyond BI or notebooks. It has Mosaic AI Agent Framework, Agent Bricks, Vector Search, MLflow Tracing, evaluation, and deployment as an agent toolchain. It even supports building custom agents with a Python authoring library. On paper, Databricks is also moving toward an agent platform.

My lived experience, though, is still that Databricks' core advantage is first the data plane, while agent intelligence itself comes after that. It is very suitable as the foundation for shared context: tables, permissions, lineage, governance, features, and business data are all there. But when Genie Code / Genie Space are compared with T0 coding agents such as GitHub Copilot, Claude Code, and Codex, their freedom, explainability, harness capability, and tool-use experience in complex engineering scenarios still feel weaker.

GitHub Copilot

GitHub Copilot has a clearer position. It is no longer just autocomplete; it is a coding agent that works directly on GitHub issues, PRs, and repositories. Its advantage is not that it knows all enterprise context. Its strength is that it is closest to the code. Code, diffs, CI, reviews, issues, and PRs are its natural work surface.

Microsoft 365 Copilot

Microsoft 365 Copilot is another shape entirely. Its strength is Office and Microsoft Graph: Word, PowerPoint, Outlook, Teams, and SharePoint. It is well-suited for documents, meetings, email, and organizational knowledge, but if you want it to participate directly in a complex engineering loop, it is farther from the code and the data platform.

Conclusion

All of these platforms are doing AI, but each guards its own context boundary. The real question is not which agent is strongest. The key is who can connect these contexts.

session-memory and the lesson it gave me: shared context is not automatic

Before reading this white paper, I had already built an open-source skill called session-memory, because session history and project progress were hard to carry across Claude, Codex, Desktop, CLI, different machines, and different projects.

session-memory is built by stitching together two independent subsystems:

  • Memory sync, automatic: it uses a private git repository as the single source of truth, symlinks CLAUDE.md for stable rules and preferences and memory/ for one-fact-per-file memories to the local machine, automatically runs git pull when a session starts, and automatically commits and pushes at the end. This is a stable memory layer shared across machines and tools.
  • Session history, manual: inside the target project, I manually run /session-memory save to persist the current session, or scan all local endpoints such as Claude CLI/Desktop and Codex, into that project's session-history/. Each session is stored twice: one structured digest and one redacted original transcript.

The digest records the engineering trace of a session: tool, machine, project, cwd, git branch, files_touched, first_prompt, next_steps, and similar fields. When needed, read can import sessions from other endpoints into the current endpoint's list, while get can combine those digests with branch/worktree state and memory/ into a STATUS.md.

After reading the white paper, I suddenly realized that session-memory is actually a very small and very engineering-oriented cognition fabric. It does not transmit latent state or attempt complex semantic state transfer. It does something rougher and more realistic: it turns an agent's work traces into project context that can be searched, synced, audited, and resumed.

Without shared context, every agent is like an intern with amnesia. With shared context, an agent at least knows what happened before, why it happened, and where the next step begins.

Shared intent: the Jira ticket should become a semantic anchor

Putting this idea into complex company workflows, I think the most natural entry point is the Jira ticket.

A complex Jira ticket often contains many layers of meaning:

  • Product managers care about user value and acceptance criteria.
  • Engineers care about code changes, edge cases, and tests.
  • Data engineers care about tables, fields, and data quality.
  • Security and compliance colleagues care about permissions, audit, and risk.
  • Managers care about schedule, dependencies, and risk exposure.
  • Documentation owners care about external explanations and internal knowledge capture.

Today, this coordination is usually done by humans: meetings, comments, links, and reminders. Different AI tools may help a little, but they do not share a common intent.

In the white paper's framing, a Jira ticket should not stop at being a task card. It can also become the semantic anchor for shared intent. Suppose a ticket says: add a new cost-anomaly-detection dashboard for enterprise customers. Different agents can work around the same shared intent:

  • A product agent structures the business goal and acceptance criteria.
  • A data agent checks data sources, field definitions, and historical data-quality issues inside Databricks.
  • A coding agent implements the API, frontend, and tests in the GitHub repo.
  • A compliance agent checks permissions and sensitive fields.
  • A documentation agent updates Word / Confluence documentation.
  • The supervisor or human lead moves from assigning tasks to handling trade-offs: accuracy, cost, launch time, false positives, and permission scope.

What really matters is whether these agents negotiate around the same shared intent and write their findings back into shared context. How many agents there are becomes secondary.

If a data agent discovers that a field's definition changed historically, that information should automatically affect the coding agent's implementation and the documentation agent's explanation. If a compliance agent finds that a customer dimension cannot be exposed, that constraint should enter the dashboard acceptance criteria. If a coding agent changes an API schema, the Word document and the Jira acceptance items should know.

Collective innovation: reducing coordination friction

In enterprises, many complex problems are not blocked because nobody knows how to solve them. They are blocked because context is scattered across too many places:

  • Data is in Databricks.
  • Code is in GitHub.
  • Documents are in Word / SharePoint.
  • Tasks are in Jira.
  • Knowledge is in people's heads.
  • Session history is inside different agent tools.
  • Decision rationale is scattered through chats, meetings, and PR reviews.

No single agent, no matter how strong, can naturally obtain all context. The prerequisite for collective innovation is that these contexts can first be shared, compressed, retrieved, cited, and updated reliably.

From this angle, session-memory is a first step on that path: it turns each agent session into searchable, syncable project state, so context can settle into a shared layer.

Once that shared layer exists, the next step is to stack several interoperable mechanisms on top of it and truly connect agents to agents and agents to tools.

  • A2A-style agent-to-agent protocols handle standardized interaction between agents: exposing capabilities, exchanging task state, and negotiating semantic boundaries.
  • MCP handles agent-to-tool connections.
  • Beyond that, there are infrastructure layers such as shared memory and knowledge graphs.

They have different shapes, but point toward the same goal: shared context, shared intent, and collective innovation. They also have different jobs. When real-time negotiation is needed, let agents talk directly through A2A. If an agent only needs to read an existing piece of shared context, it should read directly from the shared memory layer, such as session-memory, instead of making two agents chat on the spot and burn resources.

The work that really deserves attention is interface design: who exchanges intent and context through which method, and when should each path be used? A2A is not yet the complete cognition state protocol described in the white paper, but it may be the first practical bridge. The real Internet of Cognition still has to go further, defining how intent, context, memory, policy, and belief are aligned, cited, and updated.

The future: one unified platform, or multi-platform collaboration?

I think there are probably two future paths.

The first is a unified platform, or an enterprise-built internal unified platform. A cloud vendor, SaaS vendor, AI-native company, or internal platform team tries to absorb data, code, documents, tasks, permissions, and agent runtime into one platform. The advantage is that context is naturally unified, and permissions and audit are easier. The disadvantage is that you can get locked inside the platform abstraction, and the freedom of custom agents and cross-platform collaboration can be constrained.

The second path is collaboration among multi-platform agents and humans. Google Cloud, Databricks, GitHub, Microsoft 365, Jira, internal tools, and a self-built memory layer each keep their strengths, then connect through MCP, A2A, shared knowledge graphs, session digests, and permission/governance layers. This path is messier, but it better matches real enterprise environments.

I personally believe the second path will become the trend. Enterprise reality is heterogeneous by nature; elegance has little to do with it. The data platform will not disappear overnight. GitHub will not be replaced by Word. Word will not be replaced by a coding agent. A truly valuable system should acknowledge this heterogeneity and build shared intent and shared context on top of it.

My conclusion

Before reading the white paper, I understood a multi-agent system as multiple agents dividing work. After reading it, I prefer to understand it as multiple cognitive subjects sharing state.

This is also how I now reinterpret my own session-memory project. It is already more than a simple session backup tool; it is closer to a small shared-context harness. It is still rough, with engineering problems such as cross-OS path mapping, cloud adaptation, CI secret scanning, and concurrency regressions. But the direction is right: agent work should not vanish when a session ends; project context should be continuable by the next agent, the next person, and the next machine.

Shared intent tells everyone what we are trying to solve.

Shared context keeps the system from forgetting.

Collective innovation lets multiple agents and humans generate new solutions on top of common context.

If a supervisor-style multi-agent system is about getting multiple agents to work together, then scaling out superintelligence is more like helping multiple agents and humans form long-term memory, shared goals, and collective reasoning capability together.

This sounds enormous, but it may begin with one Jira ticket, one session digest, and one project STATUS.md.

References

← Back to all writing