Why connecting an MCP server costs context before you use it
I started noticing something small. Feed an agent every tool definition up front and it burns context before it does anything useful. Give it one scoped file and the command to run instead, and it just works.
Everyone has the same access to tools, but the agent still does not know when to reach for one, or how you want it used, and that knowledge has to load from somewhere too. Anthropic's own engineering team names both halves as the ways tool use inflates cost.
A skill is where I put the knowledge instead. It sits on disk until the task calls for it, and then only the part that matters comes in. That is when skills stopped being documentation and started being how you engineer context. Everything else is what happened when I kept pulling on it.
Docs teams arrived at the same shape from the other direction. llms.txt is a convention rather than a ratified standard, where a site publishes one scoped markdown file at a known path so an agent reads what matters instead of parsing the whole site. Different problem, same move. Put the knowledge somewhere cheap and fetch it when it is needed.
Why Claude's memory does not carry across Claude Code, chat, and Cowork
I build Trending Society alone, so there is no one to hand the memory problem to. Claude Code's memory lives per repository, CLAUDE.md plus whatever it writes down on its own. Chat memory on claude.ai reaches the web, desktop, and mobile apps, but stops there, it is not available in Cowork yet. And Cowork keeps its own memory too, scoped to a single project, with no visibility into what chat remembers. Three interfaces, one identity, and no shared memory between any of them that is easy to keep in sync.
Chat memory is the one that pulled me in. It writes itself, it works across every surface I use, and it is global instead of scoped to one repository. Claude Code holds more context about a project. Chat holds more context about me.
What has to survive when an AI session compacts or expires
Trending Society actually started in Linear, an AI-native build out for an AEO methodology and publishing across every platform. It was a coding and development environment first. Tasks, issues, the normal shape of building something.
Sessions degrade. They compact, they expire. What had to survive that was the handoff, the reasoning and the learnings, so the next session did not start over on what the last one had already worked out. That is what a skill is. Learnings, codified.
But the work kept pulling toward editorial and marketing, brand pages, decision history, content someone non-technical needed to read, and Linear is not built to hold that. It closes tickets. It does not compound knowledge for humans.
Notion or Linear? Deciding where each piece of knowledge lives
So I split the stack on purpose instead of arguing with myself about it every session.
| Layer | Tool | Source of truth for |
|---|---|---|
| 1 | Notion | What we know, decisions, frameworks, context |
| 2 | Skills | How we work, reusable methodology |
| 3 | Linear | What's happening now, tasks with a lifecycle |
| 4 | Slack | Real-time coordination, in theory |
| 5 | Projects | Engagement-scoped context |
Two rules hold the whole thing together.
- Every piece of knowledge gets exactly one canonical home.
- Linear never duplicates Notion. Linear tracks execution, Notion documents the reasoning behind it.
Why I keep Slack history instead of letting it evaporate
Slack is the one layer where the default is written for a different problem than the one I have. Ephemeral is right for coordination. What runs through my ingestion channel isn't coordination. Paste a URL into it and a bot picks it up, kicks off the job, and posts a progress message in the thread. When the job finishes, that same message rewrites itself into a result card with an approve button on it. Approving is what triggers the publish pipeline, so the channel is the one place a human has to touch an otherwise automated path.
Your whole team is already in Slack, and not in one role. Marketing, ops, whoever has to sign off. It is the only surface in the stack where the people on your team who don't read code can watch an automated path do its work and stop it before it ships. An agent cannot read history that already evaporated, and neither can the person who was in a meeting when it happened. That is why it stays.
I built it for myself first. I have architected this for teams, and I wanted to run it solo for a few months before handing anyone a workflow I had not already broken.
That approve button is the part I think gets skipped. An MCP connector makes it trivial to let a chatbot take a real action, and taking the action is the easy half. Knowing whether it should have fired is not. Anything that writes to a live system needs a place where a person can still say no, and that place has to stick around long enough for someone to look at it.
When a repeated workaround should become a skill
It's a real skill I run, closed-loop-routing, and it makes the "Notion or Linear" call so I do not relitigate it every session.
- A decision worth remembering goes to a Notion Decision Log.
- A task with a deadline goes to Linear.
If I catch myself doing the same workaround a third time, that is the signal it becomes a skill instead of a habit.
The one I hit most was research. Ask a model about the current state of anything and it reaches for its training data, which ends whenever it ends. I only caught it because I had the agent's steps visible and could watch it pull last year's numbers and hand them to me as now. So every session I typed the same correction. I want today, not the year you were trained on.
The third time I typed it, I put it in a file instead. That is where my skills actually came from. Not architecture. A correction I got tired of repeating.
What you give up when a tool hides where your code runs
Google Antigravity is where I first saw the pattern. An artifact, an implementation plan, and a verification loop, running together. I reverse engineered it into a skill so I could run it anywhere. What Antigravity would not give me was a straight answer to where my code was going to live a few months out.
If you cannot see where the work happens, you cannot learn the fundamentals under it. And nobody maintains what they do not understand. That is the trade sitting under every AI-native tool right now. Fast, or observable. A result today, or something a person can still reason about six months from now when it breaks. It was still beta, and the signals pointed somewhere I did not want to be a year in. I went the other way.
I rebuilt the pattern to be LLM agnostic, work I could continue in Claude Code or against a local model instead. I did not want to be glued to one desk running one IDE. Some of this work happens on my phone, which means claude.ai. Claude Desktop and Cowork stayed in the stack too, each one a different way of thinking through the same work, and losing either mode would have cost more friction. It is also why I run drafts through Perplexity, Gemini, and Claude as adversarial passes now. Each one drifts differently, and a pattern that held up two months ago can go stale without a second opinion catching it.
I have watched this trade get made before. I spent ten years in programmatic advertising, where automated buying got fast and opaque at the same time. The industry then spent years building back the parts it had skipped. Viewability standards. Supply path audits. A text file on every domain declaring who was actually allowed to sell that inventory, which the IAB introduced in 2017. None of that was innovation. It was repair work on something that shipped without it.
The tooling is new. The trade is not.
What breaks when the same skill lives in three places
It still breaks, and not because of the tooling. On August 18 I rewrote the canonical copy of my voice skill on my laptop. On August 22 I spent a session building eight versions on top of the copy installed in the chat app. Both copies reported the same version number. The installed one was a superseded lineage carrying nine files against thirty-three. Nothing on the surface looked wrong, which is why it took eight versions to catch.
The rule I wrote to prevent exactly this says one canonical home per fact. The skill had three. I was reading the wrong one. I was also jumping between too many projects that week, and a person switching between them is a session that degrades too. The routing held. I was the part that did not.
The repair was a hundred and thirty-six lines that hash every copy of a skill and report when two of them disagree. The rule had existed for months. The check did not.
That's not a knowledge problem. I knew the fix before I finished reading the error. What I don't have is a second person, and past that, no feedback loop telling me whether what I build serves anyone but me. Solo, every failure mode I solve is my own. That is the part that does not compound.
Linear still runs the work. Notion still holds the version a person can actually read, the version you could open without me walking you through it. The only thing that changed is I stopped pretending one tool could do both jobs.
Is there a right way to work this way yet
I am not going to tell you this is solved. Nobody has the source of truth for how to work this way yet, and every company shipping these tools is learning in real time. What hardens is the failures, but only the ones somebody can see. A failure you cannot observe is not a lesson, it is just a thing that happened. That is the same argument whether it is an agent session, an ad supply chain, or me on a Saturday reading the wrong copy of my own file.
There are a million tools and I can't tell you one is better than another, because the gap is never the tool. It is the layer between the tool and how a specific team actually works, and that layer gets built custom every time. The only way to build it well is to have hit the failure modes yourself, then ask enough questions to find out whether the person in front of you has different ones. You cannot solve the right problem until you have the context. Same rule I run on the agents. Ask more than you assume.
So this is where mine is right now, not where it landed. It travels, which is the part I care about. The same routing skill would run just as well handed to a team as it does running solo. If you are stuck in the same spot, three tools, no shared memory between them, I would like to hear how you are handling it.