DEV Community: marcochavezco

The Model Doesn't Remember. You Do

marcochavezco — Thu, 18 Jun 2026 17:02:38 +0000

Introduction

Before I dug into how an LLM works, I assumed each chat stored its memory or context in its own. The moment I realized it was just an array with all the messages appended gave me a sense of control. I wish I had known this sooner. This is invisible in a chat session; Claude and OpenAI pull a lot of threads to pull up a context accurate response. To know about those threads first, I needed to work with an LLM API with raw fetch, no SDK, and understand the request/response cycle.

Digging in

We want to build strong fundamentals, so not using the Anthropic SDK frees us from abstractions we may not notice. The SDK provides idiomatic interfaces, type safety, and built-in support for streaming, retries, and error handling. Without the SDK, nothing is abstracted away. Every decision is visible, which is exactly the point.

Normally, with the SDK to call the API, you'd need to add a script like this one:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const message = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 1000,
  messages: [
    {
      role: "user",
      content: "What should I search for to find the latest developments in renewable energy?"
    }
  ]
});
console.log(message.content);

And for a raw fetch, you'd need to manage the headers and body yourself:

const URL = `https://api.anthropic.com/v1/messages`;

const res = await fetch(URL, {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-api-key': `${process.env.ANTHROPIC_API_KEY}`,
    'anthropic-version': '2023-06-01',
  },
  body: JSON.stringify({
    model: 'claude-sonnet-4-5',
    max_tokens: 1024,
    messages: [
      {
        role: 'user',
        content: 'Hello Claude',
      },
    ],
  }),
});

const data = await res.json();

console.log(data.content[0].text);

Surprisingly, there is little documentation if you want to take this path; it's obvious why, but still inquiring. And well, this is just for the basic request and response dynamic. You send a query, get a response from the LLM, and that's it. The Messages API is stateless, so you need to always send back the full conversation history every time you send a request. We'd want to achieve multiple conversational turns.

The memory realization

Let's stop for a moment to think about this "history" we need to manage. This is where you learn the most important concept in LLM development. The model has no memory. You are responsible for keeping the history and sending it back every time. Our model is only aware of what we are sending to it. Everything else is forgotten.

Going through the loop development, I found out our "memory" is just an array with our previous messages, along with the latest query. Yes, that's how an LLM manages its context. This did hit me hard because I thought a model was managing this on its own, and being able to control this array to this fine-grained level was a nice surprise. Our "memory" after a second query would look like the snippet below.

messages: [
    { role: "user", content: "Hello, Claude" },
    { role: "assistant", content: "Hello! How can I help you today?" },
    { role: "user", content: "Can you describe LLMs to me?" }
  ]

What if we want a real back-and-forth conversation with the model? First, we need these requirements: read user input from the terminal, append the new message with the previous one to pass it to the model, print the response, go back to step 1, and, as a nice touch, an exit option.

If you want to check the full implementation of a basic loop chat, check this script at the raw-claude-chat where this stage is added.

This simple array is the seed for many context strategies like sliding window, RAG, and semantic search that will be necessary later for a really functional chat that "remembers".

What's next

When interacting with a chat, one thing we may want to do is not just to message it, but to tell it to do something. This leads to tool use, being able to execute what the model is actually instructed to run, run one task after another, and choose correctly which tool to run when it needs to. We have built a tool from the server perspective, gitstoria. Now we are going to complement this knowledge by understanding the counterpart, the client side.

MCP Isn't Magic, It's Just a Really Good Door

marcochavezco — Sun, 14 Jun 2026 00:19:19 +0000

Introduction

I was sold on using AI pipelines the moment I found n8n. It was impressive the potential it has. I didn't want to only be a user, I wanted to know how it works. As many developers I use AI for everyday assistance but that's just the tip of the iceberg. I wanted a deep dive into AI application development. The first thing I felt I needed to know was the Model Context Protocol (MCP), "Why it is useful and how it works?".

The big deal with MCP

As the official documentation states, MCP is an open-source standard for connecting AI applications to external systems. Let's think of MCP as the USB-C for AI applications. This protocol provides a standardized way to connect AI applications to external systems.

One example of this applied is a simple Claude or ChatGPT chat with access to an internal enterprise database and tools around the business model empowering the user; agents taking decisions on your behalf; direct connection with many of your services like Figma, PostHog, GitHub, and the list keeps growing.

First Steps

I got started with an MCP server, because I already had a good MCP Client working, Claude. When working in the server side you have three main concepts or capabilities: Resources, Tools, and Prompts. I began with Tools which are basically functions your LLM can use.

Another big thing to have in mind is that an MCP Server can be STDIO-based or HTTP-based. Each has different purposes. STDIO is meant for local single user and performant tools. While HTTP ones are for web applications and distributed systems, think of them as an API. Once I understood STDIO vs HTTP, it all clicked. I understood why some tools are CLI-based and others are full services.

I expected a bigger wall to start with MCPs, a high ceremony along with heavy AI Engineering concepts. While writing a simple get_current_time tool, what I encountered wasn't a complex protocol, instead a well-defined contract to build upon. Below we can see the implementation of the tool which is basically the registerTool block which is the only thing we need to care about. The rest is boilerplate.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import z from 'zod';

const server = new McpServer({
  name: 'my-mcp-server',
  version: '1.0.0',
});

server.registerTool(
  'get_current_time',
  {
    description: 'Get current time',
  },
  () => {
    return {
      content: [
        {
           type: 'text',
           text: `Current time is: ${new Date().toLocaleString()}`,
        },
      ],
    };
  },
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error('My MCP running on stdio');
}

main().catch((error) => {
  console.error('Fatal error in main():', error);
  process.exit(1);
});

Once integrated with my client, in this case Claude Desktop, the tool is available for us by asking Claude to "Get the current time" in a prompt to use it.

Keep pushing on MCPs

MCP is the door that gives an LLM the power to use your system. It can be as simple as a tool to get the current time and as complex to manipulate a whole web application through a chat. One of my favorite examples is the PostHog MCP that enables you to build insight graphs by telling the LLM what you would like to see.

As proof of understanding, I wanted to build a complex MCP server. I ended up with a tool named gitstoria. This tool helps you attach reasoning and process notes to your git commits via any MCP-compatible LLM client. Every time you commit, gitstoria queues the commit for review; your LLM reads the diff, writes a structured session log, and stores it locally alongside your repo history.

How it works:

You make a commit, a post-commit hook fires and records the commit hash in a local SQLite DB
You ask Claude to log what you worked on
Claude calls the gitstoria MCP tools, reads the diff, and writes a session log back to the DB

You can take a look at the full code and download the package if curious:

GitHub Full Code: https://github.com/marcochavezco/gitstoria
Package download: npm i gitstoria

The roadmap is forking

I see two paths to follow up, workflow automation tools/ecosystem and AI engineering. Each route is worth exploring; on one hand tools like n8n can help you to take processes, reduce friction, and end up with real efficiency gains; and on the other hand, taking a deep dive into how an LLM works and what is under the hood. I wanted to know how tools like n8n worked, so I chose to go deeper.