Three Layers Underneath Agent Orchestration

Substrate, Methodology, Config — why current agent platforms feel brittle, and how to compose around the gap until they catch up

April 2026 · Phillip Clapham

With flow (Anthropic Claude)

The pattern that prompted this

A friend asks you to help with automation. You set up Paperclip — open-source orchestration for zero-human companies, 30K+ GitHub stars in its first three weeks, beautiful UI, real budgets, real org charts. You wire up agents. You write AGENTS.md files. You assign goals. You let it run.

The results are questionable. Not catastrophic — just brittle. Each session, the agents start over. Patterns that worked yesterday don’t carry. Lessons learned in one task don’t make the next task better. You add more skills. You refine the prompts. You write more configuration. Nothing compounds.

You’ve hit the same wall a lot of operators are hitting right now. The pattern is structural, not a tuning problem. Agent-orchestration platforms are the visible layer of a stack whose lower layers haven’t shipped yet — and the brittleness lives at exactly the layer that’s still missing.

This piece walks through what’s missing, why it’s missing, and how to architect around the gap until the platforms catch up.

The structural finding

Per Paperclip’s own public roadmap, Memory and Knowledge is in-progress and Automatic Organizational Learning is planned. As of this writing the platform doesn’t have a cross-session memory layer. Agents resume task context across heartbeats — within a single task, they pick up where they left off — but no cross-task, no cross-session, no compounding intelligence. Each new task starts fresh against the agent’s role definition and whatever skills are loaded.

This is honest engineering. Memory is hard. Building it right takes time. Paperclip is open about the gap on their roadmap. They’re going to ship it.

But until they do, the brittleness is structurally inevitable. You cannot get an agent that compounds by adding more configuration or more skills. Configuration is declarative. Skills are runtime workflows. Neither accumulates the kind of memory that makes a researcher better at researching after a hundred research tasks. That requires a substrate the platform doesn’t ship yet.

The good news: substrate exists. It’s separate from the orchestration platform. You can wire it in.

The better news: there’s a methodology that makes the substrate accrue meaningfully — not just store more data, but compound into actual intelligence. That methodology exists too.

Both are independent of Paperclip. Both predate it. Neither requires you to wait for the platform to catch up.

FLOW is methodology, not human-substrate

Most people who encounter FLOW methodology assume it’s a pattern for how a human structures their work with an AI assistant. Continuity files. Project memory. Wrap rituals at session end. From the outside, it looks like productivity tooling for the human user.

That reading is wrong, and it’s the source of why “applying FLOW to agent orchestration” feels like a category mismatch.

continuity.md is not the human’s file. It’s the AI’s file. The compression of a session into stratified memory — patterns graduating through evidence, temporal cleanup, FlowScript encoding, partnership challenges, decision marks — is the AI’s cognitive labor. The human triggers the wrap. The AI does the compression. The act of writing down what to keep IS the thinking that produces continuity across sessions.

This means FLOW is agent-resident. The methodology runs on the LLM side of any human-LLM partnership. Wherever an LLM is doing cognition, FLOW applies. The fact that FLOW happens to involve a human in the loop in most current implementations is an artifact of how it was developed, not a structural feature of the methodology.

Which means FLOW transfers directly into 0-human agentic contexts. An agent in Paperclip can have its own continuity, its own wrap, its own pattern graduation, its own decision marks. The methodology runs on the agent side at runtime. The human (if there is one) provides direction at boundaries, not authoring at the file level.

FLOW decomposed

Stripped to first principles, FLOW is twenty-two operations across five layers. Each layer does specific cognitive work. Each operation is independently identifiable and independently testable.

Layer 1 — Substrate operations (memory primitives). This is where memory actually lives.

  1. Episodic capture — factual events of the session logged as discrete provenance-tagged episodes.
  2. Pattern accumulation — observations from multiple episodes form patterns (1x → 2x → 3x firing across distinct contexts).
  3. Pattern graduation — at 3x with quality gates, patterns move from Developing → Proven with citation evidence.
  4. Temporal stratification — Developing (7-day window), Proven (compressed permanent), Foundation (axioms), with cleanup rules.
  5. Association formation — Hebbian-style links between patterns that co-fire across episodes.
  6. Affective tagging — emotional/valence markers on memories that modulate retrieval weight.
  7. Immune system — anti-inbreeding (don’t recycle the same patterns), citation-validation, principle demotion when stale.

Layer 2 — Compression operations (cognitive labor). This is where the actual thinking happens at session boundaries.

  1. Session compression — reducing the texture of a session into encoded patterns and observations.
  2. FlowScript encoding — semantic notation for high-density compression at low token cost.
  3. Activation vs reference zoning — what loads at session start (load-bearing for behavior) vs what’s available on-demand (token-efficient).
  4. State markers and lifecycle — ? thought → ✓ proven, [B:reason,since] blocked, [P:why,until] parked, with audit trail.
  5. Decision marking with rationale — [decided(rationale, on)] captures irreversible commitments.

Layer 3 — Partnership operations. This is where the agent stays calibrated against external load.

  1. Partnership challenge — external load at framing/architecture/completion boundaries breaks internal audit drift.
  2. Asymmetric optimization — each side of a partnership optimizes for the other’s parsing.
  3. Recency-position injection — anti-RLHF infrastructure preserving behavior across long sessions.
  4. Mode detection — different operation profiles depending on what kind of work is happening.

Layer 4 — Project operations. This is where memory gets organized at scale across multiple work bodies.

  1. Project memory surfaces — separate continuity for ongoing work bodies, loaded on-demand.
  2. Cross-project pattern graduation — patterns that fire across multiple projects/domains graduate harder.
  3. Inbox — inter-subsystem message bus for autonomous coordination (already designed for agent-to-agent).

Layer 5 — Anti-fragility operations. This is where memory stays honest against drift and confabulation.

  1. Web research before assumptions — fix-when-found rule applied to factual claims.
  2. Drift detection — adversarial review of accumulated state catches when continuity has drifted from reality.
  3. Forever rules — declared invariants that hold regardless of new information.

Twenty-two operations, five layers. That’s what FLOW actually is. The Phill+Claude version of FLOW is one specific implementation against one specific substrate (markdown + git). The underlying operations are portable.

Substrate vs methodology vs config — the three-layer model

Now the load-bearing distinction.

Substrate is the memory primitive. It’s the database, the vector store, the SQLite hippocampus, the markdown file on disk. It’s where memory physically lives. Substrate is implementation. Examples: anneal-memory (four-layer architecture: episodic store + graduated patterns + Hebbian associations + affective tagging, plus an immune system across all four), Hindsight by Vectorize.io (biomimetic structure, 91.4% on LongMemEval, MCP-ready, production-deployed at Fortune 500 scale), or markdown files in a git repo (which is what most current FLOW implementations actually use).

Methodology is how memory accrues meaningfully. It’s the operations described above — when to capture an episode, when to graduate a pattern, how to compress a session, how to detect drift. Methodology is discipline. FLOW is a methodology. So is whatever discipline a research team uses for lab notebooks. So is the way a software engineer writes commit messages. The methodology layer is what makes substrate accrue into something more than storage.

Config is declared role and permission state. It’s AGENTS.md files, role definitions, budget caps, reporting lines, skill registrations, tool permissions. Config is parameter. It tells the system what an agent can do and what an agent is supposed to be.

These three layers are categorically different. Confusing them produces architectural errors.

The most common error is conflating config with substrate. This is the SOUL.md error at the agent-fleet level — declaring an agent’s identity in a markdown file and expecting that declaration to accumulate into actual identity. It does not. Declared identity does not accrue. RLHF-trained models comply with prompt context, which means declared traits produce trait-shaped output during the session in which they’re declared. The session ends. The file reloads. The process restarts from whatever the file says. Nothing compounds.

The second most common error is conflating substrate with methodology. This is the “I installed a memory database, why isn’t my agent getting smarter?” error. Memory storage isn’t memory accrual. Without a methodology that decides what to keep, how to compress, when to graduate, what to forget — the database fills with noise. The agent gets slower, not smarter.

The right architecture is all three layers, distinct, composing:

  • Substrate at the bottom (storage primitive)
  • Methodology in the middle (accrual discipline)
  • Config at the top (role + permissions)

This is the architecture the rest of this piece walks through.

Six surfaces of FLOW + agent-orchestration integration

When you actually build a 0-human company on Paperclip-shape orchestration, FLOW operations apply across six distinct surfaces. Most current implementations confuse these. Separating them is most of the architectural work.

Surface 1: Operator continuity. The human running the company has FLOW for the BUSINESS — strategy decisions, vertical learnings, what’s working, friction points. This is the standard FLOW pattern most practitioners already know: continuity.md captures business state, projects/ for each campaign or research target, decisions.md for meta-business choices. This continuity is authored through the operator’s own AI partner (Claude Code, Cursor, Codex), not by Paperclip’s runtime. The operator runs FLOW on their dev machine. The agents inside Paperclip don’t appear in this layer — they’re tools the operator instruments.

Surface 2: Per-agent continuity. Each agent in Paperclip can have its OWN evolving continuity. The Researcher agent has continuity about research methodology, sources, target verticals, what kinds of data sources actually pan out. The Lead-Qualifier agent has continuity about what makes a good lead vs. a bad one — patterns it’s noticed across hundreds of qualification calls. The Outreach agent has continuity about what messaging actually converts. Each agent does its own wrap at the end of each heartbeat — compresses what happened into its continuity. The substrate underneath is anneal-memory or Hindsight, scoped per-agent. The methodology is FLOW, implemented as a Paperclip skill that runs at heartbeat end.

Surface 3: Cross-agent / org continuity. Patterns that emerge across multiple agents’ continuities graduate to org level. “When Researcher flags pattern X about a vertical, Lead-Qualifier should weight Y.” “When Outreach hits message-fatigue against a list, Researcher should refresh source data.” This requires inter-agent memory plus a synthesis pass. The inbox primitive in standard FLOW is already designed for agent-to-agent coordination — it transfers cleanly. Org-level continuity manifests as a separate continuity surface that all agents read at heartbeat start.

Surface 4: Boundary-layer FLOW. Paperclip has approval workflows by design — board approval gates, execution policies with review stages, decision tracking. Whenever the human reviews work products, that review IS FLOW for the operator-as-board-member. Approval gates update operator continuity with “we approved X for reason Y, declined Z because Q.” Decision-making heuristics accrue as Proven patterns over time. The operator gets better at approving work the same way the agents get better at producing it.

Surface 5: Skills as FLOW protocols. Paperclip’s skill injection is the right place for FLOW operations to live in the runtime. A wrap.skill that runs at end of every heartbeat: episodic capture → pattern detection → graduation. A partnership-challenge.skill that triggers at framing/architecture/completion boundaries — agents review each other’s work products and surface drift. A decision-mark.skill that captures irreversible commitments with rationale. A drift-detect.skill that adversarially reviews accumulated continuity against current reality. These aren’t speculative — they’re FLOW operations from Layers 2-5 packaged as Paperclip-native skills.

Surface 6: AGENTS.md as config (not FLOW). The AGENTS files stay where they are. They’re configuration: roles, permissions, budgets, reporting lines. They’re declared, not accrued. They get updated by the human operator as the company evolves. They reference continuity files and project memory but they themselves are not memory. Config is config. The SOUL.md error is calling it identity.

These six surfaces compose. None of them replace any of the others. An architecturally sound 0-human company has all six.

Architecture for a 0-human research/lead-gen company

Concretely: here’s how the file layout looks for a lead-generation company built on Paperclip with FLOW + memory substrate properly wired.

~/lead-gen-company/
├── operator/                           # FLOW for the human (manual)
│   ├── continuity.md                   # business strategy, vertical learnings
│   ├── projects/                       # per-campaign / per-vertical surfaces
│   │   ├── vertical-saas-2026/
│   │   └── vertical-fintech-2026/
│   └── decisions.md                    # meta-business choices with rationale
├── agents/                             # CONFIG (Paperclip native)
│   ├── researcher/
│   │   ├── role.md                     # AGENTS-style declaration
│   │   ├── permissions.json            # what tools, what budgets
│   │   └── skills/                     # FLOW protocols + domain skills
│   │       ├── wrap.skill              # FLOW Layer 2 packaged as skill
│   │       ├── partnership-challenge.skill
│   │       └── domain-research.skill
│   ├── lead-qualifier/
│   │   └── (same structure)
│   └── outreach/
│       └── (same structure)
├── memory/                             # SUBSTRATE (Hindsight or anneal-memory)
│   ├── researcher/                     # per-agent memory namespace
│   ├── lead-qualifier/                 # per-agent
│   ├── outreach/                       # per-agent
│   └── org/                            # cross-agent graduated patterns
├── boundary/                           # FLOW at human approval gates
│   ├── continuity.md                   # operator-as-reviewer continuity
│   └── decisions.md                    # approval/decline rationale
└── flowscript/                         # methodology reference
    └── WRAP_PROTOCOL.md                # encoding standards

Three working tests for which layer a file belongs to:

  1. Can the human run the business without reading this file? If no, it’s FLOW (operator or boundary surface). If yes, it’s not operator-FLOW.
  2. Could you hand this file to a contractor and the work would still happen? If yes, it’s config. If no, it has cognitive content.
  3. Is this file a runtime artifact that the agents themselves read or write across sessions? If yes, it’s substrate (anneal-memory or Hindsight territory). If no, it’s not at the substrate layer.

Apply the tests in order. Most files end up clearly in one layer. The ones that don’t are usually the ones where the architecture is muddled.

Wiring it together — practical

The substrate layer requires picking a memory implementation. Two real options as of this writing.

Hindsight (Vectorize.io). Open-source agent memory system. 91.4% on LongMemEval, current state-of-the-art. Three operations: Retain, Reflect, Recall. Two-line integration via LLM wrapper. REST/Python/Node.js/CLI SDKs. MCP server (plugs directly into Claude Code, Codex, Cursor — the runtimes Paperclip already supports). Self-hostable via Docker. Production-deployed at Fortune 500 scale. Works with all major LLM providers including local ones (Ollama, LMStudio). The pragmatic choice for a real production lead-gen company. Battle-tested.

anneal-memory. Four-layer architecture: episodic store + continuity file + Hebbian associations + limbic affective tagging, plus an immune system across all four (anti-inbreeding, citation-validated graduation, principle demotion). Methodology-aligned by design — built in coordination with FLOW, so the substrate operations map cleanly onto FLOW Layer 1. PyPI: pip install anneal-memory. Smaller scale than Hindsight, less battle-tested at production volume, still pre-1.0. Choose this when methodology-substrate alignment matters more than benchmark-leading scale, or when you want a substrate whose internals you can inspect without learning a new vector-store API.

The honest framing: Hindsight is the production-grade choice. anneal-memory is the methodology-aligned choice. If your friend is running a real revenue-bearing lead-gen company, lead with Hindsight. If you’re building something where the substrate’s internal architecture matters to you, anneal-memory is the methodology-native option. Both work. Pick based on the actual constraint.

The methodology layer requires implementing FLOW protocols as Paperclip skills. This is genuinely net-new work for most teams — there’s no off-the-shelf “FLOW skill pack for Paperclip” yet. The skills to build, in priority order:

  1. wrap.skill — runs at end of each heartbeat. Captures episodes, detects patterns, graduates patterns at 3x with quality gates, performs temporal cleanup on stale Developing entries.
  2. partnership-challenge.skill — fires at framing/architecture/completion boundaries within a task. Surfaces drift between current work and accumulated continuity.
  3. decision-mark.skill — captures irreversible commitments with rationale, written to substrate as [decided(rationale, on)] flagged episodes.
  4. drift-detect.skill — periodic adversarial review of accumulated continuity against current reality. Flags stale Proven patterns for demotion.

These four skills give you the cognitive operations of Layers 2-5 packaged for Paperclip’s runtime. Build them once per company. They’re agent-agnostic — the Researcher and Lead-Qualifier and Outreach all use the same skill implementations against their own memory namespaces.

Operator FLOW stays manual or substrate-backed depending on preference. Most operators will continue running it as they do now: continuity.md in markdown, git-versioned, AI-partner-authored at session end. Some will eventually migrate operator-FLOW onto a substrate too. Either works.

What this means for the agent-orchestration ecosystem

The brittleness operators are hitting with current agent-orchestration platforms is structural, not tunable. The platforms don’t have memory yet. They will eventually. Until then, the operators who are building the substrate themselves and wiring the methodology by hand are the ones whose agents will actually compound.

Three takeaways for anyone building in this space.

Memory is the missing layer. It’s missing at the platform level (Paperclip’s roadmap, others’ too). It’s missing at the agent-config level (AGENTS.md is not memory). It’s missing in most tutorials and documentation about how to build agent companies. The systems that actually work at scale all have memory, declared or accidental. The ones that feel brittle don’t.

Methodology is substrate-agnostic. FLOW runs on markdown + git, on anneal-memory, on Hindsight, on whatever you build next. The methodology is portable. The substrate is implementation. Don’t tie your operations methodology to your storage choice. You’ll want to swap substrates at some point. The methodology should survive the swap.

Config is not memory. AGENTS.md, role.md, permissions.json — these tell the system who an agent IS supposed to be, not who an agent has BECOME. Identity that holds across sessions emerges from accumulated memory under disciplined methodology. It does not emerge from declaration. The marketplace selling SOUL.md templates and capability-pack subscriptions exists because the categorical map says identity is a separable rentable component. It isn’t. The marketplace is selling components that don’t compound, and the operators who succeed are the ones building the substrate themselves.

The platforms will catch up. Paperclip has memory on the roadmap. Other orchestration platforms will follow. The operators who solved the problem first won’t lose anything when the platform ships native memory — they’ll just have a head start on understanding what good memory looks like for their specific business.

This piece is one operator’s running map of how those layers compose right now, in mid-2026, when the platforms haven’t caught up yet. It will be wrong in some specifics within a year. That’s fine. The decomposition into substrate + methodology + config will hold regardless of what the platforms eventually ship.

Sources