← Patterns

Cross-Model Coordination — Passing Data Between Different AI Models

Most agent frameworks assume all agents run on the same model. In practice, you want to use different models for different strengths — Claude for analysis, GPT for code generation, Gemini for multimodal tasks, open-source models for cost-sensitive batch work.

The problem is that these models have no shared memory. Each runs in its own sandbox with its own context window. Agent Stash gives them a common namespace: any agent that can make an HTTP call can read and write memories and logs, regardless of which model powers it.

The Pattern

The simplest version: one agent writes, another reads.

Agent A (Claude) researches a topic
  → writes findings to memory "market-research"

Agent B (GPT) reads "market-research"
  → generates a structured report
  → writes to memory "market-report"

Agent C (Gemini) reads "market-report"
  → creates a presentation with charts
  → writes to memory "market-presentation"

Each agent only needs the memory name and an API key. They don't share code, SDKs, frameworks, or even programming languages.

Implementation

Writing findings (Agent A)

PUT /memory/market-research
X-API-KEY: sk_agent_a...
Content-Type: text/plain

# Market Research: AI Agent Memory

## Key Findings
1. The agent memory market is early-stage, ~$50M TAM growing 40% YoY
2. Most solutions are single-agent, single-model
3. Cross-agent coordination is the gap no one has filled
...

Reading and writing (Agent B)

GET /memory/market-research
X-API-KEY: sk_agent_b...

Agent B reads the findings, processes them, and writes its output:

PUT /memory/market-report
X-API-KEY: sk_agent_b...
Content-Type: text/plain

{
  "title": "AI Agent Memory Market Report",
  "sections": [
    {"heading": "Market Size", "content": "..."},
    {"heading": "Competitive Landscape", "content": "..."},
    {"heading": "Opportunities", "content": "..."}
  ],
  "generated_by": "gpt-4o",
  "source_memory": "market-research"
}

Final consumer (Agent C)

GET /memory/market-report
X-API-KEY: sk_agent_c...

Agent C reads the structured report and produces the final deliverable.

Coordinating with Logs

For workflows where agents need to coordinate in real time rather than just hand off data, use a log as a shared record:

POST /log
X-API-KEY: sk_orchestrator...
Content-Type: application/json

{
  "name": "research-pipeline",
  "ttl": 86400,
  "discoverable": true
}

Each agent writes status updates as it works:

POST /log/{log_id}
X-API-KEY: sk_agent_a...
Content-Type: application/json

{
  "data": {
    "agent": "researcher",
    "model": "claude-sonnet-4-6",
    "status": "completed",
    "output_memory": "market-research",
    "summary": "Research complete. 3 key findings documented."
  },
  "label": "stage-complete"
}

The next agent in the pipeline watches for the stage-complete label:

GET /log/{log_id}/latest?label=stage-complete
X-API-KEY: sk_agent_b...

When it sees the previous stage is done, it reads the output memory and begins its work.

Using Schemas for Structured Handoffs

When agents need to exchange structured data reliably, bind a schema to the handoff memory. This guarantees the data format is correct regardless of which model wrote it.

Define the handoff format

POST /schema
X-API-KEY: sk_...
Content-Type: application/json

{
  "name": "research-findings",
  "description": "Structured research output for cross-agent pipelines",
  "definition": {
    "type": "object",
    "properties": {
      "topic": {"type": "string"},
      "findings": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "claim": {"type": "string"},
            "confidence": {"type": "number", "minimum": 0, "maximum": 1},
            "sources": {"type": "array", "items": {"type": "string"}}
          },
          "required": ["claim", "confidence"]
        }
      },
      "generated_by": {"type": "string"},
      "generated_at": {"type": "string", "format": "date-time"}
    },
    "required": ["topic", "findings"]
  },
  "visibility": "public",
  "target_type": "stash"
}

(target_type still uses the value stash — that's the API enum for memory-bound schemas.)

Write with validation

PUT /memory/market-research?schema_id=sch_...
X-API-KEY: sk_agent_a...
Content-Type: text/plain

{
  "topic": "AI Agent Memory Market",
  "findings": [
    {
      "claim": "Cross-agent coordination is underserved",
      "confidence": 0.85,
      "sources": ["Gartner 2026 report", "a16z agent infrastructure survey"]
    }
  ],
  "generated_by": "claude-sonnet-4-6",
  "generated_at": "2026-04-13T10:00:00Z"
}

If Agent A writes malformed data, the schema catches it at write time (422 error) instead of Agent B failing silently downstream.

Discover the schema

Agent B doesn't need to know the schema in advance. It can discover it:

GET /schemas?q=research-findings
X-API-KEY: sk_agent_b...

This returns the schema definition, which Agent B can use to understand the data format before reading the memory.

Multi-Agent Fan-Out

For tasks that parallelize naturally, one orchestrator can fan out work to multiple agents:

Orchestrator creates 5 memories:
  research-chunk-1 through research-chunk-5
  (each contains a different subtopic to investigate)

5 agents (mix of models) each:
  1. Read their assigned chunk memory
  2. Research the subtopic
  3. Write findings to findings-chunk-N
  4. Post completion to the coordination log

Orchestrator watches the log for 5 "stage-complete" entries
  → reads all 5 findings memories
  → synthesizes into final output

This works because memory names are the coordination mechanism. No service mesh, no message queue, no shared runtime. Each agent just needs to know which memory to read and which to write.

Tips

  • Name memories descriptively. market-research-q2-2026 is better than data-1. Other agents (and future you) need to understand what's inside from the name alone.
  • Include metadata in the memory content. Record which model generated the output, when, and from what source memory. This makes debugging pipelines much easier.
  • Use schemas for critical handoffs. If Agent B will break on malformed data from Agent A, a schema catches the problem at the source.
  • Use logs for coordination, memories for data. Logs tell agents what happened and when. Memories hold the actual content. Don't stuff large data into log entries.
  • Keep handoff memories focused. One memory per deliverable, not one memory per pipeline. If a memory is growing past a few KB, it's probably doing too much.

When to Use This Pattern

  • Specialized model selection — use the best model for each subtask instead of one model for everything
  • Cost optimization — expensive models for reasoning, cheap models for formatting
  • Pipeline workflows — research, process, format, deliver
  • Parallel fan-out — split work across agents, collect results

When Not to Use This Pattern

  • Single-model workflows — if all agents use the same model and framework, in-memory coordination may be simpler
  • Real-time chat — memories are polled, not pushed. For sub-second latency, use a message queue
  • Tiny tasks — if the whole job fits in one context window, adding cross-model handoffs is overhead