Skills are good, but have you tried offloading context?

The first time I heard the time offloading context was around September 2025, by a langchain talk that Lance Martin gave, it was one of those concepts that it made immediately a lot of sense.

The problem with skills

What are skills? Skills are basically long prompts that someone created and that are very good at transmitting the information to the AI to do a particular task.

It’s possible that you have had the change of creating you skills, maybe for creating components in your project, or to deploy a specific thing, or to create a changelog for your app…

But skills are long, way too long, does it need to be like that?

I see most skills like 2000+ text code lines, a bunch of information grouped together, maybe once I need the first part, maybe then I need the other, the question that comes to me constantly when working with them is … where did we left building things with a single purpose.

Going further than skills

Imagine a skill that it’s broken down into many small pieces, and for some task a small piece might fit and for another tasks another pieces is better suited. This is what I’ve been doing for the past months, building a kind of Tree of Skills or Context Tree, where just the right information is loaded in the AI for the task at hand.

This is how I do this

/modules
  /index.md // Basic descriptions and references to other files/folders in same level
  file1.md // File with info
  folder1 // Folder with other files
    index.md // Basic description of folder 1 and refernece to files and folders
    file2.md // File with info

This can grow exponentially, in some cases creating playbooks we’ve created at MAAT up until 60+ files in the same folder, and the AI is able to find the right one thanks to the reference. For the index.md files we use something similar to the llms.txt

Where we point the file name and a brief description of it, this may look like this

file1.md: This file is to do X and Y
folder: This folder contains files that can do Z

This way the AI doesn’t have to read all the file before getting to the interesting part, thus keeping the context thin.

A local MCP to context offload

At the beginning I was doing this context offloading manually, but it was tedious to always have the skill that indicated what is the llms.txt and I found it that I had to repeat it for every single project where I want it, this is what it lead me to finally create gcontext.ai, I am not so sure how to call it, context management system, framework to create context agents or a simple context offloader.

You can read more about it here: https://github.com/bleak-ai/gcontext

Would love to hear any feedback that you might have on this

reddit.com
u/bsampera — 9 days ago

How we built a minibrain to do support tasks

So in the startup where I work, a martial arts software gyms (MAAT), we handle the memberships of students to make the life easier for gym owners. For it we use a payment system and a database.

As the number of gyms has grown, we have more and more support tasks, these can be many, owners have problems with the subscriptions, they need to make some updates to the memberships, some data has to be exported...
Across the time, we've trying to figure out how can we use AI in this process, and this is where we are currently.

The evolution of solving Support Tasks

1. Manual work.

First we were doing most of things manually through the AI, updating the DB manually, same with stripe, tedious work.

2. AI Agent + claude.md.

After this we though that with Claude code we can use claude .md to show the agent how our product was being build in the backend and which relationships were important, how the data from stripe was reflected in the db...

This was actually a big improvement from the first method, as we were much faster in knowing what the errors were and solving them, sometimes still by hand though as we didn't trust the AI too do real changed in PROD.

3. AI Agent + GContext Minibrain

We saw that the AI could do the process, sometimes we had to steer it but at the end it understood and got it right, so we decided to find a way to keep the investigations that we did in every conversation.
The way of achieving this is by using a kind of "tree of llms.txt" .
A llms.txt file can help us reference what is the information available in a website, docs... But we can also use this internally to organize different information that we need in our day to day

How does it work?

We start the agent from a folder that has access to these three folders, an llms.txt and some other steering files

.
├── llms.txt        # References each of the folder in this same level
├── stripe/
├── firestore/
└── support/

What there is in each of the folders??

stripe/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # how the structure of our stripe account looks like
└── .env

firestore/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # How the schema looks like...
└── .env

support/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # Instructions on how to resolve support tasks
├── runbooks/       # Folder with many files, each one has the steps to resolve one service task, also a llms.txt inside
│   ├── llms.txt              # indexes every runbook so the agent picks the right one
│   ├── cancel-subscription.md
│   ├── export-gym-data.md
│   └── fix-membership-mismatch.md
└── logs/           # one file per day, every task the agent resolved
    ├── 2026-06-12.md
    └── 2026-06-13.md

With this structure we can actually steer the Agent much better and create new runbooks every time a new support task comes.

Do you have any similar problem in the place you're working? How do u approach it?

reddit.com
u/bsampera — 2 months ago

How we built a context tree for our agent to resolve support tasks

So in the startup where I work, a martial arts software gyms (MAAT), we handle the memberships of students to make the life easier for gym owners. For it we use a payment system and a database.

As the number of gyms has grown, we have more and more support tasks, these can be many, owners have problems with the subscriptions, they need to make some updates to the memberships, some data has to be exported...
Across the time, we've trying to figure out how can we use AI in this process, and this is where we are currently.

The evolution of solving Support Tasks

1. Manual work.

First we were doing most of things manually through the AI, updating the DB manually, same with stripe, tedious work.

2. AI Agent + claude.md.

After this we though that with Claude code we can use claude.md to show the agent how our product was being build in the backend and which relationships were important, how the data from stripe was reflected in the db...

This was actually a big improvement from the first method, as we were much faster in knowing what the errors were and solving them, sometimes still by hand though as we didn't trust the AI too do real changed in PROD.

3. AI Agent + Gcontext

We saw that the AI could do the process, sometimes we had to steer it but at the end it understood and got it right, so we decided to find a way to keep the investigations that we did in every conversation.
The way of achieving this is by using a kind of "tree of llms.txt" .
A llms.txt file can help us reference what is the information available in a website, docs... But we can also use this internally to organize different information that we need in our day to day

How does it work?

We start the agent from a folder that has access to these three folders, an llms.txt and some other steering files

.
├── llms.txt        # References each of the folder in this same level
├── stripe/
├── firestore/
└── support/

What there is in each of the folders??

stripe/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # how the structure of our stripe account looks like
└── .env

firestore/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # How the schema looks like...
└── .env

support/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # Instructions on how to resolve support tasks
├── runbooks/       # Folder with many files, each one has the steps to resolve one service task, also a llms.txt inside
│   ├── llms.txt              # indexes every runbook so the agent picks the right one
│   ├── cancel-subscription.md
│   ├── export-gym-data.md
│   └── fix-membership-mismatch.md
└── logs/           # one file per day, every task the agent resolved
    ├── 2026-06-12.md
    └── 2026-06-13.md

With this structure we can actually steer the Agent much better and create new runbooks every time a new support task comes.

Do you have any similar problem in the place you're working? How do u approach it?

u/bsampera — 2 months ago

Cansado del tópico de que los funcionarios son unos vagos

Estoy harto de escuchar que los funcionarios son unos vagos que viven del cuento.

De verdad la gente piensa que alguien se pasa años estudiando una oposición para luego no hacer nada? La mayoría de los funcionarios que conozco trabajan duro, atienden a cientos de personas, gestionan trámites complejos y hacne mucho en su dia a dia

Hay algunos que no dan cada dia el 100% ? Seguro. Igual que en cualquier empresa privada. Incluso conozco muchos casos de funcionarios que trabajan más duro por su respeto a las arcas públicas, pero no entiendo por qué unos pocos sirven para etiquetar a todo un colectivo.

La próxima vez que alguien diga que los funcionarios son vagos, que recuerde quién mantiene en funcionamiento hospitales, colegios, juzgados, servicios sociales y gran parte de la administración pública.

La crítica es legítima. El prejuicio y el desprecio gratuito, no.

reddit.com
u/bsampera — 2 months ago

How we built a context tree for our agent to resolve support tasks

So in the startup MAAT where I work, a martial arts software gyms, we handle the memberships of students to make the life easier for gym owners. For it we use a payment system and a database.

As the number of gyms has grown, we have more and more support tasks, these can be many, owners have problems with the subscriptions, they need to make some updates to the memberships, some data has to be exported...
Across the time, we've trying to figure out how can we use AI in this process, and this is where we are currently.

The evolution of solving Support Tasks

1. Manual work.

First we were doing most of things manually through the AI, updating the DB manually, same with stripe, tedious work.

2. AI Agent + claude.md.

After this we though that with Claude code we can use claude.md to show the agent how our product was being build in the backend and which relationships were important, how the data from stripe was reflected in the db...

This was actually a big improvement from the first method, as we were much faster in knowing what the errors were and solving them, sometimes still by hand though as we didn't trust the AI too do real changed in PROD.

3. AI Agent + Gcontext

We saw that the AI could do the process, sometimes we had to steer it but at the end it understood and got it right, so we decided to find a way to keep the investigations that we did in every conversation.
The way of achieving this is by using a kind of "tree of llms.txt" .
A llms.txt file can help us reference what is the information available in a website, docs... But we can also use this internally to organize different information that we need in our day to day

How does it work?

We start the agent from a folder that has access to these three folders, an llms.txt and some other steering files

.
├── llms.txt        # References each of the folder in this same level
├── stripe/
├── firestore/
└── support/

What there is in each of the folders??

stripe/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # how the structure of our stripe account looks like
└── .env

firestore/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # How the schema looks like...
└── .env

support/
├── llms.txt        # References each of the files/folder in this same level
├── info.md         # Instructions on how to resolve support tasks
├── runbooks/       # Folder with many files, each one has the steps to resolve one service task, also a llms.txt inside
│   ├── llms.txt              # indexes every runbook so the agent picks the right one
│   ├── cancel-subscription.md
│   ├── export-gym-data.md
│   └── fix-membership-mismatch.md
└── logs/           # one file per day, every task the agent resolved
    ├── 2026-06-12.md
    └── 2026-06-13.md

With this structure we can actually steer the Agent much better and create new runbooks every time a new support task comes.

Do you have any similar problem in the place you're working? How do u approach it?

u/bsampera — 2 months ago