Cognitive Offload: An Engineering Manifesto About LLMs, People, Company Reorganisation, and Linguistics

Documenting my experience with Obsidian + OpenCode through a knowledge management lens.

Executive Summary — 5 lines

Society's attention is collapsing while knowledge production accelerates. Organisations burn cognitive hours on toil — meetings, context switching, knowledge retention. LLMs are not chatbots or oracles; they are linguistic processors, and linguistics is the science that partly explains them. When the language gap between teams starts to dissolve, value shifts from knowledge scattered across people, meetings, and handovers, toward systems that centralise context between business, people, and code — making the team less dependent on intermediaries for decision-making. This manifesto proposes Knowledge-Based Systems (KBS) with LLMs as the organisational layer that closes the gap. Not prophecy — trajectory.

Greetings

Greetings. Today I want to talk about something that has been resonating in my mind for a few months now — since around mid-2025, I think. Funny how chaos brings good ideas, right? hahaha. There's still more good fruit to come, but I've now reached a point worth sharing with you.

If the subject gets dense, grab a coffee or tea. What I want to propose in this article is a different perspective on LLMs — grounded in social, neurological, computational, and engineering context, with one foot in architectural visualisation.

If you think LLMs will solve all your problems — no, they won't. But rest assured, this perspective might help you see possibilities for applying them in your life, company, career, etc.

Hypothesis

My view is that LLMs should never be seen merely as text or code generators, but as linguistic processors capable of reducing cognitive load, organising dispersed knowledge, and transforming context into analysis, decision, and action.

In that sense, I wager that between the end of this year and across 2027–2028, we'll see a surge in focus on solutions that solve language-based problems within teams across various sectors. Today, a lot of knowledge remains decentralised: spread across people, meetings, documents, messages, and informal memory. My hypothesis is that value will migrate toward systems that centralise this context and let the team access, understand, and act with less friction.

Less knowledge trapped in management handovers — more shared context between business, people, and code.

My three pillars for this article are the Red, Green, and Yellow dots.

Problematique

Let me frame the problem I'm beginning to solve now — I'm certain it's a very common situation these days.

In this information society, where every minute we're bombarded with new demands, new comparisons, new "novelties" — data coming from here, there, everywhere.

If you already struggle to stay organised, things get worse... because rest assured: at some point you will forget something, and over time, you'll grow tired. I say this because it's happened to me. It's like a high-pressure tap over a slow drain: water keeps flowing, the drain can't keep up, and the water starts to overflow. Amnesia sets in...

Original image showing a tap with higher pressure than a drain — a parallel between data and human cognitive absorption.

P.S: I admit this is the worst drawing in the manifesto — the next ones are 10/10.

I understand that forgetting is normal. The problem is when it starts getting in your way frequently — like almost everything in life.

I've tried various solutions between 2019 and 2026: Obsidian, Notion, Trilium Notes, Joplin, Zettlr (Zettelkasten), Affine, Super Productivity, AppFlowy, Microsoft Loop, OneNote, Trello, Jira, Pomodoro, Excalidraw, Notepad. Even so, I always ended up unable to reach a decent result that actually helped me. With Obsidian itself, my graph was quite scattered — few connections and relationships, subjects looser than what I was learning. That bothered me immensely, because it feels like you're just stockpiling text, not producing knowledge and "linking your neurons."

But using these tools still served some purpose, even when I couldn't maintain a decent "flow" of the things I want/need to do.

Fortunately, almost nothing critical happened because I forgot something, or because I had losses in daily life. Not that it hasn't happened — it has. And when it did, it was a truly horrible feeling that we all want to avoid.

But when it does happen, the right thing is to understand, mitigate, and recalibrate — because life goes on, right? People make mistakes, perfection doesn't exist, and the wheel keeps turning. I'm grateful to those who were with me in those situations; it generates tacit learning and is important for aligning the path.

Just to give an example of how my Obsidian is still here. It's messy in parts — I'll still connect everything so nothing remains unrelated. You can always pull something. Even reaching into studies a bit, they say you only truly learn something when you can explain it using other analogies. Some people I've met in life could relate very distinct concepts really well — that's important because it makes learning easier for others. And moving to companies, I understand they generally like that because it makes business survival easier when staff turnover happens.

Original image showing how the writer's Obsidian knowledge graph looks, highlighting the lack of connections between concepts.

PILLAR 1 — Emphasis on ADHD and Behavioural Changes, Specifically Focus

Given the context, I now want to delve into the social/psychological context, especially regarding ADHD and behavioural changes.

But before anything else, let me be very direct: "Diagnosis is a clinical matter, not an internet opinion." I won't put my hand in the fire. If I say something wrong, feel free to tell me and I'll correct it. I don't want to contribute to fake news, especially about serious matters like health. My idea here is to attempt a social analysis based on neurological hypotheses.

I've included this point to provide more personal context — I've dealt with ADHD since childhood. Context overload, loss of focus, and difficulty sustaining focus on activities without wanting to open more threads have always been present.

Fortunately, I had the opportunity to receive treatment since childhood, and nowadays I handle it more naturally. In many situations, the impact is minimal or manageable. Even so, mitigating external factors is important for achieving a better quality of life and ensuring confidence with the people in your life. Anyway, I don't like using a diagnosis as an identity; I believe what makes a person is their actions, not their difficulties.

But I don't want to turn this article into a clinical discussion. ADHD, ASD, anxiety, depression, and other diagnoses are serious matters and should be handled by qualified professionals — not by influencer opinion or social media trivialisation.

Although the topic has become much more accessible and much of the stigma has been broken, it's become highly politicised, and that concerns me. Despite that, I won't go deep into the subject — not least because ADHD isn't just about lack of attention. Again: "Diagnosis is a clinical matter, not an internet opinion," and that's not the focus of my text; I just want to introduce some personal context.

Increased Visibility of ADHD, ASD, Anxiety, and Depression Cases with Late Diagnosis

In recent years, topics like ADHD, ASD, anxiety, depression, and late diagnosis have gained much more public visibility.

There have been consistent increases in ASD cases, a relevant 25% increase in anxiety and depression cases globally in the first year of the COVID-19 pandemic, and recent CDC data also indicates an increase in ADHD diagnoses in children in the US compared to 2016, in addition to an increase in late diagnoses in adults.

The data doesn't point to a single scenario, and I agree with that. I don't believe this situation can be explained by one reason like "oh, it was the pandemic" or "oh, it was the expanded classification scope and the lack of a biological indicator." Just like the global decline in birth rates, I understand there are multiple factors. But there is one point that impacts quite a bit too; I'll simplify a bit more, but you'll get where I'm going.

Health professionals, especially serious neuroscientists, please correct me. But simplifying a lot, here's the gist... what we consider an "attention deviation" in ADHD would theoretically be a line indicating the attention deviation that people with ADD/ADHD have compared to people without the diagnosis.

One hypothesis about the increase in diagnoses is that this deviation might be "disappearing" because the baseline of attention in the non-diagnosed population of society could be declining.

But notice that today, with the excess of information we receive, it seems to me that the attention of the non-diagnosed population is increasingly trending toward the same "attention" capacity as those with ADHD (disregarding hyperfocus, of course). So... which factors might have influenced this? I believe no one can say for sure yet, but there are clearly some assumptions.

Nothing that has been deeply postulated with consensus.

And honestly, I understand it's more than one factor and it's much more complex than it seems. Despite that, it appears to be a globally happening movement. It's complicated — which is why I don't want to go deep into the diagnosis increase question, but rather into the hypothesis of sustained focus decline due to various external factors.

This hypothesis says that the focus of non-diagnosed people in society has declined — we're having more difficulty sustaining deep, prolonged focus on things — and knowledge/information is only accelerating. We're producing more and more data.

The idea of the chart isn't to compare diagnoses, but to illustrate a hypothesis: perhaps part of the non-diagnosed population is suffering from sustained attention loss due to environmental and informational factors.

From what I understand, there's already some research on "attention traits worsened by the environment" due to various factors by which current society hinders the development of attention and focus. Not that it's equal to ADHD levels — I compared them here to simplify. But just like ADHD and ASD, the deprivation or overload of external factors can simulate behaviours similar to the spectrum and increase diagnostic difficulty.

But understand: this doesn't mean the difficulty or suffering of this group doesn't exist. It does — it's real and needs attention. But that doesn't mean we can't say there's a new group or outlier. This could happen due to various factors that neuroscience people and related fields will need to investigate more carefully to understand the phenomenon. I don't know if we need to readjust the baseline or start some action plan to regain focus like before. That's not for me — that's at another counter; I'm just saying this problem seems to exist too.

With that, understand: to remain productive and keep delivering at the same speed or faster, while maintaining high maturity and quality, we'll probably start adopting more and more AI to manage our knowledge — or to limit it, depending on your perspective.

To me, AI will boost productivity; however, it could degrade several vital areas for human beings, such as communication and interpersonal relationships — which some say are already in decline.

It could also result in a disqualification below what the market and society demand for us to keep evolving and the wheel to keep turning — if we really are evolving, of course...

Understand: delivering faster might be better for your wallet, but not necessarily for your mental health, your quality of life, and the quality of what you deliver.

Well, decline in focus and attention seems to already be happening. Some even say our language has become poorer and more direct; I wouldn't rule out that possibility, of this starting to happen with our knowledge, you know? It's related regardless.

And that's why I continue to believe that, regardless of your field — inside or outside IT — the foundations of knowledge in your area haven't changed and won't change. That's what will set you apart as a professional in the future — not just knowing how to use LLMs. Depending on your field, you'll probably need to, but that's for productivity, not technical qualification. They're different things. Maturity and confidence (the so-called "ownership") will become increasingly valuable because they mean you're responsible for your actions... or maybe we as a society have never really taken risks.

In that sense, here's the phrase @Akita has used in his videos: "Learn to learn." That's what our education system should focus on — not making us memorise things. We need to learn the concept, learn how it works... well, that's my opinion anyway.

Alright, I hope I've explained the point. I don't want controversy — I want rational debate, please (see note A at the end). I just want to reach the point that our attention as a society seems to have declined; however, it's hard to say for sure.

But that's the impression I have. Now, why? We still need to figure that out rather than wanting to implement public policies without evidence. We need to treat the root of these problems, which is multifaceted — I understand that. We must treat the problem, not the symptom.

In summary: our cognitive load is reaching its limit, our attention and focus are declining, and the solution will be to offload — to outsource this process to a computer, just as we did with calculations a while back.

PILLAR 2 — AI, AI, AI, AI, AI, AI, OK I Get It

Right — having set out the social/psychological context of what I want to discuss, let me now provide some computational grounding for the model.

The year is 2026; we've reached the current moment. To give you a definition: since GPT, especially in 2025, whenever I thought about LLMs I didn't think about code. To me, LLMs primarily evoke linguistics — after all, they're called "Large Language Models"; emphasis on "Language" here.

It's About Linguistics, Not Just Filler

Let me include an image that makes sense. I know linguistics goes far, far beyond this, but intersecting it with computing serves as an example. I'm no master of linguistics or anything like that — I just have an interest in the subject.

The idea of the map is to show how the Systemic-Functional Linguistics view relates to LLMs; the context involves the planes of expression and content.

Looking at this now, tell me if this isn't very similar to what we talk about with LLMs, context management, tokens, etc. — oversimplifying wildly, of course, because I'm not a master of Deep Learning.

Seriously, I'm not a specialist, but I see that we should stop thinking about AI applicability in terms of "cold" data and start looking at it through a linguistics lens. I understand there's much more real application than just data. Data automation has been done in computing for a long time; linguistics outside of NLP — not so much, as I understand it. It's very new — LLMs enable many more scenarios.

Literature and Linguistics people, please correct me, but in our intersection with computing, I understand "language" as linguistic processes: dealing with language itself — phonetics, semantics, syntax, words, various hierarchies and relationships. And when I think about that, I envision more of a three-dimensional view of these things. It makes it easier for me to understand, and I genuinely think the greatest capability LLMs have achieved so far is working with language and text. Not for nothing — they're text generators based on mathematics.

The original image above shows how the semantic values of language can be represented mathematically within a three-dimensional plane.

In that sense, I think LLMs will add a lot of value — not necessarily only in code, although they add enormous value there too, and that deserves a parenthesis (see note B at the end).

Alright, but in summary: I think we need to stop thinking of LLMs merely as "agents" or "text processors" and start seeing them as "linguistic processors" — something that uses properties of linguistics to solve problems and generate text. Today, with tool calling and MCP, I'd extend that to "taking actions."

PS: I've recently been taking AI and Machine Learning classes — despite missing some to focus on my final project — and I'm really enjoying them. Thinking about it, this gets close to a neural network representation. Consider that the resulting function of the network's computation is knowledge; in this case, I'm trying to draw a parallel here. Of course, in real life it's much more complex and mathematical, but — very briefly — you can think of it this way, OK?

Let me add a drawing because I enjoy visual knowledge — I find it easier to understand, especially processes — tip given.

The original image demonstrates how concepts from linguistics — such as words and knowledge — relate mathematically in the production of knowledge/vectors.

Just to be clear, based on the Machine Learning classes I've had: a neural network is basically this, but with multiple nodes performing this calculation, many layers, and a whole lot of mathematics behind the computations.

Just think that the points that are "words" can be anything I can represent in a computer's memory. If you need a reminder, remember that memory is zeros and ones; therefore, I can do whatever I want with that. It doesn't matter — if it follows a pattern and fits in RAM, it can be represented.

And in the drawing example, it's in 3D, but in real life it's not just a 2D, 3D, or 4D graph — it's n-dimensional. But the objective is always the same: find a "resultant vector." I always thought that was cool when we talked about matrices back in school hahaha. It was about cryptography and AES, but still fascinating.

If You're Stuck, Try Another Perspective

Right — context established. So, returning to the pain I explained: problems organising information/knowledge for life and project management.

This is annoying, important, but tedious depending on how much load you receive daily. That's why I genuinely think, if this catches on, we'll start doing massive data offloading.

Understand data as anything representable in vectors: text, photos — because then it becomes multimodal: vision, audio, text, etc.

If you still see LLMs and Deep Learning merely as input and output of data, I propose a view with more added value — not something too simplistic, though simplicity is important.

Stop seeing it like this

The original image above shows a simplistic view of what an LLM does.

Start seeing it like this

The original image above better demonstrates the capabilities of what a multimodal LLM model can do.

Bureaucracy Is Good for Quality, Criticality, and Software Configuration — Not for Simple Tasks

Markdown has won; tools should reduce friction, not increase it.

OK — with that in mind, I recently decided to return to Obsidian, which I'd already used around 2022–2025. I ended up taking a break in mid-2026 to try Trilium Notes, primarily because I can run a server for it on my homelab to sync notes. You can do that with Obsidian too, but I thought it'd be interesting to test Trilium.

However, I found it too complex. WYSIWYG editors don't appeal to me; for me it's the same as using Word. It's tedious — you have to select text, change sizes, adjust formatting. It might be intuitive for the vast majority, but it genuinely doesn't appeal to me.

Markdown in Obsidian is simply simpler: I type a text like '# Title' and done — I have an H1 heading. I type '#tag' and create a tag to filter with.

I'd say the same about OneNote too. I think it's too much work to record a piece of text — too much bureaucracy. And bureaucracy, despite improving processes — whether in factories (software, shoes, metallurgy, etc.) or in our dear SDLC by providing ownership and decision/validation gateways — in practical activities like writing specification documents or similar, it only helps someone who's already disengaged to procrastinate.

Stop Thinking of LLM as Your Personal Assistant — Think of Context Engineering and Harness

Back to my case... while I was reconfiguring Obsidian, pulling my backup of everything I'd ever written, I discovered a really cool extension created by @YishenTu, called Claudian. Very cool. Basically, you can "plug" a Harness like Claude Code, Codex, OpenCode, or PI into Obsidian.

In practice, it shows their output and runs the background processes within your vault path.

Even so, that alone is already very cool: running a "Linguistic Harness" inside a vault. If you want to visualise it better — knowledge is linguistics too. If you draw a parallel with AI and Machine Learning, think of your Obsidian as a Knowledge-Based System, but one that, until now, only you yourself have been recording. You define your business rules, knowledge, structural rule representation, relationships. Brilliant.

The original image represents a KBS — Knowledge-Based System. The image also illustrates, in a playful way, the generation of knowledge using Machine Learning algorithms that grow trees.

Think of it this way: just as LLMs serve as "linguistic processors," they also serve to process "knowledge" — which would be nothing more than a set of organised linguistic representations that, in a certain arrangement, represent something: a piece of knowledge. If you want a more technical parallel, think it's similar to a vector database: the word "King" points to a point — a "vector." If you combine several of these points and calculate the resultant vector, it still goes somewhere. That's your "knowledge."

Again, the image I showed earlier to reinforce my point.

Again, computer scientists, please correct me — but to me, this analogy makes a lot of sense for simplifying that LLMs are, at their root, linguistic processors. In the current hype of Claude Code, Codex, etc., this extends to the ability to work with code, which is nothing more than linguistics applied to computers and logic — with mathematical foundations, of course, in this case.

Interlude — Thank You, @Brennon!

Taking advantage of the mathematical foundation while drawing a parallel — on Friday (20-06-2026) I chatted with @Brennon about this manifesto, and he reminded me of something very, very cool that I thought impossible not to share.

So, if you're a computer scientist, you've probably had Compilers class, right? I'm not sure if you remember, but programming languages are also languages. Basically, "every language can be converted into a Syntax Tree or Syntactic Tree," and I imagine (literally because I didn't have classes on this — I studied the concepts independently during my second/first year of university) that you learned that some language expressions are subjective. The same sentence can point to two opposite or dissimilar things — correct?

So, just as compilers have this "subjectivity," LLMs are also subject to these properties, because anything that deals with linguistics is not perfect and will, at some point, generate ambiguity (even mathematics, with all its formal rigour, reaches scenarios where you need to handle undefined or unrepresentable "mathematical sins"). The difference between a compiler and an LLM in language processing is that the C compiler either doesn't understand and spits out a confusing error, or takes the first path; the LLM, on the other hand, is subject to social engineering and might accept either case. And then we're back to fundamentals: you only get good results if you've learned this.

Well, I heard that a recent study from NIST mathematically sustains that it's "impossible to put guardrails on an LLM that prevent it from leaking data it shouldn't output." Thinking about it now, I think I've arrived at the same parallel, but without the same formality and mathematical rigour — starting from the linguistic formality of compilers and the geometry of neural networks — far from it.

I remembered this because of a video by @Laurie Wired about "programming languages don't understand subjectivity." I'll also leave the link at the end of the article. I recommend her for lower-level content — really good stuff. Her thesis about what would happen if CPUs stopped being manufactured is also pretty interesting.

This image Laurie used as an example is called "Dangling else." Look it up later — I'll revise it too. But basically, if someone asks you why context matters in any situation where you're using linguistics, this is why.

NOTE FOR THE CURIOUS: Also, check out AST (Abstract Syntax Tree). I've never needed to work with one because of my field, but know that sometimes people discuss which language is faster because of this too. It's not everything, but it's part of the pipeline (GCC and LLVM have different optimisations). It's really cool and, like graphs and vectors, I understand it might start growing in use cases in my view. Again: fundamentals. Compilers use ASTs to optimise your code and make it better.

An image from the internet demonstrating the Dangling Else problem using syntax trees.

An example of this in natural language — in the case of Brazilian Portuguese — would be:

Ambiguous sentence:

"If you find Alessandra, if she's busy leave a message; otherwise, call me."

At first glance, it seems like a simple sentence, but it has a problem similar to the famous Dangling Else in compilers. GCC might reject this behaviour, or in most cases, accept only the first AST. The LLM — and perhaps a human — accepts it without question. The phrase "otherwise" can connect to two different points in the sentence.

In the first interpretation, "otherwise" is linked to the condition "if she's busy":

Meaning:

If you find Alessandra and she is not busy, call me.

In the second interpretation, "otherwise" is linked to the condition "if you find Alessandra":

Meaning:

If you don't find Alessandra, call me.

Notice the problem?

The original image demonstrates how the Dangling Else and ambiguity problem can be represented using simple trees.

Sometimes, on autopilot, we don't even notice — but it might happen that someone interprets your vector points (words) differently and arrives at different knowledge. Isn't that interesting? That's why I love IT: we relate to so many sectors of society and sometimes don't even realise it, because we're focused on delivering CRUD or discussing Design Patterns (I say this because I myself have spent a lot of time reflecting on Design Patterns in the past).

Just to draw the parallel in vector dimensions, because it's interesting and maybe someone will understand better (yes, I disregarded the weights and bias):

The original image demonstrates how the same linguistics problem can be represented in three-dimensional space, indicating this is part of the social engineering problem.

Well, if linguistic ambiguity can break an AST or make an LLM follow the wrong path, imagine what happens in an organisation where knowledge passes through 5 people before becoming action. And worse: all of them focused on reducing friction and not taking the blame when it fails because everyone is afraid. That's what I want to focus on now.

PILLAR 3 — What Does This Solve in Practice? Excel Already Handles It.

Given the computational context of this manifesto, let me move to the pillar of the question everyone asks, whether at school or at work: "What does this solve in my life?"

Let me start by saying: Excel does solve things. A good portion of what we call "systems" start and end as a well-made spreadsheet — CRUD, inventory control, task tracking. And there's nothing wrong with that.

We have to use the right tool for the right problem.

The question is another one: what happens when the problem grows?

Complex processes, auditing, decision traceability, knowledge that needs to be passed on without depending on human memory or a hidden spreadsheet in someone's drive — Excel starts hitting its limits. Not because it's bad software, but because the problem has stopped being CRUD and tabular data control and has become knowledge and context management over time.

That's where I want to place emphasis.

But before that, let me admit something.

I haven't been leading or managing teams for 15 years, but — if you'll allow me — I'm analysing patterns and connecting dots with the baggage that life and university have given me so far.

I believe seniority in software, more than time served or job title, is about maturity — and I think I have enough maturity to argue with valid foundations and market observations.

Now, on the subject itself, I want to talk about how using this extension and a few others has helped me, and also give an idea of the knowledge architecture I'm working on. I think this might help someone who was or is going through the same problem as me. Although, honestly, anyone who wants to get started, or deals with a lot of knowledge or data, will benefit from this. And, opening an appendix for IT, I think professions like:

• Product Owner
• Scrum Master
• Tech Lead
• UX Designer
• Software Engineer
• Computer Scientist
• Quality Analyst
• Systems Analyst
• Squad/Tribe/Cell Lead
• CEO, CTO (C-Level)

will be the most benefited at an organisational level.

Today, a lot of knowledge is decentralised: spread across people, meetings, documents, messages, and informal memory.

In many places, this knowledge ends up passing through management or coordination roles just to circulate.

And many times it circulates only within the "management" layer, while the operational team has no idea what was decided. The team just executes — afraid of the friction of questioning decisions — and the wheel keeps turning, perpetuating the same problem.

And then, when a failure happens, nobody wants to take the blame. And of course none of the decisions were documented — they were all informal conversations with 0% traceability. Of course everyone wants to avoid accepting the failure at times like these, right? haha. Then we push it to the collective — preferably operational, since they're the ones who "did it" and didn't question beforehand. No one admits process failures and risks, and we move on. That's exactly where the famous Kaizen should come in to solve these problems.

After @Fábio Akita's text about changes in the software development process, I've been reflecting on how many processes are like this: diluted risk, nobody takes ownership, when something goes wrong they always outsource blame, passive-aggressive discourse by default because it's standard politics — in other words, simulated compliance. Everyone agrees, pretending that intention without action changes something, and the wheel turns. You can't measure CMMI maturity level with simulated compliance — it's like test coverage: if someone tells you everything is 100% covered, question it — no software has 100% coverage without having an Ignore in the codebase.

Can you see the problem we have in most software development processes? We demand ownership in delivery but not in responsibility. Nobody really has the famous "Skin in the Game," and the failure takes time (weeks, months) to show up. By then there's been enough time to forget the decision, and since 0% was documented, it all turns into guesswork. The solution is to outsource the loss.

And, following the process rigour that Google's SREs would advocate, this is not about a witch hunt, nor about assuming fault and declaring yourself guilty. The focus is to find out what happened, document it, make it traceable, define process — not to use someone as a scapegoat. But to improve a culture, you can't improve something without finding where it's wrong. Postmortem is for that: documenting something that went wrong and improving the process.

Now think... if linguistic systems start centralising this context and accelerating the planning and management process — just as they're doing with development — freeing up data for the team to access (with Information Security policies, of course — nobody wants an ISO 27001 fine), to understand and act with less friction, then work based solely on information handover loses its power.

Value migrates to those who can connect business, people, and code within the system.

With the centralisation of knowledge and the removal of linguistic friction, everyone has more skin in the game. It doesn't matter who made the decision — the context becomes traceable and consequences appear quickly.

This solves the existing gap that, as Google's SREs would say, is genuine "Managerial TOIL." Of course — if the culture is good, we'll follow the correct process and not engage in a witch hunt. Otherwise, it'll go wrong, questioning will become a war crime, and the process will turn into "forensic investigation" instead of the KAIZEN I like: finding out where it went wrong, documenting what went wrong, and seeking continuous process improvement.

Now I want to show the impact of this with a Venn Diagram, overlapping three large common areas in a development cycle (SDLC): business, people, and code.

What separates these areas isn't just the organisational chart. It's language.

Much of the friction comes from different languages. Things are viewed one way by one part, another way by another, not 100% clear — there's noise, context loss in information exchange. A significant part of the organisational problem is linguistic. There's a political and emotional part too, but a good part is linguistic. Everyone has to work together toward the same final goal, but with the language gap.

The original Venn Diagram demonstrates how the language gap between common areas in Information Technology can be optimised using linguistic processors (LLMs).

With LLMs dissolving the old coding bottleneck, the real bottleneck that always existed is now exposed: linguistic friction between teams.

The idea here is direct: this type of system attacks exactly the "shared contexts" — where one area needs another's language to make a decision.

Historically, the market has created layer upon layer of management to translate what the business wants, what the code can deliver, and how people sustain this process.

And with that comes the question: when a system can centralise context and reduce this language gap, the need for roles acting purely as "translators" or "information routers" plummets, and our standard SDLC structure begins — or can begin — to flatten.

And, for safety, I need to be clear: this is not an attack on roles like Product Owner, Scrum Master, or Tech Lead; it's a critique of a negative form these roles can take within the current SDLC process structure.

When a role exists merely to route information, schedule meetings, pass on context, and translate decisions that were never properly documented, it becomes a human cache of organisational knowledge. And a human cache is expensive, fragile — because at any moment the person can go elsewhere — and it doesn't scale: it's distributed and centralised and only handles one thread at a time.

The value of these roles does not disappear with linguistic processors — in fact, the opposite happens: it increases significantly.

But it increases for those who genuinely know how to make decisions, explain clearly and reduce noise, prioritise, protect flow, know how to deal with people (including knowing when to schedule necessary meetings), sustain trade-offs, and improve the work system based on the people who generate value.

What loses strength is the role reduced to an information intermediary who can't sustain the decision — only pass it on or execute. If it's just to relay, we can create a knowledge base the team will actually use, throw it in there, put an LLM to simplify and communicate it appropriately for each person — and done.

If Knowledge-Based Systems start centralising context, the corporate question stops being "who knows about this?" and becomes "where is this recorded, what decision does it support, and who takes the next step?" — much better than hunting for the "owner of the truth," who, when they go on holiday, leaves the project on fire because nobody knows anything, so nobody has the ability to assume risk and take action on their own.

In this scenario, product-oriented roles (like PO, Tech Lead, UX) stop being relay channels and start acting strongly as curators of context, strategy, and product. People-oriented roles (like Agile Coaches and Scrum Masters) stop being merely organisers of ceremonies that everyone complains about and start protecting the team's real flow, removing impediments and eliminating bureaucratic friction — as it always should have been.

Agile has suffered some distortions and become stereotyped — the so-called "Agile Theatre" that everyone claims is using Scrum or Scrumban just because they have a board and rituals, even when it's Extreme Go Horse with meetings, and the game goes on — because obviously just using Scrum makes you Agile.

Mature processes are not limited to a single framework. Mature teams mix Scrum with XP, adjust according to the iron triangle of project management, and understand that true agile is about delivering value with quality and confidence — not about ritual.

In this sense, LLMs do not eliminate good professionals.

They expose poorly defined roles. Roles that depend on contextual opacity to exist will lose strength.

Roles that increase clarity, decision-making, and flow will gain value.

With this, I want to enter the most controversial point of the text. I don't want to be alarmist and I don't think this will catch on so easily — not least because I don't believe good professionals are replaceable by machines. As I said before, "linguistics" is one of the problems we have in organisations, but not the only one. There's a whole political and emotional dimension, and above all, one thing that makes you stay where you are: trust. In the middle of all this — whether to break through ego defences or political barriers like "oh, I can't escalate the problem directly to the client because I'd be cutting off someone else's responsibility; if I do that, they'll feel undermined and escalate to our side, or I'll break the process." Seriously, you don't need to go far. There's also Information Security concerns, but sometimes it's just process that can't be broken out of respect between parties.

So, in this case, I'll say this seems like a near-term trend, but it doesn't mean it will happen, or that you'll be replaced, or anything like that. It might mean you'll have more fronts, or your company will have more projects because it can distribute more people. Since the requirement for teams has shrunk, I can achieve the same productivity that I needed in a team with 5 DEVs, 3 QAs, 1 PO, 1 SM, and 1 TL — now with 2 Devs, 1 QA, 1 PO, and a Tech Lead dropping in occasionally to ensure standardisation, structure, and minimal coupling.

One point to make: this structure might be better for productivity, but it could remove an important part of those "non-productive pauses" in the process — the mental health and dopamine that make someone want to stay on a team, keep fighting even with difficulties, friction, and problems. That's what we still need to analyse and understand better, because the demands would be the same for fewer people. Throughput will increase, but — like a CPU — if the mental load doesn't decrease and we don't offload, it'll heat up just the same and cause overheat.

And I say this because I've chatted with a developer who was worried about this. It opens up a broader human discussion: professional identity, the pleasure of programming, trust, and fear of replacement. I left note F at the end of the text with my perspective.

To bring it back, in this sense there might be a "merging" of responsibilities among people who move between product, people, and code. I'm not saying this is ideal, nor that it will happen everywhere, but — analysing it coldly — it could be a move to reduce layers, whether driven by cost pressure, the AI bubble, financial management problems, economic instability, political uncertainty, etc.

Visually, something like the Venn diagram below could happen — I'm comparing it with the Tech Lead, but understand it could lean toward any side.

I don't think everyone will like it — of course not — some people don't like to talk or are more introverted, but it's a supposition, considering the common movement toward flattening hierarchies.

The original Venn Diagram demonstrates a possible market trend aimed at reducing budgets and flattening organisational hierarchy.

Remember: this is from the perspective of an IT company. In a non-IT company, the Tech Lead might be the one losing responsibilities to someone from business or people. I've heard people saying they're "giving Claude Code to lawyers to work with." And honestly, it works for simple things — it solves them, you don't need to know much. But it certainly won't be a scalable system unless the person has the basics of computing, engineering, etc.

Now, returning to the roles I mentioned earlier after the first Venn diagram: those of you at strategic or operational management/control levels receive tonnes of knowledge and data every day, because you need to make important decisions. You are decision-makers by nature — at least you should be, right? I know it's not always the case, there are exceptions, but in general you are decision-makers and also the people who assume the most risks considering the structure of our current process.

With that in mind, you could introduce this type of flow/idea and start treating LLMs and Deep Learning as linguistic processors in knowledge-based systems to achieve better performance and quality of life, by offloading a good level of the cognitive load you receive.

Now seriously: have you ever thought about the number of unnecessary emails you have to keep up with, or that classic 30-minute meeting that exists because nobody registered proper context beforehand?

Pulling meeting transcripts and sending them to your "linguistic processor" to extract everything each person said and update your definitions — like: (Fulana took responsibility for task Y) or (Fulano brought a different approach, maybe in context Z this could be well applied), or even more critically: (Based on factors X, Y, Z, and based on your company's public vision, in order to increase its value, this might be the most suitable path — if you have critical sense, please filter...).

Let me give an example I've encountered: "Oh, I need to check with the Dev what our system infrastructure is because the client's technical team is asking and I need to send an email." Imagine that now, with AI, you can have the project or documentation ingested into your machine and it will know — no need to call the Dev and have a 30-60 minute meeting to search for everything because it's not documented operationally, or you just need a double-check just to write the email. That's 30-60 minutes saved for you to do more important things or have better quality of life.

And with that, you start generating organisational knowledge graphs — decisions, relationships, responsibilities, dependencies, history, trade-offs, people. That stops being "Where is this?" and becomes traceable — imagine that.

And in this sense, Claude CoWork seems to be a great example. I'm quite excited about it, but I think we need to start an open source project — otherwise everyone will become dependent on AI companies for productivity. Just to reiterate: productivity != quality. They are different things. And to scale productivity with quality, you need well-defined processes and ways to ensure that people, software, and business won't break the process. Engineering, and specifically SQA, is for that. Build Trust and Ownership/Traceability into your process. Without that, no AI solves your problem — because it's organisational, not linguistic. Same as with broken "Scrum": it'll go wrong. Not a question of if — it will go wrong, it's wrong at the organisational level.

To wrap this up — speaking practically, but making a disclaimer: the technical team would theoretically be at an advantage, but we might start seeing a loss of space internally within Tech Teams too. I left this reflection in note D at the end so I don't drag on here.

Excel Handles It. But Does Your Organisation Really Apply Kaizen?

Coming down a bit more to organisations, let me bring a quick reminder of how the organisational structure of a more mature company works — something like CMMI level 3 or, if more mature, CMMI level 4. Just because something is old doesn't mean it's dead. Let's not argue that Scrum, Waterfall, or Kaizen is bad because it's from the 90s — it's still valid.

The image from the internet demonstrates, in a simple and grouped way, the organisational hierarchy of any company.

I haven't evaluated the data possibilities, but if you want to do an analysis, think about linguistic gaps (including knowledge) that an LLM could replace or enhance.

This is not about internal fighting, but positioning is important in the system we live in.

The plan I'm proposing here is for companies at CMMI level 4 or 5, but it can be applied at lower levels with caveats — I left this discussion in note E at the end for those who want to go deeper.

If this makes sense for your organisation, CMMI and ISO are good manuals. But implementing quality standards is expensive, requires organisational maturity, and the difficult part is rarely technical — it's always Peopleware. Culture, people, and incentives weigh more than any checklist.

Just drawing a parallel, I really like a perspective a professor once shared with me. These aren't the exact words, but I think it's good to remember — not least because you don't have a choice: capitalism forces you regardless.

Remember that even if you don't have a CNPJ (business registration), you have a CPF (individual taxpayer ID) and you are a company in the eyes of capitalism. And, thinking about CMMI — aside from Kaizen, which I like — the idea is for me to achieve CMMI level 4 maturity. So I can play at life's baseline. And God willing, of course — otherwise, accept it and move on.

Simply put — the vault would be part of my "personal company," which needs to go from CMMI 0 to level 5. There's still a way to go, but it's already a start.

Architecture at Last, Finally.

I've finally reached this part. And to think that two weeks ago I was considering 30,000 characters. Apparently 90,000 isn't enough hahaha.

But honestly, I'd much rather you leave with the rest of the article in your mind and start thinking about how to reposition yourself in your career and organisation with this entire rise of LLMs and Deep Learning, and how they can impact your life. Not because the architecture isn't important, but because critical thinking will bring you the greatest return. The architecture is a template — you adjust it however you want and optimise it for your Harness.

I started reflecting on this around mid-2025, when I was in much more troubled waters. Now I think it's starting to produce results I can invest in with some ROI and think about new business models. As a note: critical thinking is more valuable than knowing code and architecture just for the sake of it. Not that this isn't important, but without critical thinking, your architecture becomes guesswork.

If you're an established company and you've noticed this, it seems like a good option to start rethinking your competitive differentiator and check your BMC/Business Model Canvas to see if your business model will remain competitive in the near future. Maybe not this year, but I genuinely think more disruptive solutions will arrive soon. Either that or the AI bubble will burst. It's worth checking if your business model is still sustainable and where the LLM as a linguistic optimisation can strengthen your model.

But anyway — this might be the part many people are excited about. I didn't understand this very well until recently, and some recent technical conversations helped me organise these concepts. I won't turn this into a dossier, because the point here isn't to expose internal context. The point is the architectural idea.

This is the vision I think is important for the future of software engineering: not just "coding," "doing," but critical thinking — "doing intelligently and traceably."

Worth Remembering Pipelines

To briefly describe it, I arrived at this structure by talking to ChatGPT. I'd tried organising it in various ways, saw some Obsidian ricing with AI, but there was always that feeling of "I'm stockpiling text, not generating knowledge," or that thing where you waste more time on "ricing" than actually using the app productively hahaha.

But in the conversation, I asked it to optimise for being direct and focused for someone with ADHD, to avoid losing focus etc. I'd already mentioned I wanted to put an AI in the middle to solve this problem, thinking of it as a linguistic processor — my personal agent.

Then it suggested this structure, which I'll go into a bit more depth on. But in summary, you can think of the folder order as data pipeline layers — like "bronze," "silver," "gold," "diamond," etc. I liked it and I'll go with it.

So the structure wasn't born as a list of folders. It was born as a flow. Each folder represents a stage of processing: capture without friction, record what happened, transform commitment into task, connect task to direction, transform direction into project, maintain ongoing responsibilities, separate reusable knowledge, and finally let the agent learn patterns without mixing everything in the same place.

A Bit of Structure, Not Poetry

OK — stepping out of abstraction, now we can look at execution. I'll detail visually what each folder is and what its purpose is. The order matters because it's not just pretty folder aesthetics: it shows the gradual state change, from raw data to operational memory.

I asked the agent to describe each with practical examples, keeping focus on each folder's purpose without turning this into a personal dossier.

One important caution before the screenshots: this architecture deals with memory, tasks, work, people, and behaviour. So the publishing rule here is simple: if the image touches personal data, a person's name, sensitive task, private conversation, emotional state, professional context, or anything that doesn't need to become public material, I use blur/glass effect, crop it, or replace it with a conceptual diagram. The objective is to show the architectural pattern, not expose my life, the lives of others, or any internal work context.

00 — Inbox

The system's entry point. Everything raw lands here without organisational judgment: screenshots, downloaded PDFs, saved links, loose phone notes, random ideas, meeting captures. No structure, no filter. It's the equivalent of the pipeline's stdin — the raw, untreated material.

A practical example: I receive a PDF, take a screenshot of an error, save a link, or write a loose sentence like "I need to review this concept later." This doesn't need to be born organised. First it goes into Inbox. Later the agent can classify it: it becomes a task in TaskNotes, a reference in 05 - Resources, evidence in 03 - Projects, an insight in 07 - Insights, or simply junk that doesn't need to stay in the system. The Inbox exists to reduce capture friction; organisation comes later.

But raw capture isn't the same as history. The Inbox receives anything; the Journal records what happened over time.

01 — Journal

The chronological record of your personal or professional life, if you're using it at work.

Here you write what happened during the day: decisions made, meetings attended, blockers encountered, shower thoughts — it's a diary, not a report. It can have rants, it can have loose lines. The agent reads this history to understand context between sessions, but never writes here. It's exclusively your territory — the source of truth of what really happened from your perspective.

Look — to avoid making this a personal dossier, I asked the agent to generate an example of what a journal from a "standard DEV in Brazil" might look like. The result had me really cracking up:

[05:00] The alarm went off and I was already awake for a few minutes.
The phone vibrated on the bedside table and I got up before the second alarm.
Chocolate milk, toast, and fifteen minutes of blank screen trying to remember
where I left off in the code yesterday.

The routine is automatic: get up, coffee, open the laptop,
check if the build broke overnight.

[08:30] Stand-up standing, camera off, everyone tired.
Someone from product came with a story that the deadline
was brought forward because "they really need it" by Friday.
Nobody asked if it was feasible — as usual.

I stayed quiet during stand-up, but made a mental note:
this new feature has at least three unmapped flows
and the test pipeline is already slow.

> *Make a note: raise the unestimated points for this delivery at the next planning.*

[10:15] Code review of two PRs — the kid is good,
but has a habit of mixing responsibilities in the same function
that drives me nuts. I left a polite comment, but it was direct:
"suggest extracting the validation into a separate helper."

Between reviews, I opened the task I'd picked up myself: fix a permission
bug that's been showing up in one environment since Monday. Three hours later,
I discovered the problem wasn't in the frontend — it was an access rule
that another service wasn't returning in the right payload.

Someone on the backend had already solved something similar last month.
Went there, looked at an old commit, adapted it. Could have been worse.

[12:30] Break. Ate while glancing at a Twitter thread about
dev salaries in Brazil. My mistake. Spent the rest of lunch
calculating whether going back to contracting is worth it.

[15:00] Worked a bit on my personal project: a silly micro-SaaS
for freelancer invoice issuing. Small thing, but it's mine.
It's what reminds me that programming is still fun
when there's no stand-up to report to.

An older dev who worked with me years ago
always said that a personal project is the programmer's sanity thermometer.
Not sure if it's true, but today it made sense.

[17:20] The Friday delivery is already prepped. The permission bug went to a
staging environment, the PRs were approved, and the flow
is threateningly up to date. I'm always suspicious when everything is calm.

> *Still pending: update some technical documentation that was put off.*

[22:30] Tried to study an hour of something outside the work stack.
Opened a Go course, did 20 minutes, and passed out on the sofa.
The phone fell on the floor and woke me up to brush my teeth.

Fifteen years ago I thought programming was about solving problems.
It is about solving problems — they just didn't tell me that 40% of the time
is convincing people the problem exists.

The point is: the Journal records narrative and context. When something in there becomes a commitment, deadline, or concrete action, it needs to leave the narrative and become an operational artifact.

02 — Task Notes

The operational layer of the system. Every task with a date, priority, and context becomes a note here with structured metadata: status, due date, related project, priority. It's not a pretty kanban — it's a traceable task database. Examples: "review a technical delivery by Friday," "buy birthday gift," "prepare presentation slides," "follow up on a conversation," "align expectations about a pending issue."

The agent creates, updates, and queries these notes automatically. On /recap, it pulls the operational status from the last session and gives you a daily recap to keep you in the loop.

On /offload, it updates statuses and distributes everything according to the appropriate classification: resources, insights, goals, areas, etc.

But a task without direction just becomes an endless to-do list. That's why there's a layer above tasks: goals.

03 — Metas (Goals)

Long-term directions, not checklists.

Here live the objectives that don't expire: "I want to become a reference in software engineering," "I want to organise my knowledge systematically," "I want to improve my health and routine."

Goals don't have a Definition of Done — they are vectors, indicating direction, not destinations.

They serve as a north star for the agent to prioritise: a project serves a goal, an article serves a goal, a task serves a project that serves a goal.

If an opportunity doesn't point to any goal, it's a distraction.

So the goal provides direction, but doesn't deliver anything on its own. When that direction needs to become something physical — with a start, end, risk, and evidence — it descends into a project.

04 — Projects

Where knowledge becomes deliverable. Unlike Goals, this is execution with a beginning, middle, and expected end: an article to publish, a thesis to finish, a talk to present, an exam to study for, a vault template to release. Each project has associated artifacts: documents, diagrams, code, presentations, checklists, decisions, risks, and evidence.

I like to think a project needs at least one manifesto or index note. It doesn't need to be perfect, but it needs to answer: what is this, why does it exist, what physical output will come out of it, what risks exist, what next steps are alive, and what is the Definition of Done. From there, the agent can work as an analyst alongside you: refining scope, turning conversation into plan, pulling related tasks, creating diagrams, organising references, and maintaining traceability between intention and delivery.

To keep the example publishable, think of a fictional project like this:

03 - Projects/
  Technical talk project/
    Manifest.md                 -> intention, audience, final deliverable, risks
    Execution plan.md            -> stages, decisions, and next steps
    References.md                -> sources and supporting materials
    Evidence.md                  -> censored screenshots, public links, or permitted attachments
    Related tasks                -> filtered view from TaskNotes

In this model, the Manifest.md note defines the physical manifestation of the project: a talk, an article, a prototype, a thesis, an academic deliverable. The Execution plan holds the path. The Related tasks show the operational state without needing to publish a real board, names, internal deadlines, or details that shouldn't leave the original environment.

05 — Areas

Ongoing responsibilities that don't have an end in themselves.

Unlike projects that deliver and end, areas are maintained over time: professional context, finances, health, relationships, personal and technical development.

For example, a professional context area can track recurring learnings, responsibilities, career objectives, and decisions that need continuity — without exposing internal projects, organisational charts, people's names, or operational details.

"Finance" tracks bills, investments, planning.

"People" maintains personal relationship history. The agent uses these folders as long-term memory to understand your context and not have to ask everything from scratch each session.

I'd rather not publish a detailed screenshot here, because this is precisely where people's names, work context, or personal responsibilities might appear. The concept is simple: a project delivers something; an area sustains something.

A talk ends. A thesis ends. But career, health, finances, family, relationships, and work continue to exist and accumulate context over years.

So far the architecture deals with life, decision, and execution. The next layer shifts nature a bit: it's not about what I have to do, but about what I want to be able to reuse as knowledge.

06 — Resources

Your curated encyclopaedia. Depersonalised, reusable knowledge organised by area of learning: software engineering, linguistics, quality, computer science, methodologies. Unlike a Google search, the filter here is yours — it's what you've read, validated, and considered relevant. The agent uses these resources as a technical foundation to write articles, answer questions, suggest approaches. Examples: a note on the difference between CMMI levels 3 and 4, a map of systemic-functional linguistics, a software testing guide with academic sources.

An example of what an initial concept might look like:

Resources is cleaner, reusable, and less personal knowledge. But there's another kind of knowledge that doesn't come from books, articles, or documentation: it comes from the system's own use. That's where Insights comes in.

07 — Insights (Agent Memory)

This part is crucial — especially after the two commands I'll show you shortly: the memory the agent builds about you over time.

Unlike the other folders that store objective information, this is the interpretation layer: perceived behavioural patterns, communication preferences, session learnings, mapped relationships, thematic dossiers. It's what allows the agent to remember who you are between sessions — your working style, what you value, how you prefer to be corrected, what subjects energise you.

Without this, every conversation would start from scratch.

It also includes the "Current Commitments" file, which tracks the active focus and pending promises.

I'd also rather not expose a full screenshot of this layer, because it may contain personal patterns, behavioural observations, relationships, moods, commitments, and session history.

The architectural point isn't to show raw content; it's to show the folder's role: it functions as interpreted and revisable memory, separate from the Journal.

The Journal records what happened; Insights records what the system learned — reactions, relationships, behaviours, patterns — always with traceability and care not to turn hypothesis into absolute truth.

With that, we close the main part of the vault as a knowledge base: entry, history, task, direction, execution, responsibilities, reference, and memory. In practice, this architecture appears to me through operational commands. For example:

/recap -> opens the session by reading current focus, last sessions, tasks, and behavioural patterns
/recap latest -> quick summary of the last session
/recap subject <note> -> recaps context around a specific note

/offload -> closes the session, generates digest, saves decisions, and updates operational memory
/contain -> parks a useful tangent and returns to the current mission
/progress -> generates weekly/monthly report on goals, projects, journal, tasks, and digests
/chill -> musical conversation with quick research when I'm outside heavy focus, on break, or remembered a song that resonates with the subject.

/get-things-done -> experimental command for a full development flow when it makes sense, still in testing — serves to execute a spec from start to finish.

To prove the agent retains context, I did a quick recap using the command I created here (/recap), and it wanted to respond with an Albert Camus quote just because I briefly discussed Camus a while ago. It mixed English and Portuguese, but the experimentation is still evolving.

Since I talked about Camus a while back, it decided to recall absurdism hahahaha.

But this list is just the visible interface. For these commands not to become loose macros, there's a more important layer underneath: the rules that tell the agent how to behave inside the vault.

AGENTS.md — The Agent Kernel

Now we get to the part that, for me, makes this stop being just "chat inside Obsidian" and starts becoming real architecture.

Inside the vault there's a file called AGENTS.md. I like to think of it as the kernel or bootloader of the agent. It's not where I store domain knowledge. It's where I define how the agent should behave inside the system.

If Obsidian is the knowledge base, AGENTS.md is the execution rules layer. It says things like:

• this folder here is a knowledge vault, not a normal code repository;
• don't reorganise, delete, or archive notes without understanding context;
• use Obsidian wikilinks to maintain traceability;
• preserve frontmatter, Dataview, embeds, callouts, and existing structure;
• don't write agent-generated analysis inside my Journal;
• treat tasks as artifacts with a Definition of Done, not as vague intentions;
• if I declare active focus, that becomes an operational lock until I explicitly change it;
• if I ask for a reminder, create an observable artifact — don't just say "I'll remember";
• if a good tangent appears during active focus, park it in a note and return to the main path.

In other words, I don't want a loose "creative" model inside my base. I want a linguistic processor with limits, traceability, and predictable behaviour. AGENTS.md is the system's safety and behaviour boundary.

To make it clearer, think of it this way: a bare LLM is a linguistic CPU without an operating system. It processes text very well, but it doesn't know, on its own, which files it can touch, where to store memory, when to stop a tangent, or which task really matters. AGENTS.md begins transforming that linguistic CPU into a controlled process inside my vault.

AGENTS.md should be small and document the general rules, the architecture, what the agent should do with the project, and what each thing is for.

If it were a codebase: "how to build and run the project," "run tests." In this case, since it's a knowledge base: "how to access goals," "how to describe things," etc.

In this case, there are OpenCode's instructions. There I've left the heavier description that the agent pulls in as needed — like the adhd-containment-protocol.md, which prevents me from opening endless threads.

So you can separate it like this: AGENTS.md is the short kernel — the minimum that always needs to be clear. The .opencode folder is where the more specific protocols live, like modules loaded by the runtime.

.opencode — The Runtime Protocols

After AGENTS.md comes the .opencode/ folder. This is the part closest to an actual runtime.

I went to check the OpenCode documentation to avoid talking nonsense here: AGENTS.md is indeed the project's rules/instructions file, /init creates or improves this file, and opencode.json can load extra files in the instructions field. These files are combined with AGENTS.md, so it makes sense to treat this as a rules layer, not as some mystical hack of mine.

In my case, opencode.json automatically loads the files in .opencode/instructions/*.md. This means I separate agent behaviour into smaller protocols, each with a clear responsibility. It's not all in one giant, chaotic prompt. It's more like system modules.

And just to be explicit: this is standard OpenCode behaviour — I'm not using Oh My Open Agents in this architecture. It's OpenCode reading AGENTS.md, opencode.json, commands, instructions, and the vault's local structure.

This same file can also declare external integrations, such as MCPs. According to the current documentation, MCP goes in the mcp field of the config and can be local or remote, enabling external tools alongside OpenCode's native tools. The point is not to sell a specific tool as a universal standard; it's to show the architectural pattern: the LLM is not isolated — it can operate inside a vault, read context, call tools, and return traceable artifacts.

I was using Oh My Open Agents, but I removed it for now because I'm going to refactor and keep my environment cleaner here, going step by step to stay organised and productive.

Today the main protocols are:

• gabriel-operating-model.md — the agent's operational profile layer. The idea here isn't to create a psychological record or pretend the model "discovered my essence." It's much more pragmatic: documenting how I function when working with an LLM so the agent can adjust the interface. In my case, that means observing signals from the interaction itself — tone shift, excess tangents, rapid context switching, irritation, fatigue, silence, verbosity, escape into more interesting tasks — and turning that into useful behaviour: respond first with the recommended action, reduce ambiguity, limit priorities, keep text scannable, preserve depth without turning into a thesis, ask for confirmation only when needed, park good ideas without letting them hijack the task, and always return a traceable next step. It's less a "personality profile" and more a cognitive ergonomics file: if the user operates a certain way, the agent needs to learn to operate with them, not against them — not follow the "global productivity standard," but follow the standard that works with me.
• focus-allocation-lock.md — the focus lock. If I say I'm allocated to a task, the agent can't simply pull me to something else because it seems more interesting. This is essential for ADHD — otherwise the tool becomes a machine for opening mental tabs.
• adhd-containment.md — the anti-tangent protocol. If a good idea appears in the middle of work, it's not discarded, but it also doesn't hijack the flow. The agent creates a note in 07 - Insights/Findings/Future Study Ideas/, registers the idea, and returns to the main task. It's basically a parking lot for the dopamine goblin not to take the wheel.
• scheduling-and-reminders.md — the commitments protocol. If I ask "remind me about this tomorrow," the agent needs to create a task, event, checklist, or dated note. Memory without an artifact is just a pretty promise.
• journal-boundary-and-insight-routing.md — the rule that protects my Journal. The diary is authorial source material, not a place for the agent to dump analysis, advice, or coaching. If something important appears in the Journal, the agent can create an insight in 07 - Insights/Findings/, linking back to the source.

There are also reference documents inside .opencode/instructions/reference/. They don't need to be loaded all the time. They're longer materials about vault architecture, memory rules, people, operational profile, and OpenCode extension itself. This is important because context also has a cost. Not every rule needs to be on the hot path all the time.

The current inventory of the OpenCode side looks like this:

Vault local layer
  AGENTS.md
    -> short kernel, global rules, vault safety, and behaviour map

  opencode.json
    -> loads .opencode/instructions/*.md
    -> can declare local or remote MCPs when it makes sense

  .opencode/instructions/
    -> gabriel-operating-model.md
    -> focus-allocation-lock.md
    -> adhd-containment.md
    -> scheduling-and-reminders.md
    -> journal-boundary-and-insight-routing.md

  .opencode/instructions/reference/
    -> user-operating-profile.md
    -> vault-architecture-reference.md
    -> memory-and-people-rules.md
    -> opencode-extension-rules.md

  .opencode/commands/
    -> recap.md
    -> offload.md
    -> contain.md
    -> progress.md
    -> chill.md
    -> get-things-done.md

  .opencode/agents/
    -> reserved, no custom agent active at the moment

  OpenCode built-in agents
    -> Build and Plan as primary agents
    -> General, Explore, and Scout as subagents
    -> I haven't created my own agent here yet

  .opencode/skills/obsidian-vault/
    -> reserved, no SKILL.md active yet

  .opencode/modes, plugins, tools, themes/
    -> reserved for future extension

Global user layer
  ~/.config/opencode/opencode.jsonc
    -> minimal global configuration, just schema

  ~/.config/opencode/package.json
    -> global dependency of the OpenCode plugin

  ~/.config/opencode/AGENTS.md
    -> doesn't exist today, so no personal global rule active through this path

  ~/.config/opencode/commands, agents, skills, plugins
    -> don't exist today, so the real architecture is concentrated in the vault

There's also the desktop OpenCode app data folder, but I don't consider that part of the publishable architecture. It's app cache/runtime, not intentional system design.

According to the documentation, OpenCode also merges configs in layers: global configuration, project configuration, .opencode/ directories, environment variables, and managed configurations. So this architecture has a good advantage: what's a project rule stays in the vault; what's a global machine preference can stay in ~/.config/opencode; and what's app cache doesn't enter the conversation.

After this technical foundation, there's one last piece that seems like a detail but changes the experience significantly: personalisation without treating the user as a fixed character.

Personalisation Without Mysticism: Heuristics, Temperament, and Operational Model

A delicate point here: I'm not saying the agent "discovers who I am" in a magical way. Nor am I advocating MBTI, Temperaments, or any other informal model as hard science, diagnosis, or fixed identity. This becomes astrology very quickly if the person isn't careful, and you can delude yourself. It serves as a view of how you operate, but it's not absolute truth — it just helped me understand better here.

Even so, as interface language, these models can be useful. Not to prove who I am, but to register approximate operational preferences: how I tend to think, what kind of response helps me, what kind of format reduces friction, when an explanation needs to be more conceptual and when it needs to become the next action.

So, instead of writing "I'm such and such a type" or "my temperament is this thing," the file can register something more useful and less mystical: this user seems to function better with systemic vision, conceptual depth, autonomy, clear next steps, and low tolerance for waffle. If I want to use MBTI-A, Temperaments, or any other lens, it enters only as auxiliary and revisable vocabulary — not as truth about the person. The point isn't to get a classification right; it's to calibrate the type of response that helps.

In my specific case, it's been:

• straight to the point, but without being shallow;
• system view, not just checklist;
• clear next action when I'm stuck;
• tangent containment when the idea is good but not the priority;
• humour and real conversation when I'm entering a loop;
• philosophical depth when it makes sense, without turning everything into a motivational speech.

This changes the interaction significantly. Instead of every chat starting from scratch, the system accumulates a revisable operational model. If it notices I'm irritated, scattered, or trying to switch focus for the third time, it doesn't need to lecture me.

It needs to reduce ambiguity, lock scope, and give me a small action to get out of the loop.

This is an important difference between personalisation and invasion.

The goal is not to create a psychological dossier to define me. The goal is to create a working interface that respects how I function and improves with evidence.

Every observation needs to be traceable, uncertain when uncertain, and revisable when wrong. The goal is to calibrate consistently, not to build a psychological dossier.

With rules, protocols, and an operational model defined, commands become the session lifecycle: open context, work, and close state.

Commands — Recap and Offload as Boot/Shutdown Cycle

In addition to the fixed instructions, I use commands inside .opencode/commands/. The two main ones are /recap and /offload.

/recap works as a session boot. It reads Current Commitments, open tasks with deadlines, recent session digests, and recent behavioural patterns. With that, it returns something like:

• what is the active mission;
• which task is overdue or urgent;
• what was my state in the last session;
• which tangents were blocked;
• what is the smallest next step.

/offload is the shutdown. At the end of the session, it records what changed, which files were modified, what my state was, which patterns appeared, what decisions were made, and what next steps are pending. This generates a Session Digest inside 07 - Insights/Memories/.

This cycle is very important because an LLM, by default, is a disposable session. The conversation ends and most of the context dies. With recap/offload, I create persistence. The session becomes part of the system.

Summarising the Harness

So the current architecture looks roughly like this:

Obsidian Vault
  ├── AGENTS.md                    -> kernel / global rules / guardrails
  ├── opencode.json                -> loads instructions and integrations
  ├── .opencode/instructions/      -> active agent protocols
  ├── .opencode/commands/          -> operational commands like /recap and /offload
  ├── .opencode/*                  -> reserved for standard OpenCode extensions
  ├── TaskNotes/Tasks/             -> operational layer for commitments and Definition of Done
  ├── 01 - Journal/                -> chronological authorial source
  ├── 07 - Insights/Memories/      -> cross-session memory
  ├── 07 - Insights/Findings/      -> patterns, hypotheses, and interpreted learnings
  └── 06 - Outputs/                -> published artifacts, like this article

In terms of flow, it looks like this:

Human input + vault context
        ↓
AGENTS.md defines global boundaries
        ↓
.opencode/instructions defines execution protocols
        ↓
LLM processes language, context, tasks, and files
        ↓
Result becomes task, insight, digest, output, or traceable decision
        ↓
/offload saves state for the next session
        ↓
/recap recovers state and restarts the cycle

To me, this is the difference between "using a chat" and building a linguistic harness. The value isn't just in the model responding well. The value lies in placing the model inside an environment with memory, rules, artifacts, boundaries, and a feedback loop.

And here we return to the point of the entire article: if knowledge is represented in language, and if organisations often break due to loss of linguistic context, then the next leap isn't just "using AI to generate text." It's building systems where language, memory, decision, and action are connected.

Before moving on to the practical examples, there's just the back end to mention. It's not the most interesting part of the architecture, but without it the system starts becoming a mess of loose files.

99

The system's back end. Three support categories live here: templates that standardise how notes are created (task note structure, finding, session digest); assets like images and attachments used in articles; and archives — closed projects, deprecated notes, old versions. It's not active flow, but without this folder the rest doesn't work: templates ensure consistency, assets enable embeds, and archives prevent loss of history.

Practical Example

Alright — now that we've covered the architecture definition, let me give 3 practical examples I've had recently: 2 related to university and organisation, and 1 related to my final thesis.

Example 1 — Machine Learning Exam Summary

I recently had a Machine Learning exam at university. I had my notes, but they were in the initial state described earlier — all over the place. I wasn't happy with that, so I asked my agent, via Claudian in Obsidian, to pull everything I'd written, refine it with the class slides and online research, and create an MOC (Map of Content) of Machine Learning concepts. It worked really well — it adjusted everything and pulled in/clarified quite a few concepts. In the end, I also asked for a summary, all in the outputs folder.

Look how my graph turned out afterwards — much better for finding things and studying/talking with the agent.

I managed to organise the Machine Learning topics — nice, now I can work more freely and organised with the knowledge.

Example 2 — Presentation Summary

The other example is an exam I had today, 23/06, on software verification and quality. Our professor mentioned that the presentation slides we'd presented would be on the exam — ended up not being on it haha. But I wanted to do a summary because, since high school, I've thought that cramming everything at the last minute is silly. I prefer to study during classes and outside, and only review the concepts a day or two before — otherwise, I spend too much energy thinking about the subject.

So, what I did: I threw all the presentations into the folder and asked the agent to analyse each one, do external research, and generate a "Manifesto" of the subject for concept review.

It generated it and even included a note about what's important to remember.

Basically what a summary should be.

But seriously, I liked the idea of working with "Manifestos" because, by definition, a manifesto expresses intention. Semantically, it makes sense to me.

Example 3 — Final Thesis Refinement

Well, this is the last one, but I'll comment because it was interesting to test the idea. What I did: threw everything I have for my thesis in here — some things from MemPalace, others from Azure DevOps — and asked the agent to do RAG and keep refining. It helps enormously. You pull in a lot of context and keep refining. I already had about 2 large PDFs detailing my idea and project, so it was good to refine the project and flows. It doesn't replace my knowledge, but it accelerates the refinement and structuring process of an MVP solution. I liked it.

I think what differentiates this from Vibe Coding is the rigour and discipline in the process. During a normal process, you focus on actually making trade-offs. In Vibe Coding, you want to see the feature ready more than you want to see it actually within engineering quality standards.

In the photo, the PDFs aren't there because they were already ingested in the context, but the ideal is to throw all PDFs there in the future, so it becomes something like a project datalake — that makes much more sense.

In a company, you could throw a project proposal in there to keep refining, or ask for research and generate customer segmentation, segment summary, etc.

Thank You, Dear Explorer

Thank you, truly. I hope you've grasped my perspective on the changing state of technology and society at large — regarding the loss of focus and how attention is becoming a scarce resource.

We'll probably start offloading knowledge management to systems like Obsidian + Claude/LLMs or similar. I genuinely think this will be more efficient because they'll be specialised systems close to the logic of Knowledge-Based Systems.

And, in that sense, I've shared a vision of changing roles in technology, making you reflect on how you'll position yourself knowing this will likely happen across any linguistic gap.

And one point to close: if you work with knowledge, you already work with linguistics. One of the great problems of domain modelling is linguistic.

In the end, that's it: I'm running an experiment. When I have more results, I'll post them here — and I'm already considering creating a repository with a template to get started.

Opening the Dialogue

And if you work in engineering, product, management, architecture, operations, or strategy and are trying to understand how to apply LLMs practically within an organisation, I'm completely open to exchanging ideas.

My interest here is not to treat AI as hype, but as a real support layer for reducing cognitive load, improving knowledge management, accelerating decisions, and transforming scattered context into useful artifacts.

I'm interested in working on and building projects where software engineering, distributed systems, applied AI, quality, language, and business meet. Real digital transformation.

If this kind of vision makes sense for your team's or your company's challenges, it would be a pleasure to talk.

Leaving a more human reflection at the end: will we start replacing our knowledge and focus with a type of glorified hard drive?

And with that... will our human IOPS be able to handle the load?

Signing off for today — I'll leave some references below and a soundtrack for reflection...

Article soundtrack: XXI Century Blood — The Warning 🎸 "Will we regret our addiction to the rush?" — released in 2017 by girls who weren't even 18 yet. Even so, it feels like yesterday hahaha. Leaving the reflection with the soundtrack.

📎 Notes

A — On Psychology and Psychotherapy. I'm not against any cognitive or neurological therapy treatment. On the contrary, I was fortunately able to undergo it for many years and I'm certain it gave me a much better life. I trust psychologists and psychiatrists — I even have friends whose work I trust deeply.

Also, if you're from Franca-SP, know that Uni-Facef offers free psychological care through their psychology department's student team. If you're going through difficulties or need a professional hug, drop by. Anxiety and depression have been growing a lot — don't stay alone, seek support. Your life matters.

B — Claude Code and the file buffer in VSCode. It's been a while since I've actually touched code — I just read, plan, refine, converse in natural language. If I load a file from the projects I'm working on, VSCode takes about 5 seconds because the C# LSP decides to burn the CPU doing a zillion analyses. Using Claude Code, it just makes the changes and I see the git diff afterwards. Nobody can stand waiting 5–20 seconds to load a file because today's editors want to allocate 8GB just to spin up a project of 10 microservices. Tough business, hahaha.

C — Linear, Edge Engineering, and Proposal. Take a look at Linear (competitor to Jira and Azure DevOps) — it seems their goal is to reduce these coordination roles. In more innovative organisations, these roles might lose space if they remain closed in the current circle. In that case, I say "Losing Space" as a merging of functions between people from different areas — the so-called T-shaped professional will continue to be more valued.

D — Operations and Development: the gap may be closing. The Operations folks have evolved a lot in automation, and a company with a cost-cutting vision might prefer an operator who knows how to program or a developer who knows how to operate the artifact. In our case, I know there's a sea of subdivisions — Architect, Cloud Engineer, etc. — that already dialogue with Operations and Dev. If you're an architect, add business to the equation and, depending on the case, you enter even the strategic level with technology master plans. Yes, in a chaotic scenario we could be competing with these people, but then it's no longer about code. It's Peopleware, Business, and Auditing too.

E — Organisational Maturity and CMMI. After chatting with my newest 24/7 colleague here in Obsidian (also known as OpenCode + Obsidian), I realised that what I'm proposing applies best to companies with CMMI 4 maturity (structured and actively monitored processes) or 5 (innovation in processes). But even so, this scenario can be projected in most organisations at lower levels — maybe Big Techs are outliers. If you're at CMMI 3, you can use these linguistic gaps to improve communication and reduce friction, aiming for level 4. You'll need to do a lot more, but it helps.

F — Developers and the Loss of Identity. Taking advantage of my CPU wanting to throw this point into the middle of the text, even though this could become another article hahaha.

Perhaps the analogy is similar to music. When someone says K-pop "has no soul" or that rock "became a market," they're usually trying to point to a phenomenon: some expressions are born from context, community, pain, identity, and belonging — like soul, rap, and rock at various moments in history. When something with intrinsic value goes through a productivity grinder or an industrial money-making machine, it can remain efficient, beautiful, and profitable, but lose part of its soul in the process.

Something similar could happen with development. For many people, the pleasure of programming isn't just in having a ready solution — it's in building, understanding, making mistakes, debugging, and feeling mastery over something.

If the work becomes merely "doing in 5 minutes what used to take an hour," that might be great for productivity, but it can also affect the identity of those who see themselves as useful through programming.

So yes, I understand the anxiety of thinking: "I'm a junior — an AI does what I do?" But a dev isn't just code. A dev is also quality, confidence, communication, trade-off, domain understanding, and responsibility for what they deliver.

Maybe I haven't felt this identity break with the same weight because I've never seen myself — in the long term — as someone who wants to program every day. I want to move toward something more related to engineering, cloud, SDLC, and architecture — still very technical, maybe 80%–90% technical, but at a different level of abstraction. Architecture is already a whole world — it remains technical, but deals with systems, constraints, trade-offs, business, and decisions more abstractly.

This won't happen overnight, but it's my goal. That's also why I love SDLC so much — there's an enormous range of things to explore across various areas of an organisation.

But I understand those who love the act of programming itself and feel that this movement takes away part of the pleasure of work.

And if you think you don't generate trust unless you execute a card and program, remember that when you take on a task on the board, you're saying you'll take it from start to finish with responsibility. When you choose a trade-off in the code and can defend that decision — that's also trust. You assumed a technical risk and took responsibility for it. This kind of responsibility still matters, and I understand it matters even more in this new scenario.

References

Linguistics

• Fundamentals of Linguistics (The LingOtter): introduction to the fundamental concepts of linguistics. Channel TheLingOtter, YouTube. https://youtu.be/CDC19kEeKMA

Compilers

• Why C Languages Don't Understand You (Laurie Wired): explanation about the compilation process and how C is interpreted by the computer. Channel Laurie Wired, YouTube. https://youtu.be/rv3S1HVxwD4

Language Agent Security

• NIST — Transition to Continuous Monitoring and Update of Language Agents: NIST mathematical proof supporting the transition to continuous monitoring and updating in AI systems. National Institute of Standards and Technology (NIST), 2026. https://www.nist.gov/news-events/news/2026/06/nist-mathematical-proof-supports-transition-continuous-monitor-and-update

Epidemiological Data

• CDC — ADHD Prevalence in US Children (2022): increase of ~1 million diagnosed children compared to 2016. Danielson ML et al., Journal of Clinical Child & Adolescent Psychology 2024;53(3):343–360. https://www.cdc.gov/adhd/data/index.html

• CDC — ADHD Diagnosis and Treatment in Adults (2023): ~15.5 million adults in the US with a current diagnosis. MMWR 2024;73(40):890–895. https://www.cdc.gov/mmwr/volumes/73/wr/mm7340a1.htm

• CDC — Autism Prevalence — ADDM Network (2000–2022): from 1 in 150 (2000) to 1 in 31 (2022). MMWR Surveillance Summaries 2025;74(SS-2):1–22. https://www.cdc.gov/autism/data-research/index.html

• WHO — Mental Health and COVID-19 (2022): global 25% increase in anxiety and depression prevalence in the first year of the pandemic. World Health Organization, Scientific brief, 2 March 2022. https://www.who.int/publications/i/item/WHO-2019-nCoV-Sci_Brief-Mental_health-2022.1

Impact of Technology and Digital Addiction on Attention

• Acute smartphone use impairs vigilance and inhibition: 45 minutes of smartphone use resulted in a decline in vigilance and impaired inhibition capacity. Nature Scientific Reports, 2023. https://www.nature.com/articles/s41598-023-50354-3

• Smartphone notifications affect cognitive control: the sound of a notification reduces sustained attention capacity, even without direct phone use (measured by ERP). PLOS One, 2022. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0277220

• Screen time and ADHD symptoms in adolescents: longitudinal study with ~4,000 adolescents over 5 years associated increased screen time with worsening inattention and impulsivity symptoms. Nature Scientific Reports, 2023. https://www.nature.com/articles/s41598-023-44105-7

• Problematic internet use and attention deficit (meta-analysis): significant correlation between problematic internet use and attention deficit (r = 0.36), hyperactivity, and impulsivity. Journal of Affective Disorders (Elsevier), 2023. https://www.sciencedirect.com/science/article/abs/pii/S0022395623004703

• Non-clinical attention deficit traits and vulnerability to digital addiction: people without an ADHD diagnosis but with elevated inattention traits are more prone to developing digital dependency. Current Psychology (Springer), 2023. https://link.springer.com/article/10.1007/s12144-023-05203-x

• Neuropsychological deficits in problematic screen use (meta-analysis): 43 studies indicated attention and focus as the most affected domain by problematic screen use (g = 0.50). Neuropsychology Review (Springer), 2023. https://link.springer.com/article/10.1007/s11065-023-09612-4

Process, SDLC, and LLMs

• Why LLMs Will Fail in Your Company (Fabio Akita): analysis of how LLMs expose the inability to decide in teams trained not to decide — and why the process needs to be redesigned around the new constraint. Akita On Rails, 24 Jun 2026. https://www.akitaonrails.com/2026/06/24/por-que-llms-vao-falhar-na-sua-empresa

• Google SRE Book — Postmortem Culture: Learning from Failure: reference on blameless postmortem culture, focus on contributing causes, documentation, traceability, and preventive actions after incidents. Site Reliability Engineering, Google/O'Reilly. https://sre.google/sre-book/postmortem-culture/

• Google SRE Workbook — Postmortem Culture: Learning from Failure: practical study on good and bad postmortems, including absent context, blaming language, absent ownership, action items without owners, and late publication. The Site Reliability Workbook, Google/O'Reilly. https://sre.google/workbook/postmortem-culture/

• Atlassian — How to Run a Blameless Postmortem: practical guide to blameless postmortems, root cause investigation, organisational learning, and continuous improvement after incidents. Atlassian Incident Management. https://www.atlassian.com/incident-management/postmortem/blameless

Philosophy and Sociology

The works below do not constitute clinical evidence nor do they claim to explain contemporary attention problems in isolation. They offer philosophical and sociological lenses to interpret how work structures, permanent availability, and the attention economy may contribute to cognitive overload.

• Byung-Chul Han — The Burnout Society (Müdigkeitsgesellschaft): analyses the shift from a society based primarily on external discipline — "you must" — to a performance-oriented society — "you can". In this scenario, the individual becomes both manager and worker of themselves, turning freedom, productivity, and self-optimisation into potential mechanisms of exhaustion.

• Jonathan Crary — 24/7: Late Capitalism and the Ends of Sleep: discusses how the logic of permanent availability seeks to occupy even the periods historically reserved for rest. Social media, notifications, and always-on systems compete not only for our time — they continuously compete for our attention.

• Mark Fisher — Capitalist Realism: questions the tendency to interpret suffering, anxiety, and attention difficulties exclusively as individual problems, without considering the social, economic, and labour conditions in which they arise. Fisher calls this process the "privatisation of stress": problems also produced by collective structures are returned to the individual as exclusively personal responsibility.

Obsidian Extensions

• YishenTu — GitHub: creator of the Claudian extension for Obsidian. https://github.com/YishenTu

• Laurie Wired — LinkedIn: public profile of the creator cited in the section on compilers and language. https://www.linkedin.com/in/laurie-kirk