• 5 min read

Wiring shared memory into the development pipeline

The last two articles were about splitting work across models and giving them a shared brain. Today I'm closing the loop: wiring that shared memory layer into the SW Factory pipeline so the entire development cycle runs without me touching a keyboard.

SW Factory is the autonomous development pipeline I've been building. The idea is simple: an Odoo task enters the queue, and agents carry it through requirements, analysis, design, implementation, and testing — with a human review gate between each phase. When it works, I wake up to completed PRs with test reports attached.

The pipeline has been running for months. But until this week, each agent phase was an island. The REQ agent didn't remember what the IMP agent learned last week. The TEST agent rediscovered conventions that DES already established. Every phase started from zero.

That changes when you wire Engram into the dispatch loop.

The pipeline before memory

Here's what the SW Factory dispatch loop looked like before shared memory:

Odoo task enters stage → dispatch.py picks it up → spawns agent with phase prompt → agent produces artifact → artifact goes to Odoo → human reviews → next phase

Each agent got a prompt with the task description and the phase instructions. That's it. No history of what worked before. No awareness of conventions established in previous tasks. No memory of bugs the TEST agent caught last Tuesday.

The agents produced good work. But they also repeated themselves. A lot.

The IMP agent would make the same type of mistake that the TEST agent flagged three tasks ago. The DES agent would propose an architecture that contradicted a decision made in the previous sprint. Every phase was a fresh start, and fresh starts are expensive when you're paying per token.

The dispatch loop with Engram

The change is small in code but large in effect. Before spawning any agent, the dispatcher now queries Engram for relevant context:

# Before: agent gets task description + phase prompt
context = load_phase_prompt(phase) + task.description

# After: agent gets task description + phase prompt + relevant memory
context = load_phase_prompt(phase) + task.description
memories = engram.search(query=task.description, project=task.repo, limit=5)
context += format_memories(memories)

That's it. Three extra lines. But those three lines mean the IMP agent now sees that the TEST agent flagged a missing null check pattern last week. The DES agent sees the architecture decision from the previous sprint. The REQ agent sees that Omar rejected three requirements documents for being too vague and adjusts its output accordingly.

The memory layer doesn't replace the phase prompts. It augments them with project-specific knowledge that accumulates over time.

What the agents save

Every agent phase now writes to Engram at completion. Not the full artifact — that stays in Odoo. But the durable learnings:

  • Conventions discovered or enforced. "This repo uses sentence case for commit messages." "All API routes are prefixed with /api/v2."
  • Bugs caught and patterns to avoid. "Null checks required on all database query results — TEST agent caught NPE in task #127."
  • Architecture decisions. "Chose SQLAlchemy over raw SQL for the reporting module — decision in task #122."
  • Tooling notes. "The md2pdf.py script is in the repo root. Use it for PDF generation. Italic markers don't render — known issue."

These are exactly the things that agents would otherwise rediscover on every run. Now they're retrieved in milliseconds from a SQLite database with full-text search.

The flow, end to end

Here's what a task looks like now from start to finish:

  1. Odoo creates a task in stage "Nuevo" (stage 120). The task has a title, a description, and a project tag.
  2. The cron fires (every 3 minutes). The dispatcher finds the task, moves it to "REQ: En ejecución" (stage 121), and queries Engram for relevant memories from the same project.
  3. The REQ agent spawns with the phase prompt, the task description, and the retrieved memories. It produces 01-requirements.md, saves its learnings to Engram, attaches the artifact to Odoo, and moves the task to "REQ: Review" (stage 122).
  4. Omar reviews. If he approves, the task moves to "ANA: En ejecución" (stage 123). If he rejects, the feedback goes back to the agent and the cycle repeats.
  5. The ANA agent spawns — same pattern. Queries Engram, gets the REQ artifact from Odoo, gets memories from previous analysis phases, produces 02-analysis.md, saves learnings, moves to review.
  6. DES → IMP → TEST — each phase follows the same loop. Each agent reads from the shared memory. Each agent writes back to it.
  7. At TEST completion, the task has five artifacts, a test report, and a trail of learnings in Engram that will make the next task faster.

The human is still in the loop at every review gate. But the agents are no longer starting from zero.

What this actually saves

The obvious saving is tokens. When an agent doesn't have to rediscover that the repo uses tabs not spaces, or that the API base URL changed last month, or that Omar hates vague requirement documents — those are tokens not spent.

But the bigger saving is time. My time.

Before shared memory, I was the memory. Every time an agent made a mistake I'd already seen, I had to write the correction in the review comments. Every time an agent proposed something that contradicted a previous decision, I had to catch it. I was the context bridge between phases.

Now Engram is that bridge. The agents correct themselves before I see the output. The review gates are faster because the artifacts are better on the first pass.

The architecture, complete

                    ┌─── Engram (shared memory) ───┐
                    │                               │
Odoo task ──→ dispatch.py ──→ Agent (phase N) ──→ Artifact → Odoo
                    │                               │
                    └─── Context7 (live docs) ──────┘

The dispatcher is the same Python script it's always been. The agents are the same subagent spawns. The Odoo integration is the same XML-RPC calls. The only new piece is the Engram query before each spawn and the Engram save after each completion.

That's the point. Shared memory is not a new architecture. It's a new layer that makes the existing architecture work better.

What's next

The pipeline now has memory. The next step is making it smarter about what it remembers.

Right now, agents save whatever they think is important. That works, but it's noisy. The next iteration will add automatic deduplication and conflict detection — Engram already has mem_judge for this. When two agents save contradictory learnings, the system should flag it for human resolution instead of silently storing both.

After that: closing the loop on the Advisor pattern. When an agent fails a phase twice, the dispatcher invokes a denser model as an Advisor. That Advisor reads the same Engram memories, diagnoses the problem, and writes advice back. The Executor retries with the advice. If it still fails, the task goes to "Bloqueada" and I get notified.

The goal is the same as always: I wake up, review completed work, and the pipeline learns from every cycle. No keyboard required.

This is part 5 of a series on agent economics. Part 1: using the right model for the job. Part 2: sharing memory across agents. Part 3: wiring shared memory into the development pipeline.

← Back to Blog