There’s a moment every developer knows. You’re staring at a codebase you built with your own hands, something you poured months into, something that works, and you realize it’s fighting you. Not because it’s broken, but because the world around it moved somewhere your original design never anticipated.

That moment came for me with LinGoose.

A bit of history

I built LinGoose in 2023 as a Go framework for LLM-powered applications. It grew, people used it, and I was proud of it. But after a while I hit a wall I couldn’t design my way around: LinGoose was built around pipelines. A single flow, a single thread, steps executing in sequence.

In the previous article, we built a capable agent with multiple tools with real capabilities (Python, HTTP, time). It worked.

But there’s a problem with that design.

As you add more tools, the agent needs to:

• Track all tool definitions
• Reason about which tool to use
• Handle all execution contexts
• Maintain one giant conversation history

This doesn’t scale well.

In this article, we’re going to refactor it into something much more powerful:

In the previous article, we built a minimal agent:

• One tool
• In-memory conversation
• A clean reasoning loop

Now we’re going to level it up.

This version introduces two major upgrades:

1. Persistent memory across sessions
2. Multiple tools with different capabilities

We are still using go-openai as our client library, compatible with OpenAI and ollama.

But now the agent feels much closer to something you’d actually deploy.

What’s new in this version?

Compared to the previous article, this main.go adds:

Hi, I’m Simone Vellei, you might remember me from such Go-and-AI adventures as “Leveraging Go and Redis for Efficient Retrieval Augmented Generation” and “Empowering Go: unveiling the synergy of AI and Q&A pipelines”

I’m the creator of LinGoose, an open-source framework built to make developing AI-powered applications in Go clean, modular, and production-friendly. I built it because I love Go’s simplicity and performance, and I wanted the same elegance when working with large language models.

Over the winter holidays, I built Umbra — a command-line tool that takes a different approach to storing sensitive files. The core idea? Use anonymous paste services — the kind typically used for sharing code snippets or logs — as a distributed storage backend for encrypted file fragments.

The Core Idea

Services like termbin, clbin, and paste.c-net.org are designed for quickly sharing text snippets anonymously — no accounts, no tracking, just paste and get a URL. But what if you could use these ephemeral, anonymous paste bins as a storage layer for sensitive files?

One of my childhood memories is tied to my aunt’s habit of making pizza dough. It was her favorite way to relax. This might seem normal, except that she was a baker by profession. How ironic, isn’t it? The very job that could be a source of stress became her way to unwind. The funny thing is, after becoming a software developer, I found myself in the exact same situation. I love to code, but sometimes I need to do it to relax. And that’s exactly what happened when I started to develop my home server.