Agno 2.6.14 Makes Agent Memory Operable, Then Fixes the Gemini Race Waiting to Bite It

Agno 2.6.14 is a useful release because it refuses to treat agent memory like magic.

The headline feature is CRUD for AgentOS learnings: list them, create them, fetch them, patch them, delete them, filter them, scope them, and enforce RBAC around them. That is exactly the right direction. Production memory is not “the agent remembers things.” Production memory is an API surface with permissions, identity, auditability, recovery paths, and delete semantics. If your agent can learn something about a user, an admin eventually needs to inspect it, a user may need to correct it, and a compliance process may need to erase it.

Agno’s release also fixes a Gemini thread-safety race and a JSON-object followup prompt issue for providers like DeepSeek. Those are not side quests. They complete the same story: an agent platform is only as serious as its control plane and its concurrency behavior. A memory API that falls over under concurrent model calls is not infrastructure. It is a demo with endpoints.

Memory gets verbs

PR #7826 is the big one: 37 files changed, 3,533 additions, 88 removals, and a new /learnings surface for AgentOS. The API includes GET /learnings, POST /learnings, GET /learnings/users, DELETE /learnings/users/{user_id}, GET /learnings/{learning_id}, PATCH /learnings/{learning_id}, and DELETE /learnings/{learning_id}.

The filters are the part that makes this feel designed for operators rather than demos: learning_type, user_id, agent_id, team_id, session_id, namespace, entity_id, and entity_type. Reads can target a specific database/table through db_id and table. Sorting is explicit. RBAC scopes map to learnings:read, learnings:write, and learnings:delete.

That may sound like standard backend work. It is. That is the point. Agent memory should stop being a mystical sidebar and start behaving like every other sensitive data system.

The deterministic ID design is particularly important. Agno reconciles API-created records with store-created records for identity-keyed learnings such as user_profile_{user_id}, memories_{user_id}, session_context_{session_id}, and entity_{namespace}_{entity_type}_{entity_id}. Existing identity records return 409; missing required identity fields return 422.

This prevents the classic split-brain memory problem: the control plane edits one record while the agent reads another. If agent-created memories and admin-created memories use different identities, operators get a dashboard that looks correct and a runtime that behaves differently. Deterministic IDs make the API and runtime meet at the same object. That is not glamour. That is correctness.

RBAC is where memory stops being creepy

The RBAC behavior is also worth reading closely. Scoped non-admin callers are bound to their own user_id. Cross-user single-record fetch returns 404 to avoid existence leaks. Shared null-owner records are mutable only by admins. These are product decisions, not merely implementation details.

Agent memory creates privacy risk because it has a tendency to feel informal. A model “learned” a preference. A workflow “remembered” a customer context. A team agent “stored” a useful fact. But once that fact exists in a database, it is data. It needs access control. It needs deletion. It needs audit trails. It needs a way to distinguish personal memory from shared organizational memory. And it needs to avoid confirming to one user that another user’s record exists.

Agno’s AgentOS docs already position the runtime as a FastAPI control plane for agent platforms, with 50-plus endpoints, durable sessions, request isolation, JWT-based RBAC, database-owned sessions/memory/knowledge/traces, observability, governance, and multi-framework support. Learnings CRUD fits that thesis cleanly. It turns memory into something platform teams can manage instead of something agents whisper into a store and hope nobody needs to edit.

For practitioners, the upgrade checklist is obvious: create learning records as admin and as scoped users; attempt mismatched user_id writes; verify 403 and 404 behavior; delete user-scoped records; attempt to mutate shared null-owner records as a regular user; and confirm logs capture who changed what. If an agent platform stores memory, the memory API belongs in your security review.

The Gemini race is the runtime telling on itself

The stability fix is just as telling. PR #7797 fixes issue #7427, where shared Gemini clients could produce intermittent SSL/TLS failures under concurrent load. The problem: per-response cleanup blocks closed and nulled a shared Gemini client while concurrent calls were still in flight. Reported errors included DECRYPTION_FAILED_OR_BAD_RECORD_MAC and WRONG_VERSION_NUMBER, reproducible under four or more threads and tools like JMeter or Locust.

The fix removes the per-response cleanup behavior and treats the client lifecycle like the shared resource it is. Verification was substantial: five new unit tests, 48 existing Gemini unit tests, 20 integration tests, and a manual 32-out-of-32 concurrent request run with zero SSL errors.

This is the kind of bug that appears when a framework graduates from notebook usage to service usage. A single agent call hides lifecycle mistakes. Concurrent traffic exposes them. AgentOS wants to be a durable runtime, which means model clients, database connections, traces, request isolation, and background work all need service-grade lifecycle semantics. Closing a shared provider client after every response is the sort of cleanup that feels responsible until it races another request.

The JSON-object provider fix lands in the same category of practical portability. PR #8357 fixes DeepSeek-style followups by adding the standard JSON-output prompt when response_format={"type":"json_object"}. Issue #8355 showed a provider returning 400 because the prompt did not contain the word “json.”

That is annoying, but it is not surprising. “OpenAI-compatible” APIs are often wire-compatible, not behavior-compatible. JSON mode, structured output, retries, streaming chunks, safety responses, and tool-call formats all carry provider-specific quirks. Agent frameworks either encode those differences carefully or leak them into application code at the worst time — often during a followup call after the main run looked successful.

What builders should do

If you run Agno, this release deserves a real upgrade test. Exercise Learnings CRUD with realistic users and roles. Confirm deterministic IDs reconcile with the records your agents actually read. Run concurrent Gemini workloads, not just one request in a shell. Test DeepSeek or other JSON-object providers through followup flows. Inspect traces and logs for memory operations. Treat learning deletion as a product requirement, not a developer convenience.

The bigger industry lesson is that agent platforms are becoming ordinary platforms with unusual callers. The caller may be an LLM, but the backend still needs RBAC, stable IDs, concurrency-safe clients, versioned behavior, provider quirks, and administrative APIs. The more “agentic” the product becomes, the more boring the platform underneath has to be.

Agno 2.6.14 is not a single flashy feature. It is a collection of signals: memory is now operable, Gemini concurrency is being treated like a runtime reliability bug, and provider-specific JSON behavior is being patched where it belongs. That is what separates an agent platform from a clever loop around an LLM.

The editorial take: memory that cannot be listed, patched, deleted, scoped, and audited is not memory; it is liability with embeddings. Agno is moving the right parts into the control plane. Now teams need to test whether the control plane holds.

Sources: Agno 2.6.14 release, PR #7826, PR #7797, PR #8357, AgentOS docs, issue #7427, issue #8355