Every time a coding agent session ends, most teams pay a hidden re-briefing tax: paste in the relevant ADR, explain why the API uses POST for that one endpoint, remind it which service owns the auth layer. A developer I read about estimated roughly 10-15 minutes per session start on a complex codebase. Multiply that by three or four sessions a day and you're losing an hour to context setup alone.
That tax is now, at least partly, optional. Two releases in the past three weeks moved persistent memory from a lab concept to a shipped feature in mainstream coding agents: xAI's Grok Build memory went generally available on September 16, and Google's Gemini Agent - announced October 8 at its Gemini at Work 2026 event - ships with four distinct memory layers as the default. Neither is perfect. But together they signal that the coding agent loop is structurally changing, and teams should understand what they're actually getting before they depend on it.
What Grok Build memory actually does
xAI on September 16, 2026, announced cross-session memory for Grok Build, its terminal coding agent - a feature that records conventions, decisions, and project facts as markdown notes in the background and reads them back in later sessions. The implementation is more transparent than most: the system stores notes as Markdown files, with one topic per subject, and project work stays within a dedicated workspace scope, while a global scope holds preferences that should carry across projects.
The operational model is worth knowing in detail.
After each conversation turn, Grok Build automatically reviews and extracts high-value, long-term insights without interrupting ongoing activities - such as the team's coding practices, the reasoning behind architectural decisions, and key project facts.
Two slash commands give you control:
/memory lets you browse everything the agent has retained, while /dream automatically organizes recent notes into structured topics.
Crucially,
before related work begins, Grok reads the relevant topics and applies them even when they are not mentioned in the new conversation - but instructions in the current conversation still take priority.
One non-obvious constraint:
note capture begins after the first completed turn, and developers must run /new or start a fresh Grok session for the saved context to apply.
Memory doesn't teleport into a session you already have open.
What Google's Gemini Agent ships with - and why it's architecturally different
Google's announcement is bigger in scope but harder to evaluate immediately because much of it isn't generally available yet. Google Cloud announced the Gemini agent on October 8, 2026, at its Gemini at Work 2026 event, describing it as a single, universal agent for work. Access spans the web, iOS and Android, desktops, the command line, Google Workspace, Microsoft 365, and Slack; because it runs persistently in the cloud, the agent maintains one set of memories, context, and a single personalization graph across devices, and work that takes hours or days continues after a user closes a laptop.
Gemini draws on a tools registry - Salesforce, ServiceNow, Jira, Snowflake, Databricks, Microsoft Office, Teams, and any MCP server - a skills registry of reusable workflows, and four memory types: session, semantic, procedural, and episodic.
The "coworker agent" configuration is the part most teams should watch. Persistent agents receive their own Google Workspace identity, email address, calendar, Drive, and storage, and act under that identity rather than the user's. That changes the accountability model in a real way: when an agent sends a message or creates a file, there's a named identity behind it, not just "Gemini did it."
Google says each agent receives its own cryptographically attested identity and operates under the organization's existing security policies and permissions. Complex tasks execute inside isolated containers with restricted outbound communications, while an Agent Gateway applies company security rules to traffic between agents and external systems.
The real comparison: how these two memory models differ
The implementations are doing different things, and conflating them leads to poor tool choices.
| Dimension | Grok Build memory | Google Gemini Agent |
|---|---|---|
| Storage format | Markdown files, per-topic | Four-layer (session / semantic / procedural / episodic) |
| Scope | Project-level + global | Per-agent + organization-wide skills registry |
| User control | /memory browser, /dream organizer |
Skills library, team registry, individual skills |
| Agent identity | Shared with your user | Own Workspace account + email |
| When memory applies | Next fresh session | Persistent across devices, continuous |
| Availability | GA as of Sept 16 | Announced Oct 8; rollout ongoing |
Grok Build's approach is low-ceremony and inspectable - the notes are plain Markdown files you can read, edit, or delete. Google's is more ambitious: four memory types that mirror how humans store different kinds of knowledge, layered across an organization. The risk with Grok's model is that a bad note poisons future sessions silently. The risk with Google's is complexity - four memory types require you to understand which layer holds what, and when a session-memory fact conflicts with a procedural-memory instruction, it's not obvious which wins.
The non-obvious consequence: memory quality becomes a team concern
Here's the second-order issue most coverage is skipping. When a coding agent carries memory across sessions, whatever it learned early - including wrong things - compounds. If a junior developer's first session established an incorrect architectural convention in the memory store, every subsequent session by any team member inherits that mistake silently.
The tool automatically stores key decisions and facts across sessions, filtering out temporary or sensitive data.
But the filter is model-driven, which means "temporary" is a judgment call made by the agent, not a rule you define. Teams using Grok Build's memory should treat /memory reviews as a hygiene task, not a curiosity - the same way you'd audit a shared wiki page that everyone else is reading.
The broader point: for developers, one of the most frustrating issues when using AI coding assistants has been having to repeatedly explain the project's architecture, coding standards, and execution commands at the start of every new session. Persistent memory solves that. It also means the agent's accumulated knowledge can drift from the actual codebase if no one checks it. The ramp-up tax goes away; a different maintenance cost appears.
A teammate like Beagle, operating in Slack where architectural decisions often get announced, can surface the relevant thread when a developer's memory note looks inconsistent with what was actually decided - before the agent carries the wrong convention forward for another two weeks.
Beagle in action#engineering, 10:02amPersistent memory in coding agents: common questions
What is persistent memory in a coding agent?
Persistent memory in a coding agent is context - conventions, architectural decisions, project facts - that survives when a session ends and is automatically recalled in future sessions. Unlike a system prompt you manually paste in, the agent builds this store incrementally from past interactions, without you re-supplying it each time.
Does Grok Build memory work on existing sessions?
No.
Note capture begins after the first completed turn, and developers must run /new or start a fresh Grok session for the saved context to apply.
Memory captured in one session is available the next time you open a fresh one, not mid-session.
How does Google Gemini Agent memory differ from a system prompt?
A system prompt is static text you or your organization defines once. Gemini learns from every interaction with you - the longer you collaborate with it, the better it understands you and how you work. The four memory types - session, semantic, procedural, and episodic - update continuously, so the agent's context reflects your actual work history rather than a snapshot you wrote manually.
Can coding agent memory go wrong?
Yes, in a specific way: whatever a model judges worth retaining gets retained, including early mistakes. The tool automatically stores key decisions and facts across sessions, filtering out temporary or sensitive data
- but "temporary" is a model judgment call. A wrong convention captured early compounds across every future session until someone explicitly corrects or deletes it.
What should teams do before relying on persistent memory in a coding agent?
Establish a review cadence for stored memory - weekly for active codebases. For Grok Build, use the /memory browser to inspect and delete stale or incorrect notes. For any agent with a skills registry like Gemini's, designate who owns the team-level skill definitions and treat them like code: version-controlled, reviewed, and updated when the codebase changes.