Comment

I don’t normally enjoy throwing shade on other dev communities, but it’s hard not to be a little bit smug around our Android friends these days. Foldable phones have been around for 8+ years, but it took iPhone Duo, and more importantly, the Apple Developer Community, to fully open the floodgates of creativity and get the general public excited about the new experiences that foldable devices enable.

I check aggregators like beardfm.app and foldhunt.com daily, and new Duo-inspired apps just keep popping up. Granted, not all of them are great. In fact, a lot of these apps rely heavily on the hinge gimmick and arguably don’t offer much long-term value to users. But that doesn’t concern me that much. We’ve been living in bleak vibecodetown for a while now, and it’s in those gimmicks and that whimsy that I still find a spark of humanity. So keep them coming!

Speaking of gimmicks, the new MacBook Pro with a touch screen was announced on Wednesday. And I feel…a bit conflicted about it. The hero image on apple.com, with a person playing the piano on the MacBook’s screen, is outright ridiculous. But I can certainly get behind the use case of interacting with the simulator using touch input. This can be especially helpful when testing document-based apps with multi-touch workflows. And the PROLED XDR Display specs do look impressive. I really want to see it in person!

Just don’t expect me to play the piano on it 🤏

– Alex Ozun

Sponsored Link

Your coding agents need a Mac too

Claude Code can write Swift all day, but without Xcode it can’t prove the build actually passes. That’s why more teams are moving agents into a cloud development environment on Mac with Apple silicon, running the same stacks and caches as CI. This on-demand session covers how Remote Dev Environments work as shared infrastructure for developers and AI agents, where MCP fits in, and why fast builds matter even more when agents are the ones waiting on feedback. Watch it on demand.

News

Apple unveils MacBook Pro with PROLED XDR Display and Touch on Mac

As I already mentioned in the commentary section, Apple just announced its first MacBook with Touch. Conveniently, the announcement is accompanied by 3 new Tech Talks. I think these talks will be interesting both to developers who maintain macOS apps and want to adapt them for touch input, and to those who are looking at the new Macs as consumers and want to better understand the new touch-enabled affordances they offer: Design for touch on Mac, Bring Touch to your Mac app, Bring Live Activities to Mac

---

Apple forced to change app store rules in a win for roughly 15 million Australian users

Federal Court of Australia has ordered Apple to open up its devices to other app stores as it ruled that the restriction was anti-competitive.

Our Aussie editor Andyy Hope shares his thoughts: ‘Personally, I don’t think this is going to be that big of a deal in the day-to-day life of Australians, nor do I think that “Aussie App Store™” will ever take off. But I’m always open for more free market ideas.’

Design

Design the interface for functionality not familiarity

Jeff Johnson shares his thoughts on the design philosophy (or lack thereof) behind the new touch-enabled Macs. I concur with his point that touchscreens on Macs have more in common with the frustrating touch interfaces in cars than the well-motivated ones on phones and tablets.

---

Pocket Casts on iPhone Duo

Alex Grebenyuk, whom many readers will know as the developer behind the popular Nuke library, shares his experience adapting Pocket Casts for iPhone Duo. I really appreciate the generous number of screenshots that demonstrate the multitude of design decisions that went into the adaption process. And the Harder Than It Looks sections contains an important insight: ‘Duo also exposed a bigger gap: parts of the app needed more love on a big screen […] That will take more than one release’.

I think all the recent Day One support announcements have made us somewhat desensitised to the fact that adapting our apps isn’t always feasible in a single one-shot release.

Code

Closing Up: Why I’m making some of my projects closed-source

When Daniel Saidi writes about open-source vs closed-source development, both areas in which he’s found success, I pay attention. In this article he shares what motivated him to archive his popular open-source OnboardingKit library, and create a separate closed-source version with a commercial license. To nobody’s surprise, the decision was largely driven by the impact AI is having on open-source development. I respect Daniel’s decision, and recommend giving the article a read to get the full picture.

Business and Marketing

Don’t Launch to an Empty Room

Many developers are working on new apps right now, perhaps looking to ride the Duo hype wave, and will soon face the challenge of catching their audience’s attention. Jordan Morgan offers timely tips on how to launch your apps in an environment where everyone and their mother is shipping apps and competing for attention.

Tools

Feedler | The Smart RSS Reader

As you can probably imagine, I’m subscribed to tons of RSS feeds. Despite being a long-time user of NetNewsWire, I’m always on the lookout for interesting new RSS readers. This Feedler launch announcement caught my eye. As far as I can tell, it was developed largely in ‘stealth’ mode, so I was pleasantly surprised by how polished it is at launch. Kudos to the developer!

And finally...

Ok, can we please be serious and stop cracking jokes? 😅

AI-native observability requires teams to make both production systems and AI-driven workflows explainable through connected, verifiable telemetry. This Refcard explores patterns for preserving trace context, standardizing telemetry with OpenTelemetry, grounding AI-assisted investigations in evidence, and instrumenting agentic workflows end to end. You’ll also learn how common anti-patterns — including aggressive sampling, semantic noise, unsupported AI summaries, and unobservable agent execution — can weaken incident analysis and make automated findings harder to trust.

You can turn off cloud CI for pull requests and still block merges on a green check. Run the build and tests locally, post a signoff commit status with Basecamp's gh-signoff extension, and make GitHub require that status to merge. My repo has merged 833 pull requests this way since June, with cloud CI running only on main.

In June this year, the GitHub Actions bill for the Katabench repo was growing, and waiting for CI was seriously slowing down my work. Every pull request ran the .NET build, the tests, and the container image builds. And it would run the same steps again on every merge to main. In the 19 days before I changed it, that workflow ran 588 times for pull requests alone, about 2.7 minutes each on a 2-core runner.

I turned the pull_request trigger off and moved the gate to my own machine. Four months and 833 merged pull requests later, I haven't looked back.

What DHH Did With HEY

In April 2024, DHH wrote that 37signals was moving continuous integration back to developer machines. The remote CI run for HEY, their email app, took about five and a half minutes. His Linux desktop ran the same checks in less than half that time.

I found this idea quite interesting while searching for solutions to my slow CI problem.

His argument was about cores. A developer machine has far more of them than a rented CI runner, so the same suite finishes faster. He was also clear that this doesn't fit a codebase the size of Shopify or GitHub.

That still leaves the green check on the pull request. GitHub calls it a status check: a named pass or fail mark on one commit.

Basecamp released gh-signoff, an extension for the GitHub CLI that posts one from your terminal.

I gave it a try.

The Gate Is a Shell Script

The smallest version of my local gate, ci/local-ci.sh in a .NET repo:

#!/bin/sh
set -eu

marker="$(git rev-parse --git-dir)/ci-passed"

if [ "$(cat "$marker" 2>/dev/null)" = "$(git rev-parse HEAD)" ]; then
  echo "gate already passed for $(git rev-parse --short HEAD)"
else
  dotnet build MyApp.slnx -c Release -warnaserror
  dotnet test tests/MyApp.Tests -c Release --no-build
  dotnet format MyApp.slnx --verify-no-changes
  git rev-parse HEAD > "$marker"
fi

if [ "${1:-}" = "--signoff" ]; then
  gh signoff
fi

Here is what each part does, if shell scripts are new to you. The first line runs the file with sh, which ships with Linux, macOS, and Git for Windows. set -eu stops the script at the first failing command or unset variable, so gh signoff only runs when every check passed.

$(...) runs a command and pastes its output into the line, so marker is the path of ci-passed inside the .git folder.

The if compares the hash in that file with the current commit, and 2>/dev/null hides the error when the file doesn't exist yet. When they match, the script skips the checks. Otherwise the three dotnet commands run, and > writes the commit hash into the marker file.

${1:-} is the script's first argument, or empty when there was none. With --signoff, it ends by posting the status.

Put whatever your existing CI runs in here, especially integration tests using Docker.

Let Git Run It Before Every Push

A git hook is a script that git runs at a fixed point. pre-commit runs before git creates a commit, and pre-push runs before it sends your commits to GitHub. If the hook exits with an error, git cancels the commit or the push.

Git reads hooks from .git/hooks, which isn't committed, so a fresh clone has none. The fix is a committed folder and one config line per clone:

git config core.hooksPath .githooks

With that in place, .githooks/pre-push runs the gate:

#!/bin/sh
exec sh ci/local-ci.sh

Run chmod +x .githooks/pre-push before committing it, or git skips the hook.

Notice that the hook doesn't pass --signoff. At that point the commit only exists on my machine, and gh signoff refuses to post a status for a commit GitHub doesn't have yet.

So I push first, and the hook runs the checks on the way out. Then I run sh ci/local-ci.sh --signoff, which finds the marker from the hook run, skips the checks, and posts the status.

GitHub sees the commits and the status, but never the hook. It can't tell whether the hook ran before the push, and git push --no-verify skips it.

So the hook catches my mistakes early, but it can't protect the branch. That job belongs to a rule on GitHub's side.

One Required Check

GitHub can refuse to merge a pull request until named checks pass on its latest commit. That setting is a branch protection rule, or in its newer form, a ruleset.

A workflow job posts a status check when it finishes, and anyone with push access can post one through the API without running anything. That is all gh signoff does.

You can set up the gate with two commands:

gh extension install basecamp/gh-signoff
gh signoff install

install creates a ruleset on main that requires a status named signoff and blocks force pushes. The required-check rule, as the GitHub API returns it:

{
  "type": "required_status_checks",
  "parameters": {
    "required_status_checks": [{ "context": "signoff" }],
    "strict_required_status_checks_policy": true
  }
}

The strict flag is the setting GitHub calls "Require branches to be up to date before merging". With it on, GitHub won't merge my pull request if main has moved since I signed off. I have to rebase, run the gate again, and post a new signoff.

That's extra work with several branches open, but the checks always ran on the code that gets merged.

This is how the pull request shows the status:

The status belongs to one commit. If you push another commit, GitHub will block the pull request until the signoff gate runs on the new commit.

What Still Runs in the Cloud

Here's what the trigger block looks like in my workflow file:

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:

There is no pull_request trigger anymore. The pipeline runs once per merge to main, on a clean runner with none of my caches, my SDK, or my Docker images. It's the one run that doesn't take my word for it, and it checks the exact commit that landed on main.

The merge run can't block a bad signoff, because it starts after the merge. If something slipped through, main goes red and I fix it right away. That is the cost of this setup.

A signoff status proves that someone with push access posted it, and GitHub records who. The script posts it only after a green run, but anyone with push access can type gh signoff on its own, and a repository admin can bypass the ruleset outright.

On my repo that's me and my coding agents, whose instructions forbid --no-verify and a signoff outside the script. A team has to agree on the same rule.

The schedule entry runs the pipeline every Monday, even when nothing was merged that week. My pipeline scans the container images, so that run is how I find out about a new CVE in a base image.

And we've had plenty of CVEs disclosed recently. In October alone, .NET shipped security patches and an out-of-band fix twelve days later for a Brotli decoder bug, and curl fixed a use-after-free in HTTP/2 uploads.

workflow_dispatch adds a Run workflow button for a full run on demand.

Summary

Running CI in the cloud on every pull request is still a good default. You get a clean machine, and nobody on the team can fake the result.

But I was paying for that with minutes of waiting on every push, plus a growing Actions bill. My test suite finishes on my machine in a few minutes, so the trade didn't make sense anymore.

A script runs the checks and ends with gh signoff, and a pre-push hook runs it before every push. On GitHub's side, a ruleset on main requires the signoff status, and one workflow still runs in the cloud after each merge.

This setup can't handle pull requests from forks, because posting a status needs push access. If you maintain an open-source project, keep cloud CI for outside contributors and use signoff for the core team.

To try this, start with the script. Once it runs green in a few minutes, add the hook and the ruleset, then change the trigger block.

I covered the cloud version of this pipeline in an earlier issue.

Thanks for reading.

And stay awesome!

---

Summary

• The private keys of eight eMudhra intermediate certificates were compromised. A network attacker could use them to impersonate websites and services that JetBrains tools connect to.
• JetBrains IDEs, the Toolbox App, Gateway, and ReSharper are affected because they use the trust store of the bundled JetBrains Runtime (JBR). For IDEs, the embedded browser (JCEF) is also affected. Operating system updates don’t protect against this issue. 
• The Toolbox App and JetBrains IDEs use a background service, jetbrainsd. It has its own built-in list of trusted certificates and is fixed separately, in jetbrainsd 0.9.9728.
• At the time of publishing, we are not aware of any exploitation of this issue against JetBrains users.

Available fixed versions

The issue is fixed in the following versions:

• IntelliJ IDEA: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.4.
• PyCharm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• PhpStorm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• RubyMine: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• WebStorm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• Rider: 2026.3 EAP 9, 2026.2.4, 2026.1.5.3, 2025.3.5.3.
• CLion: 2026.3 RC, 2026.2.4.1, 2026.1.5.2, 2025.3.6.3, 2025.2.6.3.
• DataSpell: 2026.1.3.1, 2025.3.3.1, 2025.2.4.1.
• DataGrip: 2026.3 RC, 2026.2.6.1, 2026.1.4.1, 2025.3.6.1, 2025.2.6.1.
• GoLand: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.5.2, 2025.2.6.3.
• RustRover: 2026.3 EAP 8, 2026.2.5, 2026.1.4.1, 2025.3.7.1, 2025.2.6.1.
• Gateway: 2026.3 RC, 2026.2.4, 2026.1.4, 2025.3.3, 2025.2.6.
• ReSharper: 2026.3 EAP9, 2026.2.4, 2026.1.5.3, 2025.3.5.3.
• Toolbox App 3.9.1, 3.8.2.

The 2025.2.6.* updates for all IDEs now contain only the JBR fix. They will get a separate hotfix for the JCEF problem. Until then, use a workaround to disable JCEF in your IDE (see instructions below).

IDE versions 2025.1 and earlier, and Toolbox App 3.7 and earlier, will not receive this fix. You must update to a fixed version.

Details

In October 2026, the private keys of eight intermediate certificates issued by the certificate authority eMudhra were compromised. An attacker who can intercept your network traffic could use them to impersonate websites and services.

Full details of the incident.

JetBrains IDEs check certificates against the trust store of their bundled runtime, JetBrains Runtime (JBR), so updating your operating system doesn’t protect against this issue. We’ve integrated Oracle’s fixes for CVE-2026-91403 and CVE-2026-114820 into JBR as-is. The updated runtime blocks the compromised certificates and no longer trusts these root certificates:

• emSign ECC Root CA – G3
• emSign Root CA – G1
• emSign Root CA – G2
• AAA Certificate Services

In the fixed versions of 2025.3 and later, the embedded browser now receives Chrome’s certificate updates, which block the compromised certificates (CVE-2026-118696). It downloads them from Google’s update servers shortly after the IDE starts. If your network blocks access to Google’s update servers, the embedded browser stays unprotected. In this case, turn it off as described below.

The Toolbox App and JetBrains IDEs also install a background service, jetbrainsd. Its list of trusted certificates is built into the service itself, so updating JBR doesn’t fix it. We’ve released a separate fix in jetbrainsd 0.9.9728, tracked as CVE-2026-118697. Only one copy of jetbrainsd runs for each user, and a newer version always replaces an older one. Updating any app that includes jetbrainsd 0.9.9728 fixes it for all JetBrains apps.

What you should do: Update now

The fix is available in the latest versions of JetBrains IDEs, from 2025.2 up to 2026.3 RC. The upcoming 2026.3 release will include it too. Updating to the latest bugfix release of your current version is enough. Versions 2025.1 and earlier will not receive a fix. If you use one of them, please update to one of the versions above.

If you use ReSharper or other JetBrains .NET tools, update them to the latest version.

Important for Toolbox App users: versions 3.7 and earlier won’t receive this fix. If you’re on 3.7, update to version 3.9.1 or 3.8.2.

If you use JetBrains Gateway, update it to one of the following versions: 2026.1.4, 2025.3.3, 2025.2.6.

If you use JetBrains Runtime directly, update to one of the fixed builds: jbr25.635.79, jbr25.508.41, jbr25.329.142, jbr21.1163.125, jbr21.1038.91.

In rare cases, the IDE will no longer connect to a server whose certificate chains to one of the removed root certificates. The server’s owner will need to replace the certificate.

If you can’t update right away

Also check

Your project JDKs and any tools that bring their own runtime, such as Node.js, Python, or Go, use their own trust stores. Update them as their vendors recommend.

Support

If you have any questions about this issue or have trouble updating, please contact our Support team.

Most enterprise AI agent projects look impressive as a demo but never reach production. When these projects stall out, the usual explanation is that the model underperformed, the prompts were wrong, or the use case was too ambitious. But often, the real problem lies deeper. It’s the data layer.

An AI agent that can’t remember what it did in a previous session, that can’t be audited when it makes a consequential decision, and can’t access live operational data without calling three separate APIs doesn’t have a model problem. It has an infrastructure problem. And the Couchbase AI Data Plane is built to solve it.

Why do AI agents fail between pilot and production?

According to Gartner, organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026. In most cases, the model isn’t the problem. A pilot looks good in a demo environment, then breaks down in production because the organization lacks a unified data plane built for agent speed. Agents end up reaching across disconnected systems for memory, context, and tools, and every hop adds latency, cost, and risk.

Three specific failures account for most of what goes wrong.

Agent amnesia – the memory problem

An agent that can’t remember what it did last session, what a user told it two minutes ago, or what it already tried in a multi-step workflow is not a production agent. It’s a stateless function that happens to use an LLM. Every session starts from scratch, users repeat themselves, and the agent repeats mistakes it already made.

Agent amnesia occurs when an agent’s memory is fragmented across separate caches, vector databases, session stores, and in-context window state, with no unified layer to manage them as a coherent whole. The agent technically has access to information in pieces, but it can’t maintain a consistent, personalized understanding of a user or a task over time.

The governance gap – the observability problem

In regulated industries, “the agent decided” is not a defensible explanation for a consequential decision. For every agent action, the engineering team must be able to answer the questions: What data did the agent access? Which tools did it invoke? What prompt was it operating from? Which version of that prompt? 

If the engineering team can’t answer those questions, then the security and legal teams can’t trust the agent in production.

Tracing and auditing agent behavior isn’t a model problem. It’s a data problem. When tools, prompts, and agent function calls aren’t logged in a structured, queryable format, auditing agent behavior becomes a manual reconstruction effort rather than a straightforward query. Teams need the observability infrastructure to trace each action, understand how the agent reached a decision, and produce an auditable record when compliance, security, or legal teams need answers.

Integration cost – the point-solution problem

A production AI agent typically needs access to a vector store for semantic retrieval, a cache for fast context lookup, a session store for short-term memory, a document store for operational data, and a tool registry for governed function calls. When each is a separate system, integration overhead is significant. You deploy five systems, maintain five APIs, manage five sets of credentials, and face five potential points of failure on every agent inference call.

Each point solution was probably the right decision when you added it. But together, they become a fragmented infrastructure that causes the agent to fail when one component falls behind, goes down, or drifts out of sync with the others.

What is the Couchbase AI Data Plane?

The Couchbase AI Data Plane is the governed data and memory layer that gives production AI agents persistent memory, governed access to data and tools, and consistent context from the cloud to the edge. It collapses the five separate point solutions described above into one platform that’s built on Couchbase Capella and is available across cloud, self-managed, hybrid, and edge deployments.

The AI Data Plane has these three core components that directly address the three potential failure areas discussed above:

Agent Memory

Agent Memory gives AI agents persistent recall across sessions, users, and frameworks. Memory is structured across three levels that work together. Short-term memory holds the current conversational context and active task state. Long-term semantic memory stores observations and facts as vector embeddings for cross-session retrieval. Profile memory stores structured user attributes (like preferences and permissions) for deterministic, low-latency lookup.

When an agent with proper memory asks, “What did we discuss last time?” or “Does this user prefer metric or imperial units?” it retrieves a real answer from a governed store rather than generating a hallucinated one. Over time, the agent becomes more personalized because its memory reflects each user’s actual interaction history, not a fresh context window.

Memory in the AI Data Plane is not a bolted-on vector store. Every memory block is a JSON document containing an embedding vector, a natural language summary, a structured context object, a timestamp, and a configurable time-to-live for retention compliance. The system stores, retrieves, and governs these memory blocks alongside the agent’s other operational data.

Agent Catalog

The Agent Catalog is the governed registry where every tool, prompt, and agent function used in a production application is stored, versioned, and made inspectable. It gives regulated enterprises the visibility they need to trust agents in production.

When an agent makes a decision, the Agent Catalog records which tool it called, which prompt version it used, what data it accessed, and the result. Those records are vectorized and indexed so that teams can search agent behavior semantically. “Show me all sessions where the agent invoked the payment tool without user confirmation” is a real query, not a hypothetical. 

The Agent Catalog also makes development faster. Instead of each team building a new agent from scratch, the Agent Catalog makes existing tools and prompts discoverable. With semantic search over the catalog, a team can find and reuse a tool another team already built.

Governed data access via MCP Server

The Couchbase MCP Server implements the Model Context Protocol (MCP), the open standard that defines how AI models connect to external tools and data sources at runtime. MCP gives agents a governed, discoverable interface to invoke capabilities without hardcoding an integration for every tool.

Rather than giving the agent direct database credentials, the MCP Server enforces role-based, tool-level access control. The agent can query what it’s authorized to query, invoke the tools it’s authorized to invoke, and nothing more. The AI Data Plane’s audit infrastructure logs every invocation.

How unified data infrastructure changes what agents can do

The difference between an agent running on fragmented point solutions and one running on the Couchbase AI Data Plane isn’t primarily a performance difference. It’s a capability difference.

An agent with unified memory, governed tool access, and fast semantic retrieval in one layer can do things that a fragmented agent can’t. It can recognize a returning user across channels without the user identifying themselves, resume a complex multi-step task from exactly where it left off after a session interruption, refuse a request that falls outside its authorized scope and explain why, and surface the exact prompt and tool invocation that produced a specific output when a compliance team requests an audit.

None of these capabilities require a better model. They simply require a data layer designed for agent workloads, not one assembled from systems designed for something else.

The AI Data Plane also runs where production workloads actually run. For enterprises with edge deployments, field service applications, or always-on requirements, the same data layer available on Couchbase Capella extends to self-managed, hybrid, and edge environments. Couchbase Lite and Couchbase Edge Server support these deployments with bidirectional sync and consistent governance across every tier.

What this looks like in practice

The value of the AI Data Plane becomes clear when you see how its components work together in a real application. Consider a customer service agent that needs to deliver personalized support while keeping its actions secure, consistent, and auditable.

A customer service agent powered by the Couchbase AI Data Plane opens every interaction with the customer’s preference profile from Agent Memory, retrieves semantically relevant context from prior sessions using vector search, invokes authorized tools through the MCP Server to look up orders or update records, and logs every action through the Agent Catalog for compliance review. When the session ends, it writes the outcome back to the customer’s long-term memory so the next interaction builds on it.

Compare that to the same use case on fragmented infrastructure. This time, the agent has no memory of prior sessions unless the developer has pre-loaded a summary into the context window (which has a token cost, a latency cost, and is limited by window size). Tools are invoked through hardcoded API calls with no centralized audit trail. And compliance teams requesting a review of a specific interaction have to reconstruct what happened from logs spread across five systems.

The agent in the first scenario gets smarter over time. The agent in the second scenario starts from the same point on every call, regardless of how many interactions it has handled.

FAQs

What is the Couchbase AI Data Plane? The Couchbase AI Data Plane is the governed data and memory layer for production AI agents. It provides persistent agent memory across sessions, governed tool access through MCP Server, a centralized Agent Catalog for prompt and tool governance, semantic caching, and vector search, all on one platform available across cloud, self-managed, hybrid, and edge deployments.

Why do AI agents fail between pilot and production? The most common causes are fragmented agent memory (agents that can’t remember prior sessions or maintain personalized context), lack of observability (no structured log of which tools and prompts the agent used and why), and point-solution sprawl (five separate systems for vector search, caching, session state, operational data, and tool registries). These are data infrastructure problems, not model problems. You can watch this on-demand webcast to learn more about the difference.

What is Agent Memory in Couchbase? Agent Memory is the persistent memory layer in the Couchbase AI Data Plane. It stores agent state at three levels: short-term memory for the current conversational context, long-term semantic memory as vector embeddings for cross-session retrieval, and profile memory for structured user attributes. Every memory block includes a JSON document with an embedding, a natural language summary, a structured context object, a timestamp, and a configurable retention TTL.

What is the Agent Catalog? The Agent Catalog is the centralized registry in the Couchbase AI Data Plane where tools, prompts, and agent functions are stored, versioned, and made inspectable. It records every tool invocation, prompt version, and data access event in a structured, queryable format, enabling compliance audits and making existing tools discoverable and reusable for teams building new agents.

Does Couchbase AI Data Plane support edge and always-on deployments? Yes. The AI Data Plane is available on Couchbase Capella and extends to self-managed, hybrid, and edge environments through Couchbase Lite and Couchbase Edge Server. They provide bidirectional sync and consistent governance at every tier.

What is MCP and how does it relate to the AI Data Plane? MCP is the Model Context Protocol, an open standard that defines how AI models connect to external tools and data at runtime. The Couchbase MCP Server implements MCP as part of the AI Data Plane, giving agents a governed, auditable interface for tool invocation with role-based access control enforced at the server layer rather than in application code.

The post Why AI Agents Fail in Production: The Data Layer Problem appeared first on The Couchbase Blog.

This tutorial shows how to embed a DOCX editor in an ASP.NET Core web application with TX Text Control. It covers setting up the editor, loading a DOCX document, and editing it with true WYSIWYG rendering, without any dependency on Microsoft Word.