DEV Community: Fran Bar Instance

Your AI Agent Forgets You Every Time? Meet memento-context

Fran Bar Instance — Fri, 10 Apr 2026 13:30:23 +0000

If you use any AI Agent (like Claude, Cursor, Windsurf, or similar) for coding, this has definitely happened to you:

"I prefer concise answers in Spanish, please."

"Sure, I'll keep that in mind."

The next day (or even in another conversation the same day):

"Here is a detailed explanation in English…"

No memory between sessions. You waste time repeating the same things over and over.

memento-context solves this problem. Here is an MCP (Model Context Protocol) server that gives your agent persistent, scoped memory, completely local and no-nonsense.

What does it actually do? It injects small notes and reminders at the start of every conversation. Short notes, one or two lines, to avoid saturating the agent's context. Just enough so it remembers your preferences or the rules of each project without becoming annoying.

And yes, it's open source and on GitHub:

https://github.com/FranBarInstance/memento-context

What is MCP and why does it matter?

MCP is an emerging standard that allows AI applications to connect to context servers running on your machine. These servers expose tools that the agent can call, just like it uses a browser or a code interpreter.

What does MCP solve? Until now, every conversation with an AI agent was its own isolated world. The agent didn't know who you were, what your preferences were, or how you work on each project. MCP creates a bridge: the agent can call these tools to read and write memory in a structured way.

memento-context is one such server, specialised in long-term memory. It does it cleanly, without cloud, without magic.

How it works: three levels of memory (the second one is coming)

The design is very deliberate. No "dump all tokens and see what happens". Right now you have two operational levels, and a third one on the way:

Level 1: Notes – fully operational

Short, high‑signal statements (1-2 lines).
Automatically injected at the start of every session.
Two scopes:
- global: follows you across all projects.
- repo: only for the current repository.

Example (global):

"I prefer direct answers in Spanish, without explaining basic concepts unless I ask."

Example (repo):

"This project uses DDD with hexagonal architecture. Tests are written before the code."

Level 2: Skills – coming soon

(Complete procedures, like "how to deploy to production". Not implemented yet, but it will come.)

Level 3: References + Conversation attachments – operational

For large content: entire conversations, architectural decisions, long documents.
Only a lightweight pointer lives in active memory.
The full content is loaded on demand only when the agent needs the detail.

The most powerful part: conversation attachments. When you explicitly tell the agent "Remember this conversation" or "Save this chat", it creates a memento and stores the dialogue and any files you indicate. You don't need to know how it's saved, just ask for it.

What it deliberately does NOT do (just as important)

It is not a RAG system → no vector search, no external API calls. Retrieval is deterministic and context‑driven.
It does not save conversations automatically → privacy first. It only saves when you ask.
It is not a document dump → philosophy: "small, high‑impact context".
It is not cloud‑based → everything lives on your machine, in ~/.memento-context/. No remote requests of any kind.

Real‑world use cases (no technical jargon)

Personal preferences (global)

"Never use any in TypeScript unless strictly necessary."
"I like functional programming patterns when reasonable."
"Always answer with code examples first, then explanation."

Project conventions (repo)

"All API endpoints must have proper error handling with concrete exception types."
"We use pytest with fixtures; not unittest."
"Database migrations are generated with Alembic."

Architectural decisions and saved conversations

Imagine you've had a long discussion about redesigning the cache system. You say: "Save this conversation, and attach the diagram I uploaded."

Days later, you simply ask: "Do you remember what we talked about regarding the cache system?" and the agent retrieves all the context (including attachments) without you having to repeat anything.

Memory that travels between agents (this is key)

The best part: you can switch agents (for example, from Claude to Cursor) and, because everything is stored locally in the same format, the new agent can also read the mementos. The memory is not tied to a single assistant. Just ask: "Do you remember my global preferences?" and it will retrieve them instantly. That easy.

How to get started

1. Visit the repository

All the up‑to‑date information, installation scripts and documentation is at:

https://github.com/FranBarInstance/memento-context

There you will find the quick method (curl for Linux/Mac, PowerShell for Windows) as well as manual installation from source.

2. Configure your MCP client

Heads up: each agent or assistant has its own quirks when it comes to configuring MCP servers. The syntax of the configuration file may vary from one to another. For example, in some cases you can install the server globally (available for any project) and also locally (only for a specific project), while in other assistants only global installation is available.

Consult your agent's documentation (Claude Desktop, Cursor, VS Code with MCP extension, etc.) to know exactly where and how to add the configuration. In most cases, editing an mcp.json or similar file with this content will suffice:

{
  "mcpServers": {
    "memento-context": {
      "command": "memento-context",
      "args": []
    }
  }
}

If your agent allows local configurations, you can put that block in the project's configuration; otherwise, you will have to put it in the agent's global configuration.

3. Use natural language, forget about the internal tools

You don't need to know that save_memento, get_memento_attachments or similar exist. That is the agent's job. You just speak normally:

"Remember that in this repository we always use FastAPI and SQLAlchemy."
"Remember that for all my repositories I prefer answers in Spanish."
"Save this conversation about the new architecture."
"Do you remember what we talked about yesterday regarding tests?"

The agent automatically detects the context (whether you are in a repository or not) and decides whether to save the memento as global or repo. You can also be explicit: "this only for this project" or "this for all projects".

Everything is on your disk, visible and editable

~/.memento-context/
├── global/
│   └── mementos.json
└── repos/
    └── my-project__hash/
        └── mementos.json

When you save a conversation with files, a folder with the attachments is created. But you don't have to worry about that: the agent manages it on its own. If you want, you can open the JSON files and see what has been saved.

When does this pattern shine?

You work on multiple long‑running projects.
You have strong personal coding preferences.
You want your agent to evolve with you over months.
You often switch between different assistants (Claude, Cursor, etc.) and don't want to repeat yourself.
You value privacy and everything staying local, with no external API calls.

Links and resources

Official repository (installation, docs, code): https://github.com/FranBarInstance/memento-context
License: MIT

What about you?

Have you already tried any memory system for your AI agent? Do you suffer from the "every conversation starts from zero" syndrome? Do you like the idea of memory travelling between agents? Tell me in the comments.

And if you try memento-context, I would love to hear about your experience!

Dynamic Bootstrap 5 Themes Without SASS, Without Hardcoded Dark/Light — and Without the Usual Headaches

Fran Bar Instance — Sun, 15 Mar 2026 12:17:27 +0000

I'll admit it: for more years than I care to count, I've been patching Bootstrap projects with Bootswatch, telling myself "someday I'll build a proper dynamic theming system."

Someday finally arrived — in 2026, when AI is supposedly doing everything. Better late than never. Here it is: bootstrap-dynamic-themes

The core problem with Bootstrap theming

Bootstrap needs to know upfront whether your theme is dark or light. That means hardcoding contrast mode directly into your templates:

<header class="bg-primary" data-bs-theme="dark">
    <a class="nav-link" href="#">Static Link</a>
</header>

data-bs-theme="dark" tells Bootstrap that bg-primary is dark and should render light text on top. Fine — until you dynamically switch to a light palette at runtime. Now that hardcoded attribute causes white text on a light background, and your UI silently breaks.

This is what makes dynamic theming genuinely hard in Bootstrap: it's not just about swapping colors, it's about contrast awareness.

How BTDT solves it

BTDT handles contrast at the CSS variable level. Each theme calculates its own contrast colors (--bs-primary-contrast, etc.), and the engine applies them automatically. Your HTML stays clean and agnostic:

<header class="bg-primary">
    <a class="nav-link" href="#">Automatic Dynamic Link</a>
</header>

Switch from a dark professional theme to a light pastel one at runtime — menus, cards, links, even SVG icons like the navbar toggler adapt automatically. No data-bs-theme juggling, no conditional logic in your templates, zero HTML changes.

More than a theming fix — a full design system

The project ships with a visual editor where you can design your theme in real time: 50+ color palettes, 50+ fonts, 50+ presets, and multiple structural styles. When you're done, you click "Copy CSS Preset" and drop the output into your project.

No SASS, no npm, no Webpack, no build steps at all — just standard CSS custom properties. It even works opened directly from the filesystem (file:///), which makes it ideal for prototyping.

Once you have a theme, integration is a single line:

<!-- Option A: Pure CSS, maximum performance -->
<link rel="stylesheet" href="btdt/themes/preset/studio.css">

<!-- Option B: One-line loader with JS API -->
<script data-preset="studio" src="btdt/js/btdt.min.js"></script>

And at runtime you get a clean JS API:

btdt.load('aurora');   // Switch preset
btdt.toggleMode();     // Toggle dark/light

BTDT vs. Bootswatch

Bootswatch is great for static themes. BTDT is for when you need more:

Fully editable — tweak every variable in real time, not just pick from a list
Dynamic runtime — switch themes or toggle dark mode without a page reload
Modular — combine the palette from one theme with the typography from another
No compilation — pure CSS, no toolchain overhead
AI-extendable — the project includes agent skills so an AI assistant can add new palettes, fonts, or presets following the established architecture

Try it

🎨 Live editor
⭐ GitHub repo — stars are very welcome :-)

Developing for AI: The New Paradigm of Application Architecture with Intelligent Agents

Fran Bar Instance — Thu, 19 Feb 2026 10:28:56 +0000

Introduction: An Experiment to Understand the Future of Development

Neutral Starter Py is an experiment conceived to explore how we should design applications in the era of AI agents. Its premise is radical: if we want AI to actively collaborate in software development and maintenance, the architecture must be designed from the ground up to be readable, modifiable, and extensible by language models.

This project, which combines Python (Flask) with the Neutral TS template engine, proposes one path: extreme modularity based on self-contained components. But beyond the technology, what is truly innovative is its stated goal: "to provide developers with AI-powered agentic capabilities." It is, above all, a testing ground for understanding where we are heading.

The Motivation: Adapting to the New Reality

We are living through a paradigm shift. AI models are no longer just tools for consultation or text generation; they are becoming agents capable of executing complex tasks within our development environment. However, most current codebases are optimized for human reading, not for autonomous AI intervention.

How can we, as developers, face this challenge?

The answer may lie in changing our role: from being mere "code scribes" to becoming architects and orchestrators of architectures. Our work will no longer be just implementing functionalities, but creating the blueprints and rules (the "skills") so that AI agents can build and evolve software within safe and coherent boundaries.

The Heart of the System: Components as "Atomic Units" for AI

The strength of this approach lies in a directory like src/component/. Each subfolder with an identifying prefix (for example, cmp_6100_rrss, an RSS reader) is a complete and isolated functionality.

What does this mean for an AI?

Self-containment: A component includes everything it needs: routes, business logic, templates, static files, configuration, and metadata. An AI can read a single component and fully understand its purpose and operation without examining the rest of the project.
Isolation: If a model receives the instruction "modify the RSS reader to include images," it can operate within the boundaries of that component with the certainty that it will not affect the login component or the database one. This drastically reduces cascading errors and the need for constant human supervision.
Replaceability: A component can be removed simply by deleting its folder, without causing application failures. This feature is crucial to allow the AI to experiment, propose alternative versions, and subject them to testing.

Practical Example: A component like cmp_7000_hellocomp serves as a template. It contains its own logic, its specific CSS/JS, and its templates. For an AI, it is a model to follow: "if you want to create a new component, copy the structure of hellocomp and adapt it."

Persistent Memory: The AI's "Skills"

One of the biggest challenges when working with AI on software projects is the loss of context between conversations. Each new interaction starts practically from scratch, leading to inconsistencies and having to repeat instructions.

The solution proposed by this paradigm is the creation of a repository of "skills" accessible to the AI, typically in a folder like .agent/skills. These are definitions of "abilities" that the AI must read to align its behavior with the project's architecture.

How do they work in practice?

When starting a new task, the AI consults these files.
It finds rules like: "To create a new component, you must:
- Name it with a prefix and an order number.
- Include a metadata file.
- Define its routes following the established pattern."
With these "workshop instructions," the AI can generate code that integrates perfectly with the rest of the application, maintaining coherence over time.

The conclusion is key: a large part of the developer's work in this new paradigm will consist of providing the project with sufficient skills. In the same way that we used to document code so that other humans could understand it, we now have to document tasks and processes so that the AI can execute them autonomously and coherently. Every recurring operation (creating a component, adding a route, modifying a template) must have its counterpart documented in the form of a "skill." These skills are the project's long-term memory and the main deliverable of the developer-architect.

Prompt Strategy: The Art of Communicating with AI

If the skills are the "manual," the prompt is the "work order." A good prompt in this context follows a structure we can call Prompt Strategy: the systematic way of asking the AI to generate new functionality.

An effective prompt contains key elements:

"Your task is to create the component [name], which must [functional description]. Use route: /my-route. To complete this task, review: - .agent/skills/manage-component/SKILL.md - .agent/skills/manage-templates/SKILL.md - src/component/[example_component] (as an example). Define routes dynamically if needed, following the pattern used by other components."

This strategy includes:

Clear Identity: Component name.
Functional Purpose: What it should do.
Entry Point: The URL.
References to Documentation: The skills the AI must consult.
A Concrete Example: A real component from which to extract patterns.
Design Principles: Style guidelines.

A good Prompt Strategy recognizes that the AI is a "collaborator" that needs context, examples, and clear rules to operate effectively within our code ecosystem.

A Qualitative Leap: Towards "Darwinian" Component Development

Component-based modularity opens fascinating possibilities. Since each component is an independent unit, nothing prevents the existence of multiple simultaneous versions for the same functionality (e.g., a comment system) generated by different AI models or in different sessions.

A developer (or even an "AI supervisor") could then:

Run performance and security tests on each version.
Evaluate code quality, readability, or resource consumption.
Select the best implementation and promote it to the definitive version.

This turns the development process into a cycle of generation, evaluation, and selection, similar to an evolutionary process. Our role would no longer be to write every line, but to design the experiment, define the selection criteria, and orchestrate the flow.

Conclusion: The New Role of the Developer as Architect-Orchestrator

If AI can write increasingly complex code, our value will no longer reside in the ability to type algorithms, but in:

Designing architectures that are inherently "AI-friendly," with clear boundaries and explicit rules.
Defining the "skills" , i.e., documenting the tasks and processes that the AI needs to know to operate coherently. This is, essentially, documenting the "how things are done" in the project.
Creating effective Prompt Strategies that guide the AI towards optimal solutions.
Orchestrating and evaluating the generated work, deciding which components deserve integration.

In this new paradigm, code is not only for humans to read, but also for machines to interpret and modify. Documentation is no longer just for other developers: it is the fuel that allows AI to operate autonomously and aligned with our objectives.

The question is no longer "how do I program this?", but "how do I organize the knowledge, architecture, and tasks so that AI can program it with me, coherently and reliably?" Answering this question will likely be the most valuable skill for developers in the coming decade.

Neutral TS: Language-Agnostic Backend Web Templates

Fran Bar Instance — Thu, 12 Feb 2026 17:25:52 +0000

I’ve been using my own PHP-based template system for years. A little over a year ago, I decided to port it to Rust and make it open source – that’s how Neutral TS was born.

Web development today is heavily frontend‑focused, with JavaScript templating everywhere. Neutral TS, on the other hand, is a backend templating system, so right off the bat that’s its first weak spot. Still, there are cases where you genuinely need a backend template engine.

With that in mind, I thought: what if the main feature was being language‑agnostic? The exact same templates could be reused in any programming language.

Another feature – “objects” – lets you create a plugin that can be embedded in any Neutral TS template and work regardless of the host language. Right now objects are experimental and must be written in Python, but that’s not a problem even if your main app is in Rust or PHP, for example.

So I can build a set of web templates and use them interchangeably from a Rust app, a Python app, a PHP app, or whatever.

Neutral TS works natively in Rust and Python. For other languages you need an IPC, and to illustrate that I like to use the MySQL (or any database) analogy.

MySQL runs a TCP server to talk to your app: you send a query, you get a result. Neutral TS can also run as a TCP server – you send the template, you get the rendered result. The language doesn’t matter, and just like with MySQL the result is always exactly the same.

This model is also more secure than the traditional one, because templates are rendered in a separate sandbox with no shared memory.

I tend to build complex things with no real utility – you guys can tell me if that’s the case :-)

Rust crate: https://crates.io/crates/neutralts
Python package: https://pypi.org/project/neutraltemplate/

To use it as an IPC you need a server and a client:

Examples: https://github.com/FranBarInstance/neutralts-docs/tree/master/examples