muench.dev Articles (English)

magento.watch MCP: Query Magento and Adobe Commerce knowledge directly

2026-10-06T11:00:00+00:00

With the magento.watch MCP, you can query important information about Magento Open Source and Adobe Commerce directly from an AI assistant. I have been using the MCP for a while, mainly to check dependencies. The ability to quickly check whether a shop uses the official patches is also handy.

Connect the MCP without credentials

The MCP is documented at magento.watch/mcp. For Claude, for example, you can add it like this:

claude mcp add magento-watch --transport http https://magento.watch/mcp/api

In VSCode / CoPilot, you can do this through configuration, for example:

{
  "servers": {
    "magento-watch": {
      "type": "http",
      "url": "https://magento.watch/mcp/api"
    }
  }
}

Neither a password nor a token is required. That makes getting started straightforward: Once it has been added, Claude can use the tools provided to answer specific questions about releases, support periods, dependencies, security bulletins, and patches.

And here you can see the MCP in action:

Release and dependency information

For an overview of versions, the tools include get_all_versions, get_supported_versions, and get_eol_versions. These let you query all recorded versions of a distribution, currently supported releases, and versions that have reached end-of-life. get_version provides details about an individual version, including its lifecycle and system requirements. If you only need the latest stable version, you can use get_latest_version.

For upgrades and maintenance work, check_compatibility is particularly useful. The tool checks whether a specific version of PHP, MySQL, or another dependency is compatible with a release. This lets me compare requirements directly against the shop version in use, rather than manually gathering information from several documentation pages.

Security bulletins and vulnerabilities

Security information is also accessible through dedicated tools. get_security_bulletins lists Adobe and Magento security bulletins, optionally filtered by severity or publication date. With get_security_bulletin, you can retrieve a specific bulletin, its CVEs, severity, and the releases that include the fix.

For a specific shop version, there is check_version_security. This lets you check whether known bulletins affect the version and which version contains the fix. That is helpful for answering a patch question more specifically: Is the installed version affected, and which release should it be updated to?

Check quality patches

For quality patches, find_patch provides a list of patches applicable to a Magento version. The search can also prioritize results based on a described bug. get_patch provides details about an individual patch, such as variants, restrictions, changed files, and documentation.

This also makes it possible to check in practice which official patches are relevant to a shop and whether they have already been taken into account. It is a useful addition to release and security queries, especially during the ongoing maintenance of an installation.

REST API and n98-magerun2

In addition to the MCP, magento.watch also provides a REST API. This API will be used in the next version of n98-magerun2 in a command for checking database compatibility. That means the information is not only available to AI assistants, but can also feed directly into existing command-line workflows.

A community project with practical benefits

magento.watch is developed by Łukasz Bajsarowicz. He has already made many valuable contributions to the Magento community and is a core contributor. I really appreciate his work.

For me, magento.watch is a compelling project because it makes release, compatibility, security, and patch information accessible through a clear interface. The MCP saves time when checking dependencies and helps answer targeted questions about the state of a shop. If you use Claude, you can try the integration with a single command, without any password or token.

herdr: A Terminal Multiplexer for Servers and AI Agents

2026-10-05T09:00:00+00:00

For me, a terminal multiplexer is a tool for keeping several working contexts in view at the same time. These might be local shells, SSH connections to servers, or sessions with coding agents.

For this, I use herdr. It can be used as a regular terminal multiplexer and supports various coding agents out of the box. It also offers persistent sessions and the ability to connect remote machines via SSH. This lets me organize multiple terminals and agent sessions in parallel in a single tool.

Even though it is a CLI tool, it is important to know that everything can also be operated with a mouse. All panes can be moved by drag and drop, as can tabs. Menus can also be opened with a mouse click.
Of course, everything works through the keyboard too.

More than terminal windows

herdr manages multiple sessions and workspaces. This is useful when, for example, I am developing locally, accessing a server in parallel, and running one or more agents alongside that.

One important difference from several ordinary terminal windows is the persistent session: herdr is based on a client-server architecture. Processes started in a session continue running even when I leave the connection or terminal. When I return later, I can carry on there and see the current state. This applies not only to coding agents, but to processes in the session in general.

This lets me separate tasks without losing track of them: for example, one workspace per project, separate sessions for different agents, and additional terminals for server access.

Bringing agents into the terminal workflow

Coding agents frequently work directly in the terminal. herdr brings sessions, workspaces and agent integrations into a shared working environment.
This does not make herdr itself a coding agent. Rather, it organizes the environment in which agents and other processes run. The practical benefit comes when several tasks are being worked on in parallel and I want to switch between the respective sessions.

There are additional features too, such as Git worktrees for separate working states, plugins, configurable keyboard shortcuts, and tools like Neovim and Lazygit. Which of these are useful depends on how much of your own development environment you want to integrate into this workflow.

Agentic use

Herdr itself can be fully automated through the command line. It therefore makes sense for agents to control Herdr remotely too. For this, the project directly provides a suitable agent skill.

npx skills add herdrdev/herdr --skill herdr -g

The skill contains important CLI commands, for example for window management. In addition, the tool can also be controlled through a socket API.

Remote access and parallel sessions

For me, SSH access is an important part of the whole setup. Remote machines can be incorporated into the workflow, keeping local terminals, server access and agent sessions in view together.

This is particularly helpful when a task involves more than just local code. For example, you can work on a project, execute commands on a remote system, and observe the status of an agent session at the same time. The interface brings these contexts together instead of spreading them across different programs and windows.

Conclusion

I use herdr as a terminal multiplexer for ordinary shell work, SSH access and coding agents. The persistent sessions and the ability to bring multiple workspaces and remote connections together are what make it particularly interesting for my workflow.

There are other tools too, such as tuios, which may render more smoothly or look particularly stylish. Personally, I currently feel very comfortable with herdr and am significantly more productive with it.

Building My Own Uptime Kuma Widget for KDE Plasma in Around Two Hours

2026-10-02T08:00:00+00:00

Sometimes small projects come about not because you particularly want to
program something new, but because something is missing from your everyday
life. That is exactly how my new KDE Plasma widget for Uptime Kuma started.

I have been running Uptime Kuma for some time to monitor various
servers and applications. When something goes down somewhere,
I receive a corresponding notification in Discord.

That generally works well. However, a Discord message can occasionally
get lost in the noise. Especially when you receive lots of other
messages alongside it, a notification is easily overlooked.

Since I spend most of the day working at my KDE desktop, a simple idea
occurred to me: Why not see the current state of my systems directly
on my desktop?

Isn’t there already a widget for that?

Before building something myself, I naturally searched first.

What I had in mind was actually pretty simple: a Plasma widget
connects to my existing Uptime Kuma instance and shows me at a glance
whether my servers and applications are reachable.

However, I could not find an existing widget that matched my expectations.

Developing Plasma widgets was not entirely unfamiliar to me.
Many years ago, I had already written a KDE Plasmoid myself.
Back then, of course, in the traditional way and without AI assistance.

That knowledge had become pretty rusty in the meantime.
At the same time, that was precisely what made it interesting to me.

A good opportunity to try Antigravity CLI

I had been wanting to try Antigravity CLI more extensively on a real
project anyway. Until then, I had used only a small fraction of my
available token allowance.

So I thought: why not?

The project was a nice size for this. It was not an artificial
“Hello World,” but something I actually wanted to use afterward.
At the same time, it was manageable enough to observe how well a
coding agent copes with this kind of project.

I also wanted to try out how a fast Gemini Flash model performs
on an agentic coding task like this.

That turned the little widget into an experiment as well:

How far can I get with Antigravity CLI and a fast Flash model on a
real KDE Plasma project?

From zero to the first widget

I started from scratch.

Of course, my old Plasma widget gave me a rough idea of how a Plasmoid
is structured. But I no longer had the specific implementation for
current Plasma 6 fresh in my mind.

That was an important part of the experiment for me too. I did not want
to spend hours reading documentation first and completely relearning the
current KDE stack. Instead, Antigravity was supposed to take on a large
part of that work.

A first working version appeared relatively quickly.

From then on, the work mainly consisted of iterations: try the widget,
discover a problem or have a new idea, describe to Antigravity what
should change, and then test the result again.

It was precisely in this process that I found using a coding agent
particularly interesting.

The Git history captures the speed quite well

I did not time the entire session with a stopwatch. Looking back and
adding it up, it was roughly two hours.

Part of that is quite easy to trace through the Git history.

The first commit visible today was created at 8:13 p.m. By that
point, however, quite a lot had already happened and the widget basically
existed. I had started about an hour earlier.

After that, things moved quickly.

Within just 43 minutes, eleven commits were created. By then, this
was already about much more than simply displaying any data on the desktop.

Among other things, Plasma 6 compatibility issues were fixed,
redirect handling and group filtering were improved, nested monitor
groups were taken into account, and various display options were added.

A nice example is the header-only mode. The feature was added,
tried out, and corrected again just a few minutes later.

That describes my actual workflow with Antigravity quite well:

Idea → have it implemented → try it out → discover a problem → give
feedback → have it corrected → next idea.

More than a proof of concept

What surprised me a little: after those roughly two hours,
I did not simply have a technical prototype.

The widget was already something I could actually use on my desktop.

It displays the status of services monitored through Uptime Kuma,
response times and uptime values. Monitors can be displayed by group,
and heartbeat bars also let you see their history.

There are different layouts for different places of use. On the desktop,
for example, I can use a more detailed overview, while the widget can
be displayed much more compactly in the Plasma panel.

Multiple widget instances with different monitor groups are possible too.

You can also add the widget in a small form to a panel (bar):

During development, other things were added that were not necessarily
on my initial list: search and filtering, different display variants,
KDE notifications for outages and recoveries, and various ways to
authenticate against Uptime Kuma.

A relatively simple idea thus became a fairly complete Plasma widget
surprisingly quickly.

The coding agent does not replace trying things out

What I found especially interesting was how my own work changed.

I did not have to research and implement every QML component and every
Plasma 6 API myself. My task became much more about evaluating the result.

Does this really work? Does it look sensible on the desktop?
What information is missing? What behaves differently than expected?
Which feature do I want next?

Especially in a visual project, the agent cannot take over that
evaluation completely.

I had to keep starting the widget and actually using it.
But when something did not work or I did not like it, I could describe
to Antigravity quite specifically what needed to change.

This created a very fast feedback loop.

Two hours is not the whole story, of course

“Developed in two hours” quickly sounds as if AI does all the work
while you just sit beside it.

That is not how I would describe it.

I knew what problem I wanted to solve. I could judge whether the proposed
solution made sense. Through my earlier Plasma widget, I had at least
a basic understanding of what was happening. And, above all, throughout
development I decided what should happen next.

Antigravity did, however, take a great deal of implementation work and
research off my hands. I deliberately did not do Agentic Engineering; instead, I did a little vibe coding on the side to see how far you can get even without much prior knowledge.

I had the agent iteratively optimize quite a few things in the configuration.
I think the result looks pretty good too:

And that is exactly how an idea I might otherwise have written on some
TODO list became, within one evening, a tool I actually use.

My conclusion

For me, this project was a pretty good test of agentic coding.

Not because the result is particularly huge or complex, but precisely
because it solves a real, small everyday problem.

I needed an Uptime Kuma widget for my KDE desktop. I could not find one
that matched my expectations. So I started Antigravity CLI and tried
out how far I could get with it.

Roughly two hours later, I had a widget on my desktop that monitors my
servers and applications and lets me immediately recognize when
something is wrong somewhere.

The fact that a fast Gemini Flash model was enough to guide me through
QML, Plasma 6, Uptime Kuma and numerous small iterations was at least
as interesting to me as the widget itself.

Above all, the experiment showed me one thing: coding agents do not
automatically make your ideas good. But they can make the distance between
“That would actually be useful” and “That is now running on my
computer” remarkably short.

I published the widget’s source code on GitHub.
https://github.com/muench-dev/uptime-kuma-plasma-widget

The widget can now also be installed directly through the KDE Store:

Home Assistant in My Homelab: Making Existing Data Visible and Optimizing with AI

2026-09-29T14:46:00+00:00

I wanted to get more out of my existing Home Assistant installation. Not because I was missing a new system, but because I realized that quite a lot of information was already being collected around the house. It just was not always arranged usefully or easy to find at a glance.

So I had Claude Code and OpenCode review and rework my Home Assistant configuration. OpenAI models were used in both cases. The result is more than a new dashboard: it shows how existing infrastructure can be put to better use, how monitoring lays a foundation for automations, and where coding agents can help maintain a system that has grown over time.

Making the existing data easier to read

Most of the rework concerned Home Assistant’s “Overview” view. I rebuilt seven other views following a common pattern. Instead of tile collections that had evolved differently, there are now clearly structured sections with headings and icons, consistent tiles, and compact history charts.

Which measurements appear depends on the area. They include temperature, humidity, radon, electrical power and CO, among others. A tile shows me the current state; a small history chart helps put it into context. Is a temperature unusual, or has it been like that all day? Has a measurement just changed, or is the trend stable? A graph often answers more than another number does.

The goal was not to fit in as much data as possible at once. A dashboard should answer the questions that actually arise in everyday life. Empty sections and duplicate cards have therefore disappeared. I removed references to devices that no longer exist and a broken camera card. Labels and typos were cleaned up too. That sounds mundane, but it makes an interface easier to read and prevents outdated entries from undermining trust in the display.

Additional functions complement the existing views: a weather forecast, music controls, options and child lock for the dishwasher, and the battery levels of the smoke and CO detectors. The guest Wi-Fi switch is now in the network section. Its automatic shutdown at 10 p.m. remains in place. This is a small example of how not every improvement needs new sensors. Sometimes it is enough to move an existing function to where you expect it to be.

Warnings that appear only when needed

A common weakness of smart-home dashboards is the constant presence of status information. When every state is displayed equally prominently, an important message is just one tile among many. I therefore wanted warnings that appear only when there is a specific reason for them.

Among other things, the views highlight smoke and CO alarms, low batteries, detectors at the end of their service life or outside their normal state. Protective shutdowns of Shelly outlets are also reported, for example due to overheating, overcurrent, overvoltage or overload. There are also notices for low dishwasher salt and rinse aid, and for a finished dishwasher cycle. A detector with a weak wireless signal remains visible for as long as the problem persists. In the case of a smoke or CO alarm, I can silence the detector directly in the corresponding section.

For the outlets powering refrigerators and freezers, it was also important to me that touching a tile should not accidentally switch off the appliance. This is a small usability change, but an important separation between displaying status and taking action: not every piece of information needs to be a switch at the same time.

This kind of dashboard is more useful to me than the most complete possible device list. I still see relevant states, but the interface directs my attention toward deviations. For that to work, the underlying entities naturally need to be maintained. A pretty warning is no help if the integration behind it stopped providing reliable data long ago.

Measurements become automations

A new dashboard now also shows usage of several AI services: costs, requests and token counts for OpenAI, OpenRouter and Opper AI. It also includes an overall total and the current day’s costs. At the time I recorded it, the daily value was US$1.16.

These metrics are interesting not just because they explain a bill. They can also trigger a concrete action. I set up a Home Assistant automation that notifies me through Discord when daily costs exceed US$10. There is a Discord integration and a script for sending the message for this purpose.

At this point, no generative AI is needed to decide whether costs are “high.” The threshold is clear: if the daily value exceeds it, a message is sent. That makes the rule easy to understand and predictable. AI was helpful when working on the configuration; during regular operation, an ordinary automation makes the decision.

For me, the sequence matters: first the data must be available, then I can visualize it usefully. Once measurements are reliable, understandable rules can be built on them. Without metrics, I would only be guessing whether a threshold had been reached. With an automation, I also do not have to hope that I happen to look at the right view at the right time.

The fact that Home Assistant logs to my Discord server also helps me notice messages outside the dashboard. A notification is not an end in itself. It should clearly state what happened and why I should pay attention. To begin with, a single threshold warning is better than a flood of messages that I eventually ignore.

Coding agents for the work that otherwise gets left undone

Claude Code and OpenCode helped me review and rework the existing Home Assistant configuration. Particularly in a system that has been in use for a while, tasks accumulate that each seem manageable on their own: standardizing views, finding old device references, removing duplicate cards, correcting labels, and building warnings consistently. Taken together, these tasks consume time that everyday life often uses up on other things.

A coding agent can analyze what is there, identify relationships, and implement proposed changes. That does not mean every suggested change is automatically correct. Home Assistant is connected to real devices and can therefore have real-world consequences. I treat the agents as tools for analysis and configuration work, not as autonomous house managers. Changes must remain traceable and be checked afterward. Particularly with switches and automations, it should be clear which entity is being addressed and what consequences an action has.

For me, the practical gain is not that AI makes every decision for me. It lowers the barrier to cleaning up a system that has grown over time. Tasks I kept putting off can be tackled more deliberately when an agent helps with searching and structuring. Responsibility for the changes and for operation still remains with me.

New information from existing integrations

Alongside the dashboard work, the information available from individual integrations has expanded too. After a Home Connect update, there are additional notices about low salt and rinse aid, as well as reminders for machine care and filter cleaning. A separate switch for the screen has been added for the television in the living room. For the photovoltaic system, another sensor shows how long monitoring data has been missing.

These are not major platform changes. They are additions within infrastructure that already exists. If an integration provides a useful new sensor, it can be added to a dashboard or used as an automation trigger. The prerequisite is that I notice the information and correctly understand its state.

Visibility is not troubleshooting

The rework did not eliminate every problem. The doorbell integration no longer provides a camera. One device was temporarily unreachable; the log contained around 530 timeout messages about it. There are also individual unreachable devices and still a detector with a weak wireless signal.

This does not contradict the improved dashboard. Quite the opposite: a good overview should not give the impression that everything is fine merely because the interface looks tidy. It helps make faults and outages easier to recognize. But the cause may lie with an integration, a device, the network connection, or another dependency. That needs to be investigated separately.

This boundary matters for AI too. An agent can help narrow down a problem using logs and configurations. But it cannot conclude that a device works reliably from a nicely formatted view alone. When data stops arriving, that state must remain visible as a problem rather than silently being treated as normal.

An approach you can apply to your own homelab

Perhaps the following steps will be interesting for your homelab too:

Inventory existing data. What sensors, integrations and states are already available? Before buying new hardware, it is worth looking at what is already being collected.
Organize for everyday usefulness. A good overview groups information by purpose and shows trends when history helps put things into context.
Make warnings conditional. Only relevant deviations should demand attention. Constant status messages make you tune out.
Measure first, automate second. A stable sensor value and a clear rule are a better foundation than a complicated automation built on uncertain data.
Use AI for analysis and routine work. Coding agents can help search and clean up. Changes, particularly those with real-world consequences, must remain verifiable.
Do not hide faults. A dashboard must not conceal problems. Outdated data, unreachable devices and integration errors need attention too.

My Home Assistant was already an important part of the homelab. The rework has made it more useful to me: information already in the system is easier to find, selected problems stand out sooner, and a new cost overview has led to a concrete Discord warning.

AI helped me tackle work for which I otherwise had little time. The automations deliberately remain understandable, and Home Assistant executes clearly defined rules. For me, the real value lies in the combination of existing infrastructure, visible metrics and verified AI assistance.

What data in your homelab or existing IT is already available, but not yet visible where it would really help you?

Automatically Tagging LinkDing Bookmarks: My AI Workflow with n8n, Opper AI and kev

2026-09-25T08:00:00+00:00

In everyday life, I save links quickly as I go. Finding them again later is another matter. Good search is important. But I also like having tags so I can spot connections and similar links more quickly. That is why I built a workflow for my self-hosted Linkding instance that automatically categorizes new bookmarks and existing ones without tags.

It brings together two browser extensions, the Linkding REST API, n8n, and a small model through Opper AI. The crucial part is not simply “AI creates tags,” but the classification system that determines how those tags are assigned.

Collecting and finding links in the browser

I use two extensions that perform different jobs:

LinkDing Extension (Chrome Store) saves a link in my Linkding instance. The extension also displays Linkding search results in the background on search pages such as Google. So when searching, I can see whether a link is already in my collection.

LinkDing Bookmark Sync (Chrome Store) synchronizes my tags as folders in the browser and places the matching bookmarks beneath them. This lets me access saved links through the familiar folder structure too.

I run Linkding self-hosted. For login, I use SSO through Authentik. That keeps the collection under my control while still making it searchable through the web interface.

The n8n workflow handles untagged bookmarks

The automation runs in n8n. Through the Linkding REST interface, I retrieve bookmarks that do not yet have a tag. The workflow therefore does not reprocess the entire collection on every run, but focuses on the outstanding entries.

I pass the bookmark data to a small, separate n8n workflow. Its input parameter is called body and is simply a string. This keeps the component independent of the original workflow: it receives the information about a bookmark, classifies it, and ultimately produces a tag list.

For classification, I use Opper AI as a model router and the kev 4b model. The component calls the API twice. Classification takes place in two stages and is based on a classification system I developed together with Gemini. It is more a kind of worldview than a loose collection of individual topic words: the tags should place links into a structure that fits the way I organize knowledge and interests.

I deliberately do not describe these two steps as some magical “AI understands everything” feature. The model receives the bookmark information and the classification system’s instructions; it returns the tags that I use for tagging.

Why a small model is enough here

For this task, I do not need a model that argues at length or produces an elaborate text. It should quickly categorize a link according to a predefined taxonomy. This is a narrowly defined classification task, for which a fast System 1 model suits me better than a large model with elaborate reasoning.

The cost also supports this choice. On the plan I use for kev 4b, the charge is US$0.04 per one million input tokens; output tokens cost nothing. Because the workflow accesses the API twice, input is naturally the relevant cost factor. For the amount of text associated with a bookmark, that remains very inexpensive. This specific price refers to the plan I use and may change.

In practice, processing is also fast enough that automatic tagging does not become a task of its own. A link arrives in Linkding, the workflow classifies it in the background, and the tags are then available for search and synchronization.

The existing collection gets new tags too

The workflow was useful for more than just new bookmarks. I also used it to retag all my existing bookmarks once. That was important, because a good taxonomy only shows its value when it includes not just today’s links, but also the archive built up over the years.

Since then (okay, only since yesterday), tagging has become noticeably faster and more consistent for me. Having simply had all the tags reassigned, I can clearly see the difference compared with before. I do not have to rethink which tag I used for a similar link every time. And because the tags are subsequently visible as browser folders too, the same organization works in Linkding and in the browser.

What I need to keep in mind

Automatic tagging does not automatically make classification correct. If the taxonomy changes or a bookmark is ambiguous, a tag may be missing or inappropriate. The system therefore stands or falls with a clear, well-maintained tag structure. The two classification steps do not replace this work; they simply apply the structure more consistently.

The data path also deserves attention: Linkding is self-hosted, but the bookmark information I pass to the classification component is forwarded to Opper AI for model processing. Self-hosting alone therefore does not mean that every processing step stays local. For private or confidential links, I need to consider what data I send to the router and the selected model.

Conclusion

For me, this workflow is a good example of where a small model can make more sense than the largest possible one: the task is clearly bounded, the tag structure is defined by me, and the result should be available quickly and cheaply.

With Linkding as a self-hosted archive, the two browser extensions for collecting and accessing links, and n8n for automation, this has become a process that organizes new and existing bookmarks more consistently. The biggest effort was not the two API calls, but developing a classification system that actually works for my collection.

I also use Readeck to collect material for articles or as a “read it later” tool. It (deliberately) comes without AI tagging. I have integrated the same tagging logic there too. But that is a topic for a separate blog article.

My Hermes Agent Takes Care of Our Minecraft Server

2026-09-24T15:00:00+00:00

My son wanted me to install a Minecraft plugin on our server. I was at work at the time. Instead of putting the task off until later, I handed it to my “Homelab” Hermes profile. The agent already knows the server from its inventory and manages it for me.

It handled the installation and discovered a problem with the update source during setup: the updater pointed to a different project with a similar name. The agent brought this to my attention and suggested an appropriate correction. We agreed on the change together and implemented it. We also adjusted the settings for safe operation together.

From assignment to verification

The agent did more than install the plugin file. It checked the server’s state, identified the issue with the update source, suggested an improvement, and carried out the agreed changes.

Afterward, it restarted the server in an orderly manner and checked that the plugin was active, the server started cleanly, and the updater correctly recognized the configured plugins. The checks were successful.

An agent with context about my homelab

The difference from a one-off chat response: my Homelab profile already knew the server and had access to the information needed to administer it. I did not first have to explain which machine I meant or carry out the individual steps myself. I could hand over the task and also received feedback when the agent encountered a problem.

The agent handled the routine technical work. We agreed together on changes that affected the server. It then verified the result. That is exactly the combination I care about: the agent can complete tasks independently in a familiar environment, flags problems, and involves me when a decision is needed.

For me, this was practical relief while I was at work. My son got the plugin he wanted sooner, and I could keep working.

Hindsight: An Agent Memory System That Really Impressed Me

2026-08-27T07:00:00+00:00

Anyone who works with Claude Code, Codex CLI or opencode every day knows the problem: at the end of every session, the agent is back to square one. You explain the tech stack, the team conventions, and why you abandoned Redis caching three months ago for what feels like the tenth time. Notes in system prompts or CLAUDE.md files help, but they do not scale—they capture only a static snapshot, not a growing, evolving knowledge base.

I have been using Hindsight, an open-source memory system from Vectorize.io, for a few weeks, and I am pretty taken with it. Or let us call it what it is: for the first time in a long while, a software solution has genuinely excited me. It does exactly what you imagine “agent memory” should do when you do not reduce it to the naive vector database solution. It has opened up new worlds for me, both conceptually and technically.

Why should you use Hindsight?

Before I get into the technical details, here are the three reasons that tipped the balance for me:

Greater context continuity: Agents retain relevant prior knowledge across sessions, delivering consistent, personalized recommendations instead of starting from scratch with every new session.
Better accuracy on complex questions: Temporal and graph retrieval combined with automatic observation consolidation noticeably improve the hit rate, particularly for historical or indirectly connected facts.
Controlled, explainable memory logic: Missions and directives create safety and compliance guardrails, while evidence tracking makes it clear what an answer is actually based on.

What Hindsight is—and what it is not

The most important point first: Hindsight is not simply a vector database with a pretty API wrapped around it. Anyone who throws in raw data and hopes cosine similarity will produce the right answer is regularly disappointed by naive RAG approaches. Once you have a few hundred memories covering different topics and time periods, the principle of “embed everything, retrieve Top-K” often breaks down.

Hindsight takes a different approach. PostgreSQL with the pgvector extension provides storage in the background, but what gets used is not the raw data. It is the result of an extraction process: structured facts, resolved entities (“Alice” and “my colleague Alice” become the same entity), timestamps for temporal analysis, and a knowledge graph mapping relationships between entities. If you are now worried about your data... okay, the documents are still stored in the Postgres database as “Document” too. But the raw documents are not the interesting part of the overall process; the processed data is.

Everything connects via MCP—Claude Code, Codex, opencode, Cursor, VS Code, practically any MCP-capable client can connect. For internal processing (fact extraction, entity resolution, reflect operations), Hindsight needs its own LLM provider, independently of the model the actual agent uses. That is a detail I like: you can deliberately use a cheap, fast model here because this processing runs in the background and does not affect the quality of the actual agent responses. I used the GPT-5.6 Luna model for my tests because, initially, I was paying out of my own pocket. Despite the inexpensive model, I got really good results. You can also use multiple models in Hindsight and fine-tune everything. Honestly, I have probably tried only 30–40% of the features so far. But that is fine. You get results quickly, can work with the data, and can improve it yourself. How? That is coming next.

The three core operations

Hindsight offers three central operations, available as MCP tools:

retain—Store. You feed Hindsight text (a single fact, an entire conversation, a document), and an LLM extracts structured facts, resolves entities, generates embeddings, and indexes everything for later searches in the background. Important: you should not summarize or extract facts yourself beforehand—Hindsight needs the full context of a conversation, otherwise “yes, exactly” or “I will take option 2” becomes meaningless text.

recall—Search. Four retrieval strategies run in parallel: semantic search, BM25 keyword matching, graph traversal across the knowledge graph, and temporal filtering. The results are then sorted using cross-encoder reranking. This is the real advantage over a simple vector search: a question such as “What did we decide about caching?” finds the right answer even when the original memory uses different terminology.

reflect—Synthesize. Reflect goes beyond simple retrieval and lets an LLM draw conclusions across multiple memories—for example, in response to “Which tech stack would you recommend based on my previous decisions?”

flowchart LR    
    subgraph YourApp["Your Application"]
        A["AI Agent"]
    end

    subgraph Hindsight["Hindsight"]
        API["API Server"]

        subgraph MemoryBank["Memory Bank"]
            direction TB
            MM["Mental Models"]
            OBS["Observations"]
            ME["Memories & Entities"]
            CH["Chunks"]
            DOC["Documents"]

            MM --> OBS
            OBS --> ME
            ME --> CH
            CH --> DOC
        end
    end

    A -->|retain| API
    A -->|recall| API
    A -->|reflect| API

    API --> ME

Extraction strategies and tagging

One point that is underestimated in practice: not every data source should be processed the same way. Hindsight offers named retain strategies for this—for example, verbatim for content that should be stored word for word, or chunks for larger documents split into sections. These strategies can be defined in the bank configuration and selected explicitly in the retain call depending on the source.

There is also a tagging system with so-called entity labels: controlled vocabularies following the key:value pattern, such as user:christian or topic:architektur, which can be extracted automatically during storage. For purely content-based searches, you often do not need this at all—entities end up in the knowledge graph anyway and drive graph-based search. For explicit filtering on entity-like values, however, tags are worth their weight in gold, especially when you want to keep multiple projects or customers clearly separated within a bank.

Mental Models: living documents

What convinced me most were the Mental Models. You define a question—for example, “Which architectural decisions were made for project X?”—and Hindsight generates a document that updates automatically whenever new memories are added or existing documents change. You therefore do not have to run a full reflect across the entire memory collection for every request. Instead, you get a kind of precomputed, always up-to-date summary.

Technically, this runs asynchronously through a queue: the actual LLM-assisted generation happens in the background, an API call initially returns only an operation ID, and the finished result is available after a few seconds. This is thoroughly thought through, but it also has a downside—more on that shortly.

Scaling is not a problem either, because the architecture also includes worker instances that can be scaled using Kubernetes. All of that is possible. In my homelab setup, a single worker in a fixed Docker container does the job.

Visualization

The Control Plane—Hindsight’s admin UI—includes the Constellation View: an interactive, zoomable graph visualization of entity relationships with heat-gradient coloring, also usable in dark mode. For me, this is more than just a nice feature. With a growing knowledge graph, the visual overview is enormously helpful for getting a feel for what your memory bank actually “knows” and where extraction might have gone wrong.

Of course, you can also filter, zoom, and inspect the individual underlying documents.

Feature overview

A few points from the full feature list that have not come up in this article yet but are part of the picture:

Hierarchical memory types: Alongside Mental Models (curated, self-defined summaries), there are Observations—evidence-backed beliefs automatically consolidated from raw facts—as well as World Facts and Experience Facts. This separation ensures that reflect checks Mental Models first when answering a question, then Observations, and only turns to raw facts as a last step.
Multi-strategy retrieval (TEMPR): The four parallel search strategies in recall—Semantic, Keyword/BM25, Graph, Temporal—operate under the name TEMPR and are merged using reciprocal rank fusion before cross-encoder reranking takes over. This makes retrieval robust even for questions involving temporal or graph-based connections.
Observation consolidation: After every retain call, a consolidation process runs automatically in the background, comparing new facts against existing Observations, deduplicating them, and adding evidence references. Observations that may have been superseded by newer, not-yet-consolidated facts are marked “stale” and verified against the raw facts before use.
Temporal reasoning: Queries such as “last spring” or “in June” are resolved not just semantically but explicitly by time—a field in which pure vector search typically fails.
Mission and policy configuration: At bank level, you can define a mission specifying which knowledge should be prioritized, along with immutable directives as compliance guardrails and disposition traits such as skepticism, literalness, or empathy that influence how reflect weighs arguments. Important: these settings affect only reflect, not recall.
Evidence-backed answers: Observations refer to their source memories, including quoted evidence and proof counts. This makes an answer’s derivation understandable rather than something you accept as a black box.
Clients & SDKs: Official SDKs for Python, TypeScript and Go, plus a CLI and HTTP API—making integration into existing agent stacks beyond MCP straightforward.
Deployment options: Alongside the local Docker setup I use in my homelab, there are Helm charts for Kubernetes, a pip installation for quick local testing, and an integration hub for connected data sources.

How does data get into the system?

Data can enter memory in several ways. When using the MCP server, you can simply store something through the retain tool. Tags and a unique document ID can be defined for each captured document. Defining the document ID is optional. If none is supplied, the system creates a UUID.
If you want to store raw data, such as chat histories, using the generated UUID is sufficient. For data such as the content behind a web page, the document ID can also be a URL. If a new document is submitted with the same document ID, Hindsight updates the existing entry too.
Hindsight also lets you define different data extraction strategies for different sources. You can influence RAG-specific parameters such as chunk size as well.

Because Hindsight was designed consistently so that everything the UI does communicates through a REST API, using that same API to import data is straightforward too.
As an example, I installed an n8n community plugin that simply exposes the three basic operations in an n8n node.

My homelab setup

I set everything up in my homelab rather than the cloud—two LXC containers, one for the API and one for the admin UI, or Control Plane. I did not have to set up a new database server: I already had a PostgreSQL server with the pgvector extension running and only needed to create an additional database there. That made setup considerably simpler. Anyone already running a Postgres instance with pgvector is ready in minutes, rather than having to wrestle with the embedded PostgreSQL variant from the Docker quickstart.

For the internal processing LLM provider, I quickly connected OpenRouter and chose GPT-5.6 Luna—the inexpensive, latency-optimized variant from OpenAI’s GPT-5.6 series, intended for precisely these high-frequency but not particularly demanding background tasks such as fact extraction. The model can easily be swapped out, though: Hindsight supports a broad selection of providers, from OpenAI, Anthropic and Gemini to local models through Ollama or llama.cpp. Anyone who prefers to keep internal processing completely offline, without external API calls, can now do that too.

Integration with other systems

Via MCP, Hindsight can connect practically anywhere a client speaks the standard—Claude Code, Codex CLI, opencode and other coding agents are supported directly, in some cases even with automatic ingestion without an additional setup step.

The MCP server is built directly into Hindsight and can be configured separately for each memory bank. You can also restrict the MCP tools.

I have not restricted anything in my setup because I already have a LiteLLM gateway in between anyway.

Use cases

The most obvious use case for me personally is not primarily technical at all: I want to prepare data about the football club Wormatia Worms to lighten the workload of the office staff. Instead of answering every request manually, an agent could draw on a Hindsight bank containing historical information, club rules, and recurring questions, genuinely taking on some of the communication burden.

Alongside that, I am currently building a second bank of my own: I am adding the club’s history, season results, and player profiles. The interesting part here is not simply retrieving individual facts, but having the system independently discover statistical peculiarities and relationships across the imported data—for example, that a particular season had an unusually high number of draws, or that a player scored disproportionately often across multiple seasons. That is precisely what reflect is for: not just retrieving facts, but drawing conclusions across the entire dataset. This becomes especially interesting for the club’s archivist, who wants to ask questions such as “When was the longest winning streak?”—questions that no individual record answers, and that emerge only from considering many season results together.

In technical project environments, I see at least two more useful scenarios:

Architecture and policy memory: An agent that keeps track of software architecture decisions, coding guidelines, and project conventions and is available to developers as a question-and-answer resource directly in their coding tool—without first having to search a wiki.
Requirements completeness checks: In projects where requirements are captured continuously, an agent with access to the accumulated memories can check whether all necessary documents and information are available and specifically highlight gaps. Especially in business contexts with many stakeholders, this is a scenario that delivers real value.

Assessment

What works well: getting started is pleasantly straightforward, especially if—as in my case—a Postgres/pgvector instance is already available. MCP as the connection standard means you do not have to build a separate integration for every client. In practice, the combination of multi-strategy retrieval and reranking produces noticeably better results than a simple vector search, particularly with larger memory collections spanning many topics.

Are there things about this approach that bother me? Not really, but you should be aware that as the amount of information grows, and with every Mental Model, the effort required to keep everything up to date increases too. Token costs can certainly add up.
Every retain operation means additional LLM calls for internal processing, which accumulate at high volumes. And the ecosystem’s maturity is not set in stone yet. Integrations can change at relatively short notice.

It really comes down to whether you have recognized context/memory as something valuable for yourself.

Business outlook

For a project environment like the one I know at valantic, I see the greatest leverage in agents retaining project context, customer preferences, and architectural decisions across sessions. That means less time spent repeatedly explaining context and more time available for actual value creation. It is a tangible productivity gain, particularly in longer projects with changing points of contact.

At the same time, governance cannot be ignored: where do the extracted facts end up, who has access to the memory bank, and how cleanly can customers or projects be separated? Self-hosting via Docker or, as in my case, LXC containers in your own homelab is a valid answer here—you retain full control of the data instead of entrusting it to a cloud provider.

Conclusion

Hindsight is the first agent memory system that immediately and genuinely excited me, because it does not reduce memory to “throw text into a vector database.” Instead, it combines structured facts, entities, temporal context, and a knowledge graph. Setup in my own homelab was surprisingly straightforward thanks to the existing Postgres/pgvector infrastructure, and the combination of the MCP standard and flexible LLM provider selection makes the system interesting for very different scenarios—from day-to-day club work at Wormatia Worms to architecture memory in technical projects. I will continue expanding this over the coming weeks and report back once concrete workflows emerge.

mage-remote-run with JSON Body Support and Other New Features

2026-06-25T07:00:00+00:00

Two releases in one day — that happens when features are ready. On June 17, 2026, I released v1.9.0 and v1.10.0 of mage-remote-run. The highlight in v1.9: Virtual Commands now support JSON request bodies — making POST and PUT requests against the Magento REST API possible without writing your own JavaScript code. v1.10 brings cleaner plugin infrastructure: incompatible plugins are now detected during loading and rejected with a clear error message.

v1.9.0: Virtual Commands with JSON Body, Choices, and Interactive Prompts

Virtual Commands have been a central extensibility feature since v1.4: define REST requests through configuration, without having to write JavaScript. Until now, they were limited to GET requests. That is now history.

JSON Body Templates

With body in the command definition, POST and PUT requests can be sent directly from the configuration. The body is a JSON template. Options are embedded as placeholders and substituted at runtime.

{
  "name": "customer update-email",
  "method": "PUT",
  "endpoint": "/V1/customers/:id",
  "description": "Update customer email address",
  "body": {
    "customer": {
      "id": ":id",
      "email": ":email"
    }
  },
  "options": {
    "id": {
      "type": "string",
      "required": true,
      "description": "Customer ID"
    },
    "email": {
      "type": "string",
      "required": true,
      "description": "New email address"
    }
  }
}

mage-remote-run customer update-email --id 42 --email new@example.com

This opens up the entire Magento REST API to Virtual Commands — not just read operations, but write workflows as well, without custom plugin code.

You can find the full documentation here: mage-remote-run.muench.dev/extensibility/virtual-commands

Choices for Option Definitions

Options can now have predefined choices. This makes commands more user-friendly and prevents invalid input:

"options": {
  "status": {
    "type": "string",
    "required": true,
    "description": "Order status",
    "choices": ["pending", "processing", "complete", "canceled"]
  }
}

In interactive mode, choices appear as a selection menu. Via the CLI, invalid values are rejected immediately.

Interactive Prompts for Missing Required Options

Virtual Commands now prompt interactively for missing required options instead of aborting with an error message. The behavior depends on the context: a prompt appears in the terminal; in CI/CD pipelines, the error is reported as before. Where possible, variables already defined by default by CI/CD systems such as Gitlab-CI or Github Actions (such as CI=1) are detected automatically, so interactive mode cannot block the pipeline.

For pipelines, interactive mode can also be disabled explicitly:

NON_INTERACTIVE=1 mage-remote-run my-command
# alternativ:
NONINTERACTIVE=1 mage-remote-run my-command

Both environment variables are accepted as aliases, in the spirit of Homebrew conventions for shell scripting.

Other Changes in v1.9

Performance: Config I/O now runs fully asynchronously (fs.promises instead of synchronous fs) — noticeable when switching profiles frequently
Performance: findRegisteredPluginIndex uses Promise.all for parallel checks
Fix: Swallowed errors in catch blocks have been fixed — errors are now visible instead of silently ignored
Refactoring: Duplicated filter-matching logic has been extracted into parseFilterOption
Deps: axios, zod, inquirer, and @modelcontextprotocol/sdk updated to current versions

v1.10.0: Plugin Compatibility Checks via peerDependencies

Plugins have declared a peerDependency on mage-remote-run since v1.6. Starting with v1.10, it is actually evaluated during loading.

If a plugin requires a version of mage-remote-run that does not match the installed version, loading aborts with a clear error message — rather than inexplicable runtime behavior.

This is the usual principle: explicitly bad is better than silently wrong. Anyone developing or using plugins declares the peerDependency in the plugin's package.json:

{
  "name": "my-mage-remote-run-plugin",
  "peerDependencies": {
    "mage-remote-run": ">=1.10.0"
  }
}

The check runs during plugin loading — before commands are registered. Incompatible plugins are skipped and the error is logged.

Update

npm update -g mage-remote-run

Or straight to the current version:

npm install -g mage-remote-run@latest

Feedback and bug reports via GitHub Issues, as always. If you use Virtual Commands in production or develop plugins... I would love to hear about your experiences.

valantic Becomes an Anthropic Partner — and I Was Part of It

2026-06-18T08:46:00+00:00

valantic has officially become a Select Partner in Anthropic's Claude Partner Network (Services Track) — one of the very first consulting and solutions companies in Europe to do so. I had the opportunity to contribute to the substance of this process and was personally part of the training required for it.

What This Partnership Means

A partnership with Anthropic is not just a marketing agreement. To become a Select Partner, you have to demonstrate that you really understand the subject: Claude, the Anthropic ecosystem, the architecture behind agent systems. And you have to be able to pass on that knowledge — internally to colleagues, but also in customer projects and training sessions.

The thinking behind this makes sense: Anthropic wants to ensure that implementation partners do not just sell licenses, but deliver genuine added value. That requires the people advising customers to know what they are talking about.

London: Training to Become a Trainer

Part of demonstrating this was a training course in London that I attended together with my colleague Alexander Weinfurter. The goal was clear: we were to acquire the knowledge needed to train others — both internally at valantic and for customers.

In terms of content, it was an intensive format. We explored evaluating prompt results in depth — a topic often underestimated in practice. It is not enough to build a prompt that works at first glance. You need to be able to measure systematically whether a model responds consistently, correctly, and appropriately for the use case at hand. There are methods and frameworks for this, which we worked through in London.

Another focus was building and deploying agents in the cloud. We covered how to set up production-ready AI agents, what infrastructure is behind them, and where the typical pitfalls lie. This is precisely the area that determines success or failure in many projects: not the model itself, but how it is embedded and used.

We also compared various Anthropic models and developed a sense of which model makes sense for which purpose, and when.

What I personally enjoyed most: the direct exchange with Anthropic employees, AI architects, and my valantic colleague. Alexander, for example, was much better at optimizing prompts. That is how you learn from each other. Formats like this give you a different perspective from documentation and blog posts. Questions you cannot easily ask in everyday work can be answered directly there.

What This Means for Customers

When I look at valantic's page on Claude implementation, I see exactly what we worked on in London reflected there. The approach is not "switch on AI and you're done," but a structured process: from initial exploration through a pilot with a measurable business case to a company-wide rollout.

I find one aspect valantic explicitly mentions particularly important: many companies fail when moving from individual tests to production use. Not because the model is bad, but because strategy, governance, and integration are missing. That matches what I experience in projects. The technology is rarely the problem.

As a concrete starting point, valantic offers Claude Code workshops for development teams — a direct, practical route into Anthropic's agentic coding capabilities. For developers who want to understand what AI-assisted software development looks like in practice, this is a good first step.

Select Partner status also means that valantic has direct access to Anthropic expertise and roadmaps. In a field evolving this quickly, that is no small matter. Getting earlier access to information or models is a competitive advantage, especially right now.

Conclusion

I am glad valantic took this step — and even more glad that it involved genuine, substantive effort. Training in London, in-depth work on evaluation, deployment, and architecture, direct contact with Anthropic. This is not a badge on the website, but a foundation for projects that actually work.

Anyone wanting to take Claude seriously in an enterprise context now has a contact at valantic who knows what they are talking about.

Google Cloud Summit DACH 2026

2026-06-15T08:25:00+00:00

Last week I attended the Google Cloud Summit DACH in Frankfurt for valantic. The journey was relaxed: by train with the Deutschlandticket, climate-friendly and without the stress of finding parking. Even the supporting program set the tone for the two days — large-scale, professional, well thought out. Several thousand attendees, a free event including food and drinks. Google is spending real money on this.

Day 1: The AI Experience Walk

For me, the first day revolved around the AI Experience Walk — a kind of walk-through AI exhibition where Google presented its solutions along the entire value chain. Everything was represented, from the first customer contact to internal process automation.

Google itself shared insights into how development has changed through the use of AI. More and more developers work exclusively with prompts and no longer really use the IDE itself.

What kept coming through for me was that "grounding" simply needs to be taken much more seriously. Tests need to repeatedly and automatically verify the results, particularly when working with your own data. Test-driven development is back, but different from how it used to be.

What impressed me most: live remote video translation into 15 languages, in real time, directly in the video stream. This was not a demo video or a "coming soon" — it worked. Moments like that show where AI really stands right now. Not everything is still just a promise.

A second major topic on the first day was digital sovereignty. This is not a new topic, but it was striking how prominently Google positioned it. Who controls the infrastructure, who has access to the data, where do the models run? For many companies, these are no longer academic questions but concrete decision criteria when choosing a platform.

Day 2: Hands-on Rather Than Hype

Day 2 was more valuable for me. Less stage, more workshop. In the hands-on sessions, you could get straight to work yourself — and that makes a difference.

I migrated an MCP server to Google ADK live — right at the event, not prepared beforehand, not in a controlled demo environment. It worked, and that was a good sign. The ADK is practical enough to work with spontaneously.

A talk on RAG (Retrieval-Augmented Generation) using a specific use case — legal texts — was particularly interesting. The challenge with legal documents is not just finding the right passage — but also citing it correctly, with a reference to the relevant section and in the right context. That is exactly what was demonstrated. A use case with real requirements, where poor results would have real consequences. RAG needs to work more than just "most of the time" here.

Google as the Only Full-Stack AI Provider

One observation runs through both days: Google is the only provider that delivers hardware, software, and platform for AI from a single source. Its own TPUs, its own models (Gemini), its own cloud infrastructure, its own developer tools. That is a different starting position from providers that rely on external chip manufacturers or third-party infrastructure.

Whether that is an advantage depends on what you are looking for. Anyone wanting to go deep into the Google ecosystem gets a consistent stack experience. Those prioritizing independence and portability may see it differently. Still, I find it remarkable that no other hyperscaler can offer this combination at this depth.

Conclusion

Two days, several thousand attendees, no admission fee. Google is visibly investing in community and visibility — and it pays off. You do not leave an event like this with finalized decisions, but with a good sense of where things are heading.

For me personally: day 2 delivered more than day 1. Not because the AI Experience Walk was uninteresting — but because nothing can replace hands-on experience. Migrating an MCP server live and getting immediate feedback is worth more than ten slides on the same topic.

If you have the opportunity to attend the next Google Summit: it is worth it.