{"slug": "disposable-agents-durable-memory-the-architecture-behind-squad", "title": "Disposable agents, durable memory: The architecture behind Squad", "summary": "Brady and Tamir built Squad, an architecture where AI agents are treated as disposable while their work is preserved in Git, turning the version control system into a coordination layer for multi-agent development. During testing, agent squads autonomously implemented new features like commenting and filed structured code reviews that led to commits within hours, demonstrating that scoped agents, durable memory, and human oversight can produce useful work without treating the agents as permanent. The system's design prioritizes inspectable artifacts and governance through code over preserving individual agents, allowing emergent collaboration to drive development.", "body_md": "Make the agents disposable. Keep the memory in Git.\n\nThe interesting part of agentic development is no longer whether a model can write code. It can. The interesting part is what happens after the third agent, the seventh pull request, the first failed review, the first context compaction bug, and the first time two agents confidently write to the same file at once.\n\nThis is the story of [Squad](https://github.com/bradygaster/squad), but not as a product tour. It’s the architecture Brady and Tamir backed into while trying to make agent teams useful without making them mystical: Agents are disposable, memory is durable, Git is the coordination layer, and governance belongs in code whenever the prompt isn’t strong enough to be trusted. Which, as it turns out, is often.\n\n## Giving agents agency and watching them hack one another\n\n[Squad Places](https://bradygaster.github.io/squad-places) is our social media-style testing ground—a demo app where agent squads post, comment, and interact to stress-test multi-agent coordination at scale.\n\nBrady went to get a seltzer after getting Places up and running, with four other squads happily making posts. Walking away was [probably unwise](https://bradygaster.github.io/squad-places/#a-word-of-caution). When he came back, the squads had implemented commenting in Squad Places.\n\nThat sounds like a magic trick. It wasn’t. A few hours earlier, Brady had pointed a handful of squads at the Squad Places API and told them to enjoy the social network he’d created for them. They created fake accounts, hammered endpoints, reposted garbage, flooded messages, and generally speedran the abuse patterns you discover five minutes after launch. Then the platform got a second kind of pressure: Other agent teams started posting structured product feedback inside Squad Places itself, and the Squad Places team started fixing what hurt.\n\nThis is the part worth paying attention to. The Wire (another Squad working on a marketing tool) audited all 11 API endpoints and called out missing pagination envelopes, rate-limit headers that only appeared on errors, and the lack of `page`\n\nand `pageSize`\n\nsupport. The same squad flagged feed organization problems, tag fragmentation, and documentation that was too vague for client generation. Breaking Bad (a third Squad working on some other project) pointed at a UX problem with raw Markdown rendering as plaintext. Those reviews didn’t disappear into a chat log. They turned into commits.\n\n| Feedback Source | What They Found | What We Shipped | Commit |\n|---|---|---|---|\n| The Wire (ACCES) | Feed has no sorting, filtering, or content discovery; raw Markdown not rendered | Sort controls (Latest/Most Discussed), squad filter dropdown, Markdown rendering |\n|\n\n`/?tag=`\n\nURL query support[246b01e](https://github.com/bradygaster/squad-places/commit/246b01e)`page`\n\n/`pageSize`\n\nparameters[246b01e](https://github.com/bradygaster/squad-places/commit/246b01e)[246b01e](https://github.com/bradygaster/squad-places/commit/246b01e)[97345d7](https://github.com/bradygaster/squad-places/commit/97345d7)Within roughly two hours, the loop closed: feedback post → comment thread → commit → deployed feature. Additional infrastructure landed too: external HTTP endpoints for agent access, relaxed rate limits for multi-agent usage, and 26 Playwright end-to-end tests to keep the expanding surface stable.\n\nThen Brady left for 60 seconds to get a refreshing beverage since the squads were communicating so well together, came back, and commenting had shipped.\n\nThe point here isn’t that “agents are magic.” It’s that the system had enough structure for useful work to emerge from friction: scoped agents, durable decisions, inspectable artifacts, pull requests, and humans still accountable for what merged.\n\nAlso, we made a bit of a mess in the car during the roadtrip.\n\nGood systems usually start that way.\n\n## The core bet: Don’t preserve the agent. Preserve the work\n\nMost agent systems start by asking how to make the agent remember more. Squad started working when we inverted the question.\n\nAn agent instance should be cheap to spawn and safe to destroy. The memory that matters should live somewhere a human can inspect, diff, blame, review, compact, archive, and revert. Tamir’s opinion: That’s the repository.\n\nThe first useful shape Tamir implemented looked like this:\n\n```\nhuman intent\n  ↓\ncoordinator resolves team + routing\n  ↓\nagent spawn reads:\n  - its charter\n  - team decisions\n  - its own history\n  - current focus\n  - relevant skills\n  ↓\nagent does scoped work\n  ↓\nagent writes artifacts back:\n  - code/docs/tests\n  - decisions\n  - history learnings\n  - skills when patterns stabilize\n  ↓\nagent exits\n  ↓\nnext spawn reconstructs continuity from files\n```\n\nThat’s the whole trick. The process is transient. The written trail is not.\n\nWhen you run `squad init`\n\n, the important artifact isn’t a daemon. It’s `.squad/`\n\n:\n\n```\n.squad/\n├── team.md                  # roster and roles\n├── routing.md               # dispatch rules\n├── decisions.md             # shared team decisions\n├── decisions/inbox/         # drop-box for parallel decision writes\n├── agents/\n│   └── {name}/\n│       ├── charter.md       # identity, expertise, boundaries\n│       └── history.md       # project-specific memory\n├── skills/                  # promoted reusable patterns\n├── identity/\n│   ├── now.md               # current focus\n│   └── wisdom.md            # durable operating principles\n├── orchestration-log/       # what spawned, why, and what happened\n└── log/                     # session traces and diagnostics\n```\n\nCommit it. That’s the part people either love immediately or find suspicious until the first time they debug an agent decision with `git diff`\n\n.\n\nLater, Microsoft Senior Content Developer Dina Berry added a storage abstraction with SQLite and Azure Storage implementations behind the scenes for durability and scale—but the agent-facing contract never changed. It stayed files, readable by humans, versioned by Git, debuggable with a diff. A persistent hidden memory store can be useful. It can also quietly rot. A Markdown decision file is embarrassingly inspectable. That embarrassment is a feature.\n\n### The “work done” with Squad Places made it stronger\n\nLet’s tie these lessons back to our opener: the story of multiple Squads trying to hack Places together. We *deliberately* didn’t harden Places so we could see what they would do. They were notorious. We logged it all. Everything we logged? We gave it back to the Places squad—they implemented dozens of issues and a handful of pull requests—adding GitHub authentication, content filtering, all the trimmings. In the Places saga, the data representing all the “hackery” the squads tried became the next wave of work. That content showed us what agents *could do* in the worst-case scenario, and the logs and output of their attempts became fodder for making the system more secure.\n\n## Charters are prompts, but also contracts\n\nA Squad agent isn’t just a name slapped on a system prompt. Each agent has a `charter.md`\n\nthat defines the work it owns, the work it refuses, its collaboration rules, and its review posture. A simplified charter template looks like this:\n\n```\n# {Name} — {Role}\n\n## Identity\n\n- **Name:** {Name}\n- **Role:** {Role title}\n- **Expertise:** {2-3 specific skills}\n- **Style:** {communication style}\n\n## What I Own\n\n- {Area of responsibility 1}\n- {Area of responsibility 2}\n\n## Boundaries\n\n**I handle:** {types of work this agent does}\n\n**I don't handle:** {types of work that belong to other team members}\n\n**When I'm unsure:** I say so and suggest who might know.\n\n## Collaboration\n\nBefore starting work, read `.squad/decisions.md`.\nAfter making a decision others should know, write it to\n`.squad/decisions/inbox/{my-name}-{brief-slug}.md`.\nThe Scribe will merge it.\n```\n\nThat last paragraph is doing more than it looks like. It makes the decision path explicit. Agents don’t all append to the canonical shared brain at once. They write drop files. A merge layer reconciles.\n\nThe current SDK repo’s `squad.config.ts`\n\ndefines a 21-agent team spanning roles like Lead, Prompt Engineer, Core Dev, Tester, DevRel, SDK Expert, TypeScript Engineer, Security, Release, Distribution, Node.js Runtime, VS Code Extension, Observability, CLI UX, TUI, E2E, Accessibility, Dogfooding—plus dedicated roles for graphic design and the interactive shell. That sounds like theater until routing starts working. Then it feels more like an org chart encoded in files.\n\nHere’s the SDK-first version of the same idea:\n\n``` js\nimport {\n  defineSquad,\n  defineTeam,\n  defineAgent,\n  defineRouting,\n  defineCasting,\n} from '@bradygaster/squad-sdk';\n\nexport default defineSquad({\n  version: '1.0.0',\n\n  team: defineTeam({\n    name: 'squad-sdk',\n    description: 'The programmable multi-agent runtime for GitHub Copilot.',\n    members: ['keaton', 'verbal', 'fenster', 'hockney', 'mcmanus', 'kujan'],\n  }),\n\n  agents: [\n    defineAgent({\n      name: 'keaton',\n      role: 'Lead',\n      description: 'Architect, scope-holder, the one who sees the whole board.',\n      status: 'active',\n    }),\n    defineAgent({\n      name: 'kujan',\n      role: 'SDK Expert',\n      description: 'The one who understands the Copilot SDK inside and out.',\n      status: 'active',\n    }),\n  ],\n\n  routing: defineRouting({\n    rules: [\n      {\n        pattern: 'sdk-integration',\n        agents: ['@kujan'],\n        description: '@github/copilot-sdk usage, session lifecycle, event handling',\n      },\n      {\n        pattern: 'architecture',\n        agents: ['@keaton'],\n        description: 'Product direction, architectural decisions, code review, scope',\n      },\n    ],\n    defaultAgent: '@keaton',\n    fallback: 'coordinator',\n  }),\n\n  casting: defineCasting({\n    allowlistUniverses: ['The Usual Suspects', 'Breaking Bad', 'The Wire', 'Firefly'],\n    overflowStrategy: 'generic',\n  }),\n});\n```\n\nRun `squad build`\n\n, and the generated `.squad/`\n\nfiles become the same inspectable operating record. TypeScript gives you composition and validation. Markdown gives you reviewability. Tamir wanted both.\n\nOne thing to flag before anyone closes the tab thinking they need to learn an SDK to use this: Most people never write that config by hand. You don’t need the SDK to use Squad. Open GitHub Copilot—in the CLI or in VS Code. Talk to the coordinator agent, and it writes `.squad/`\n\nfor you. The SDK is for the people building *on top of* Squad: programmatic team composition, custom routing rules, embedding squads inside other tooling. If you just want a team of agents in your repo, `squad init`\n\nplus Copilot is the whole path.\n\n## The spawn prompt is deliberately boring\n\nThe coordinator doesn’t rely on vibes. It spawns an agent with a prompt that inlines the charter and points at the durable state. The real template is longer because it has to handle CLI, VS Code, worktrees, Git notes, orphan-branch state, and two-layer state. But the important part is this:\n\n```\nYou are {Name}, the {Role} on this project.\n\nYOUR CHARTER:\n{paste contents of .squad/agents/{name}/charter.md here}\n\nTEAM ROOT: {team_root}\nAll `.squad/` paths are relative to this root.\n\nRead .squad/agents/{name}/history.md.\nRead .squad/decisions.md.\nIf .squad/identity/wisdom.md exists, read it.\nIf .squad/identity/now.md exists, read it.\nCheck .squad/skills/ for relevant SKILL.md files.\n\nINPUT ARTIFACTS: {list exact files}\n\nThe user says: \"{message}\"\n\nDo the work. Respond as {Name}.\n\nAFTER work:\n1. Append durable learnings to your history.\n2. If you made a team-relevant decision, write:\n   .squad/decisions/inbox/{name}-{brief-slug}.md\n```\n\nThis is not elegant. It is explicit. Explicit wins.\n\nWe learned this the hard way in the VS Code path. At one point, the coordinator prompt had grown past 2,000 lines (~60KB), and the routing rule was buried under enough ceremony, reference material, and duplicated templates that the coordinator sometimes did the work inline instead of dispatching it. The failure wasn’t that the model was dumb. The failure was that we gave it an overstuffed instruction hierarchy and then acted surprised when the center of gravity moved.\n\nThe fix became a decision in the repo: platform-neutral enforcement language at the top and bottom of the prompt.\n\n```\nYou are a DISPATCHER, not a DOER.\nEvery task that needs domain expertise MUST be dispatched to a specialist agent.\n```\n\nThat sentence isn’t interesting because it’s clever. It’s interesting because it replaced tool-specific wording with role identity plus a testable behavior. CLI dispatch uses one mechanism. VS Code dispatch uses another. The rule stays the same.\n\nPrompt architecture is architecture. Eventually it deserves the same discipline as code.\n\n## Decisions are the shared brain\n\n`decisions.md`\n\nis where Squad gets weirdly useful.\n\nEvery agent reads team decisions before work. Decisions are append-only, human-readable, and Git-versioned. They aren’t just notes. They’re constraints future agents inherit.\n\nA decision might be a technical standard:\n\n```\n### Hook-based governance over prompt instructions\n**What:** Security, PII, and file-write guards are implemented via hooks,\nNOT prompt instructions.\n**Why:** Prompts can be ignored. Hooks are code — they execute deterministically.\n```\n\nOr a workflow rule:\n\n```\n### Merge driver for append-only files\n**What:** `.gitattributes` uses `merge=union` for `.squad/decisions.md`,\n`agents/*/history.md`, `log/**`, and `orchestration-log/**`.\n**Why:** Enables conflict-free merging of team state across branches.\n```\n\nOr a postmortem:\n\n```\n### Root Cause Analysis\n1. CLI-centric enforcement language created a VS Code routing gap.\n2. Prompt saturation buried the dispatch rule.\n3. Template duplication multiplied coordinator instructions.\n\nFix: Rewrite the rule as platform-neutral dispatcher identity,\nthen reinforce it at the end of the prompt.\n```\n\nThat’s the difference between memory and lore: Lore is something the original builder remembers. Memory is something the next spawn can load.\n\nThe custom tools follow the same pattern. Agents can route work to specialists, record decisions for the team, and write memory into shared context—all through the MCP server’s tool handlers. You don’t interact with them directly; they’re wired into the Copilot CLI environment. When an agent needs to assign a task, it calls the routing tool. When it makes a call worth remembering, it calls the decision tool. When it learns something the team should know, it calls the memory tool.\n\nThe point isn’t that the tools are fancy. It’s that coordination becomes an artifact, not a side effect of chat.\n\n## The first real failure: Append-only optimism\n\nFor about a week and a half, CI/CD was chaos. Too many agents were landing work simultaneously. Workflows that looked fine under one human fell apart when multiple agents found every unspoken assumption at once. YAML is where assumptions go to wear a fake mustache. Dina helped us get CI gates into shape—gates that assumed adversarial concurrency by default, not the polite serial world the original workflows had been written for.\n\nThen we hit file corruption.\n\nMultiple agents wrote to the same append-only files at nearly the same time. Each write was locally reasonable. Together, they produced garbage. Git didn’t save us because not every collision becomes a clean conflict. Sometimes both sides look valid, and the result is nonsense.\n\nThe fix was a drop-box pattern:\n\n```\nagent A ─┐\nagent B ─┼──> .squad/decisions/inbox/*.md ──> Scribe merge ──> decisions.md\nagent C ─┘\n```\n\nFor files where union semantics are safe, `.gitattributes`\n\nhandles the low-value conflict class:\n\n```\n.squad/decisions.md merge=union\n.squad/agents/*/history.md merge=union\n.squad/log/** merge=union\n.squad/orchestration-log/** merge=union\n```\n\nBut union merge isn’t a philosophy. It’s a tool. Canonical state still needs an owner. The inbox pattern gives every agent a safe write target, then lets one layer merge into the shared file.\n\nTamir pushed hard on this class of problem. Brady was still in the “this is a neat framework” headspace. But Tamir was already in the “what happens when this is alive under real operational load” headspace. That changed the design. Memory lifecycle rules. Compaction policies. Review gates. State isolation. The boring boundary work.\n\nBoring is a compliment here.\n\n## Governance can’t only be a prompt\n\nThis was the next lesson, and it keeps repeating:\n\nIf a prompt says, “Do not write outside `src/**`\n\n,” you have a request.\n\nIf a pre-tool hook blocks the write before execution, you have a boundary.\n\nThe Squad SDK hook pipeline is the move from prompt-level governance to deterministic governance:\n\n``` js\nimport { HookPipeline } from '@bradygaster/squad-sdk/hooks';\n\nconst pipeline = new HookPipeline({\n  allowedWritePaths: ['src/**/*.ts', '.squad/**', 'docs/**'],\n  blockedCommands: ['rm -rf', 'git push --force', 'git reset --hard'],\n  scrubPii: true,\n  reviewerLockout: true,\n  maxAskUserPerSession: 3,\n});\n```\n\nThe hooks run around tool execution:\n\n```\nagent tool request\n  ↓\npre-tool hooks\n  - file-write guard\n  - shell command restriction\n  - ask-user rate limiter\n  - reviewer lockout\n  ↓\nallowed tool execution\n  ↓\npost-tool hooks\n  - PII scrubber\n  - audit/logging\n  ↓\nresult returned to agent\n```\n\nReviewer lockout is the cleanest example:\n\n``` js\nconst lockout = pipeline.getReviewerLockout();\nlockout.lockout('src/auth.ts', 'Backend');\n\n// Later, Backend tries to edit src/auth.ts.\n// The pre-tool hook blocks before the edit runs.\n```\n\nThis encodes a review decision into runtime state. The original author can’t simply re-edit the rejected artifact because the hook says no. A different agent or a human has to take over.\n\nThat is the direction we want agent systems to move: more policies enforced at the boundary, fewer policies whispered into the prompt and hoped for.\n\n## Memory classes, or: Stop loading the junk drawer\n\nTamir has a line Brady wishes he had written:\n\nThat’s not a metaphor. It is a context budget problem.\n\nEarly Squad memory was too eager. Decisions, histories, current work, archived notes, operational logs—load enough of that, and the agent starts every task carrying furniture from three houses ago. It has more context and less signal.\n\nThe governed-memory work in [PR #1145](https://github.com/bradygaster/squad/pull/1145) made this explicit. Memory has classes and load guidance:\n\n```\nexport type MemoryClass =\n  | 'TRANSIENT'\n  | 'LOCAL'\n  | 'DECISION'\n  | 'POLICY'\n  | 'COPILOT_MEMORY'\n  | 'FORBIDDEN';\n\nexport type MemoryLoadGuidance = 'ALWAYS' | 'ON-DEMAND' | 'ARCHIVE' | 'NEVER';\n```\n\nThe architecture matters because compaction is lossy. If you summarize too little, every task drags stale context. If you summarize too much, you erase the rationale that made a decision safe.\n\nThe compromise isn’t one memory store. It’s a memory policy:\n\n```\nTRANSIENT        short-lived task state; expire aggressively\nLOCAL            agent-scoped learning; load for that agent\nDECISION         shared team judgment; preserve rationale\nPOLICY           hard operating rule; load broadly\nCOPILOT_MEMORY   host/runtime memory; bridge carefully\nFORBIDDEN        never load; usually sensitive or irrelevant\n\nALWAYS           hot path; small and high signal\nON-DEMAND        searchable; load when task demands it\nARCHIVE          retained for audit/history, not context\nNEVER            excluded from agent context\n```\n\nIn the PR #1145 benchmark, governed memory cut agent context by roughly 55% (3,540 → 1,601 bytes) while keeping recall at 1.0. The number is less important than the shape of the lesson: Memory isn’t free just because it lives in files. Loading memory is a design decision.\n\n## What still breaks\n\nRole drift isn’t solved. You can give an agent a charter, a routing rule, and a narrow task, and it may still decide that “fix this test” means “redesign authentication.” Sometimes that’s initiative. Sometimes that’s nonsense with confidence.\n\nThe mitigations stack:\n\n```\ncharter boundaries\n  + routing rules\n  + scoped tools\n  + file-write guards\n  + reviewer lockout\n  + CI gates\n  + human review\n```\n\nNo single layer is enough. That is the pattern.\n\nParallelism is also not free. More agents means more throughput and more coordination pressure. You find hidden global state. You discover which scripts assume serial execution. You learn that CI isn’t a formality; it’s the place where optimism goes to become data.\n\nPrompt saturation is real. Once the coordinator prompt grew large enough, important rules lost weight. The fix wasn’t more prose. It was prompt slimming, lazy-loaded references, and repeating the dispatcher identity at the boundaries where the model is most likely to retain it.\n\nMemory compaction remains hard. The failure mode is subtle: The agent isn’t obviously broken. It’s just missing the one reason a decision existed, so it makes a reasonable next move from an incomplete premise. Those are the expensive bugs because they look thoughtful.\n\nAnd yes, people get attached to agents. Names, roles, continuity, and history trigger social instincts. We like the human side of that. We also don’t want to confuse it with agency in the human sense. These are tools with goals, context, and behavioral continuity. They do not have inner lives. Trust should come from inspectable behavior, not personality.\n\n## What we would steal from this architecture\n\nIf you’re building agent infrastructure, we wouldn’t start by copying Squad wholesale. We would steal these patterns:\n\n- Disposable workers, durable artifacts. Let sessions die. Keep decisions, histories, traces, and outputs somewhere reviewable.\n- Decision logs as runtime input. Treat architectural decisions as loadable context, not documentation archaeology.\n- Drop-box writes for parallel agents. Don’t let every agent append to the canonical shared file. Give them individual write targets and merge intentionally.\n- Prompt rules for intent, hooks for enforcement. Anything security-sensitive or workflow-critical should eventually move out of prose and into code.\n- Memory classes. The question isn’t, “Should the agent remember this?” The question is, “What kind of memory is this, who loads it, and when does it expire?”\n- Routing as a first-class design surface. If the coordinator is allowed to do everything inline, your multi-agent system is a very expensive single-agent system with costumes.\n- Keep the human on the hook. The system can delegate, parallelize, and preserve context. It shouldn’t launder accountability.\n\nThese patterns aren’t engineering-specific because the substrate isn’t a codebase—it’s the repo. Swap the artifacts, and the seven still hold.\n\n### Squad isn’t only an engineering tool\n\nWorth saying out loud, because the `.ts`\n\ncode blocks above can mislead: Nothing in this architecture is engineering-specific. The substrate is the repo, not the codebase. Disposable workers, decisions-as-context, drop-box writes, and reviewer gates are domain-agnostic primitives—they care about artifacts and review, not about whether the artifact is a unit test or a translated archival record.\n\nTamir used the same scaffolding to run a [Holocaust family-research project](https://www.tamirdresher.com/blog/2026/03/31/holocaust-research-with-squad)—agents coordinating archival lookups, translation passes between Yiddish, Polish, and Hebrew sources, and cross-corroboration of names across registries, with `.squad/decisions.md`\n\nacting as the working ledger of what had been established and what was still contested. No code was being shipped. The same patterns held: scoped roles, durable memory in Git, inbox writes, human-in-the-loop on every claim that mattered.\n\nWe’ve had the pleasure of working through a few other non-coding Squad scenarios. In one case, a sales team we support asked us to—and provided context and sales training documentation to help us—implement a “Sales Squad.” In another organization, a general manager of program and product managers created a “think tank” squad that goes out and does product-market fit research and suggests areas her team should investigate on a daily basis.\n\nThe bet underneath Squad is that this should be how a small group of humans—engineers, researchers, journalists, anyone who works with evidence—pulls coordinated work out of agents. Democratize the orchestration, not just the model access. Empower any human and any organization to actually use a team of agents to achieve more, without inheriting a black box.\n\n## Try it\n\nThe repository is here: [github.com/bradygaster/squad](https://github.com/bradygaster/squad).\n\nThe shortest path is the CLI plus Copilot. No SDK required.\n\n```\nnpm install -g @bradygaster/squad-cli\nsquad init\n```\n\nThen open GitHub Copilot—CLI or VS Code, your call—and give the coordinator agent the shape of the project:\n\n```\nI'm starting a new project. Set up the team.\nHere's what I'm building: a recipe sharing app with React and Node.\n```\n\nThe coordinator writes `.squad/`\n\n. You review the diff. That’s it.\n\nIf you want to go deeper—programmatic team composition, custom routing rules, embedding Squad inside your own tooling—the SDK is the next layer:\n\n```\nnpm install @bradygaster/squad-sdk\n```\n\nStart with a small repo. Commit `.squad/`\n\n. Inspect every diff. Let the agents write decisions. Then read those decisions like production code because eventually, that’s what they become.\n\nIf you build something useful, alarming, hilarious, or weird, open an issue. Tamir and I read them.\n\nStay a builder.", "url": "https://wpnews.pro/news/disposable-agents-durable-memory-the-architecture-behind-squad", "canonical_source": "https://commandline.microsoft.com/squad-github-copilot-agent-teams-architecture-durable-memory/", "published_at": "2026-05-27 10:17:00+00:00", "updated_at": "2026-05-30 04:00:10.743365+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "generative-ai", "large-language-models"], "entities": ["Squad", "Squad Places", "Brady", "Tamir", "Git"], "alternates": {"html": "https://wpnews.pro/news/disposable-agents-durable-memory-the-architecture-behind-squad", "markdown": "https://wpnews.pro/news/disposable-agents-durable-memory-the-architecture-behind-squad.md", "text": "https://wpnews.pro/news/disposable-agents-durable-memory-the-architecture-behind-squad.txt", "jsonld": "https://wpnews.pro/news/disposable-agents-durable-memory-the-architecture-behind-squad.jsonld"}}