Ok. MCP just shipped the biggest change since the day it launched, and the headline isn't a feature you get to switch on. It's the delete key.

The 2026-07-28 revision — people are calling it MCP 2.0, and it's the first release that breaks the base protocol on purpose — rips the session out. No more initialize handshake. No more notifications/initialized. No Mcp-Session-Id. No GET SSE endpoint, no resumable streams, no resources/subscribe, no roots/list at the top level, no ping, no logging/setLevel. Gone.

And here's the thing — that's the good news.

I've shipped servers behind three different gateways, and every one of them cracked open the JSON-RPC body to route a request. That's the tax the session quietly charged. On every call. This revision stops charging it.

Let's get the map down before we walk the wreckage. Six threads landed in one revision — a stateless core, an extensions framework, a rebuilt Tasks story, server-sent UI, an OAuth hardening pass, and a written deprecation policy — and every one of them hangs off the first. Delete the session and the other five stop being optional.

What they deleted (and why nobody's crying)​

The initialize handshake did three jobs at once, per connection: negotiate the protocol version, hand you the server's capabilities, hand the server yours. Three payloads welded together. That weld is gone, and the jobs got unbundled.

Protocol version, client info, client capabilities now ride in _meta on every request, next to a mandatory MCP-Protocol-Version header that has to match or the server answers 400. Server capabilities move to a new server/discover call you make only if you want them; servers must implement it, clients may never call it. Log level becomes a per-request field. Version negotiation happens inline — ask for a version the server doesn't speak and it hands back the list of ones it does.

So every request now carries who you are and what you speak. Self-contained. Which means it can land anywhere.

That last part is the whole point.

Sessions were never state. They were a bill.​

The part nobody printed on the box when MCP launched: the session wasn't a feature you used, it was a tax you paid down at the infrastructure layer. If you server held per-connection state, you had exactly three ways to run more than one box, and every one of them cost you money.

You pinned each client to the instance holding its state — sticky sessions. Or you stood up Redis or Postgres so any box could reload it — a shared store you now operate, monitor, and get paged about at 3am.. Or you put a gateway in front that cracked open the JSON-RPC body on every single request just to work out where to send it. Deep packet inspection. To route a shopping basket.

The sessionless design deletes all three at once.

Any request lands on any box. No shared store, no pinning, no gateway reading your mail. Round-robin and go home.

Where did the state go? Into the arguments.​

It didn't vanish. It became a string.

Instead of a basket the server secretly holds against your connection, the server exposes a create_basket() tool that hands back a basket_id — call it BBB — and the model threads BBB straight into add_item(BBB, …) and then checkout(BBB). No handles/* method, no handle type in the schema — a handle is a string in a result and a string in the next argument. Just a string.

And this is already how every server you actually use behaves. Linear's create_issue returns an issue id. GitHub's create_pull_request returns a PR number. Stripe's create_customer returns a customer id. Nobody was keeping your Stripe customer alive in a session — they handed you an id and told you to bring it back. The difference now is the model can see the id, instead of it hiding in a transport session behind the server.

How much of the ecosystem does this actually break? The maintainers ran the numbers on a sample of 1,000 open-source MCP servers. 90% never reference the session id at all. Another 3.5% only touch it as SDK routing boilerplate a sessionless transport deletes for them, and 2.8% touch it only to wire up the transport. Basically it's a two-line change for almost everyone, and a real rewrite for two small groups — servers that keyed application state on the session (2.5%), and gateways doing sticky routing (0.7%).

One catch, a security one: the requestState blob comes from the client on the next call, so it's untrusted input the second it leaves your process. Integrity-protect it, bind it to the authenticated principal and the original arguments, give it an expiry.

Signed requestState = untrusted input. Encrypted requestState = still untrusted, just unreadable. Signing is not a trust upgrade, so don't stuff anything secret in there and call it safe.

But the server still needs to ask you things​

A stateless server still has to stop mid-call and ask for something — confirm you really want to delete basket BBB, sample the model, read a root. The old way was a held-open SSE stream you side-channelled the question down. No stream anymore. So how?

The answer is a mechanism called Multi Round-Trip Requests, the cleanest idea in the release. Instead of streaming a question back, the server returns a result that says input_required, carrying the questions plus that opaque requestState blob. You gather the answers and re-issue the exact same call — original arguments, the new inputResponses, the same blob echoed back, a fresh request id. All the correlation lives in the payload, so the retry can land on any instance and rebuild from the blob alone.

Server A asked the question. Server B finished the job. Neither of them held anything.

The same pattern swallowed URL elicitation too: no separate completion notification, no server-held elicitationId. The client finishes the external interaction and retries the original call. And there's a quietly good consequence — a server can no longer prompt you out of nowhere. Every question is causally tied to a call you started. Less spooky. Easier to audit.

Extensions aren't bolt-ons. They're the new default shape.​

The stateless core is deliberately small, and everything that used to fight its way in now lives outside it as an extension. The mechanics are dull, and that's the point. Client and server each declare supported extensions as namespaced capabilities — official ones carry io.modelcontextprotocol/* identifiers, anyone else uses a reverse-DNS prefix so com.acme/whatever can't collide with the standard. Each extension versions and ships on its own clock, off the base-protocol calendar. So a new idea can land, get beaten on in production, and earn its way into core or not — without holding the whole spec hostage to one feature's release date.

Tasks got demoted. On purpose.​

Tasks — long-running work you kick off and check on later — shipped as an experimental core feature in 2025-11-25. Production got hold of it, found three things wrong, and the maintainers did the thing nobody wants to do to their own baby: they pulled it out of core and rebuilt it as an extension.

The old design made you prime a warmup before you could even issue a task. Its blocking tasks/result needed exactly the open SSE stream the new rules now ban. And tasks/list had no safe scope once the session was gone. The real reason, not the hand-wavy one: a random bearer handle with enough entropy can safely identify one task. It cannot safely enumerate every task a user is allowed to see. Enumeration needs an identity model — who are you, what may you list — and a protocol guessing game is not that. So tasks/list isn't replaced. It's removed.

What's left is smaller and reads clean. The client advertises the Tasks extension; the server decides per call whether to answer with a normal result or a task handle — kick off a full export of basket BBB and you get a handle back, not a hung connection. Reads (tasks/get) stay pure and idempotent. Writes (tasks/update, tasks/cancel) are separate. Call one against a server that never advertised the capability and you get a clean -32003 from the extension, or -32021 if you asked core. And the handle doesn't come back until the task is durably created — so you never poll for a task that isn't there yet.

The demotion is the real story, bigger than the feature. MCP now has a written path for "ship it as an extension, let production beat on it, promote it to core only if it survives." Tasks walked that path backwards and came out better for it. A protocol learning to say no to itself. Useful skill.

UI showed up, and it's in a box​

A tool can now render an actual interface. Not a wall of markdown — a real HTML app served under a ui:// scheme, dropped into a sandboxed iframe with no access to your DOM, your cookies, or your storage, talking to the host only through postMessage. MCP Apps has four actors, and holding them apart is the trick: the Server publishes the tool and the UI resource, the Host is the MCP client and the policy boundary, the Model picks ordinary tools and reads ordinary results, and the View is the untrusted HTML in the sandbox.

The security property that matters is where a click goes. Hit a button in that View and it doesn't get a private tunnel to the server — it comes back as an ordinary tools/call through the host, down the identical path a call from the model would take: same authentication, same consent, same per-tool visibility check, same line in the audit log. Visibility defaults to ["model","app"] per tool, and the host builds the sandbox's Content-Security-Policy out of _meta.ui.csp, so the server declares what its UI may load and the host enforces it. Server-authored code runs in a box, and everything it does leaves the box as structured JSON-RPC. That's the difference between a UI standard you can ship to enterprises and remote code execution with a nicer name.

But let's be honest about what a sandbox can and can't do. It fences the code. It does not fence the story the code tells a human. A sandboxed iframe can still paint a login form that isn't one, or hide a destructive action behind a cheerful blue button. CSP stops the JavaScript from phoning home. It does nothing about a screenshot-perfect fake asking for your password. The host has to keep its own chrome visibly separate and always show where the pixels came from — because the one thing you cannot sandbox is a lie.

The auth got hardened. The runtime didn't.​

Six changes tighten the OAuth 2.1 profile, and they're all the boring, correct kind. Issuer validation per RFC 9207 — the iss from the authorization response compared exactly against the issuer you picked before the redirect, no case folding, no trailing-slash cleanup. An application_type in dynamic registration, native for desktop and CLI and localhost clients, web for remote ones, so a desktop client's localhost redirect stops getting rejected on sight. Stored credentials bound to the validated issuer, so a resource moving issuer is a migration, not a quiet reuse of the old token. Defined refresh tokens, step-up scope accumulation, unambiguous .well-known paths, and a sane line on offline_access — the client may ask for it, the resource server should not demand it. Dynamic Client Registration is still there as a fallback but got deprecated late, in favour of Client ID Metadata Documents or pre-registration. And Enterprise-Managed Authorization went stable on 2026-06-18 — your IdP decides whether a client may reach a server at all, Okta first, with Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase on board.

Real improvements. Take them.

But does any of it authorise a tool call? No. Every one of these six governs the handshake — who you are, which server you may reach, at what scope, once. Not one checks whether this specific call, right now, with these arguments, is allowed to run. Per-call authorisation — the thing you actually want when your agent is firing tools in a loop at 40 requests a second — is still entirely yours to build.

Six locks on the front door. Zero on the hallway.

The unglamorous half nobody demos​

Once every request stands alone, clients need to know when cached data has gone off. So caching grew up: ttlMs and cacheScope land on cacheable results — public reusable across auth contexts, private not, the cache key covering the method and every parameter that can move the result. The TTL is a freshness hint, not a promise and not a polling schedule. A matching change notification invalidates the entry the instant it arrives, and a broken stream does not make a stale entry immortal.

When it expires, fetch again. That's the whole contract.

The old general GET stream and resources/subscribe/unsubscribe folded into one subscriptions/listen — a filtered subscription the server acknowledges, then feeds only the notifications you asked for. No Last-Event-ID recovery: stream breaks, you retry with a new id. Correctness comes from refetching; notifications only shave latency. Closing an HTTP response stream now cancels that request cleanly, and long-lived subscription streams stay alive with SSE-comment keep-alives so a proxy doesn't guillotine them for going quiet.

The rest reads like a checklist written by someone who has been paged: W3C Trace Context rides through _meta so host, gateway, server, and every downstream call show up in one trace; the Mcp-Method and Mcp-Name headers mirror the operation so a gateway can route, meter, and categorize traffic without parsing the body; and a tool input field marked x-mcp-header gets projected into an Mcp-Param-* header for the same reason. None of it makes a launch video.

A few quieter tightenings ride along. Tool schemas move to JSON Schema 2020-12, so what you already write for validation is what the protocol speaks. structuredContent stops insisting on an object — a tool can return an array, a number, a bare string, whatever the result actually is. Tool lists became deterministic — a stable ordering lets a client do a cheap equality check and lets the model's prompt cache actually hit. And the error codes got sorted: the old -32002 resource-not-found folds into the standard -32602, and three new codes -32020/-32021/-32022 show up. Not glamorous. Correct.

Who actually has work to do​

Ok, and now the part nobody demos… let's sort the migration by how much it's going to hurt. It is genuinely not the same for everyone.

• stdio-only local server, no HTTP sessions → wait for your Tier-1 SDK's release candidate — Python, TypeScript, Go, or C# — bump the dependency, done.
• Behind a gateway or a load balancer → drop the session id, move per-connection state onto explicit handles or the authenticated user, implement server/discover, emit Mcp-Method and Mcp-Name, and confirm your CDN and WAF pass Mcp-* through untouched — a proxy that strips an unknown header fails every request and looks exactly like a client bug at 2am.
• Built on the experimental Tasks API, or on server-initiated SSE elicitation → budget real time.

stdio-only local server = a no-op. Behind a gateway = the actual work, all of that 0.7% doing sticky routing and then some. Built on experimental Tasks = a rewrite.

And the trap in all three: don't migrate by chasing compiler errors. Detect the era explicitly and keep legacy and modern state on separate paths — an old client wants initialization and a session, a new one sends self-describing calls, an old server omits resultType and a new one must include it. Blend both eras in one ambiguous code path and you get bugs that look like networking, then capability negotiation, then random server amnesia. Test the wire, not the TypeScript types.

And don't build off the announcement examples. The RC was frozen back in May, but the intended-final draft kept moving: clientInfo became optional, serverInfo moved into result metadata, URL elicitation lost its completion notification, error ranges shifted, and DCR got deprecated late. The candidate stood still. The design did not.

Nothing forces your hand on the date. Old clients and new servers keep talking by negotiating down to 2025-11-25 — that's the whole back-compat story for the deleted pieces. Version negotiation, not a grace period. The stateless removals are a clean break, and none of them got the twelve-month deprecation floor: that floor covers features carrying the Deprecated annotation that still work, not calls cut outright. You migrate when your SDK is ready, not when the calendar tells you to.

The part where a protocol grows up​

There's one more change behind the mechanics, and it outlives all of them: MCP now has a grown-up way to change. Substantial proposals go through the SEP process with a Working Group attached, and nothing on the Standards Track reaches Final without a conformance-suite scenario proving it behaves. Features get real lifecycle states — Active, Deprecated, Removed — with a twelve-month floor before a deprecation is even eligible to be pulled, and a 90-day fast lane for security. Roots, Sampling, and Logging are the first residents of Deprecated; they still work, they just carry the annotation now.

There's a wonderful bit of comedy in the timing, the deadpan kind. This is the revision that writes down the careful twelve-month, conformance-gated, don't-yank-things-out-from-under-people policy — in the same breath that it yanks the session, the handshake, the GET stream, and half a dozen calls out of the core. Fine. You usually write the safety manual right after the thing you wish you'd had a safety manual for.

So, is this MCP 2.0?​

Officially, no. It's still date-versioned, it's 2026-07-28, and the maintainers will tell you the "2.0" label is a marketing accident.

Conceptually? I get why it sticks. The protocol just dropped its founding assumption — that a connection remembers who you are and what happened before you got here. Now every request explains itself, state carries a name instead of hiding in the wire, a paused interaction is a retry instead of a private phone call. Sessions felt like maturity. Real servers hold state, right? Turns out the session was the one grown-up-sounding thing standing between your server and a load balancer you never have to think about again. yeah, the maintainers looked at the most impressive feature they owned and hit delete.

State was free the whole time. The session was just the subscription.

Ok, let's say you working in the company and your management or you the manager all day long talking about being AI native. First of all what does it mean to become an AI native company? Fire all developers and build AI agents to make all work? Maybe. Or something less radical, like add AI in all steps of product lifecycle? Might be.

Regardless how radical you want to be, probably you will miss the most important point, without it all your idea of becoming an AI native company will fail. Moreover you might damage your company badly.

Let's go over a basic product life cycle (I believe it will cover up to 80% of tech companies out there).

Let's define Actors:

• Product Manager — comes up with ideas for new features, owns the roadmap, and makes prioritisation calls across the entire lifecycle
• Product Analyst — tells which features are in use, identifies patterns in user behaviour, and suggests new features or improvements to Product
• UX Designer — translates product ideas into wireframes, prototypes and user flows; ensures the experience is usable before a line of code is written
• Architect — defines the technical foundation; makes system design decisions at definition and design phases to ensure the product can scale, integrate, and be maintained long-term
• Engineering — builds the product; turns specs and designs into working software, raises technical constraints early
• QA / Testing — validates that what Engineering built matches what was defined; catches regressions and edge cases before release
• Marketing — shapes how the product is positioned and communicated to the market; drives awareness at launch and ongoing growth
• Sales — converts market interest into revenue; feeds back real customer objections and needs into the roadmap
• Customer Support — first line of contact after launch; surfaces recurring pain points and bugs that inform future iterations
• Data / Analytics — measures everything post-launch; tells the business what is working, what is not, and where to invest next
• Finance — validates the business case, tracks ROI, and gates investment decisions at key lifecycle milestones
• Legal / Compliance — ensures the product meets regulatory requirements; involved at definition and before any major release
• Exec / Leadership — sets strategic direction, allocates resources, and makes go/no-go calls at critical lifecycle gates

Ok. Up until now nothing new… let's add something that connects all of them… can you guess what is this? Yeah, money.. But I'm talking about something else — knowledge. How do all those actors share information? Meetings, emails, chats? Let's have another look at knowledge storages of different types.

Where does all the knowledge live? (Spoiler: everywhere and nowhere)​

Let's talk about something nobody warns you about when you join a product team. Every actor in the product lifecycle has their own favourite place to store knowledge. And surprise — none of them talk to each other by default.

You end up with a beautiful mess. The product manager has the grand vision locked in Confluence. The analyst has the real data somewhere in a Notion doc nobody can find. The architect drew the perfect diagram in Miro at 11pm and never shared the link. Developers have the actual truth buried in Jira tickets and Git commits. And the customer? They screamed into the Zendesk void and nobody connected that feedback to anything.

Here's how it actually breaks down by actor.

Product Manager lives in Confluence, Notion, or ProductBoard. This is where the PRDs, roadmaps, and meeting notes go to slowly become outdated. ProductBoard is for collecting ideas and prioritising features — basically a graveyard of great ideas that "aren't in scope this quarter."

Product Analyst lives in Mixpanel, Amplitude, Looker, or Google Analytics. They know which features nobody uses. They just need someone to actually read their reports.

UX Designer works in Figma and documents things in Confluence or Notion. Figma is where the real truth lives — the design system, the flows, the components. Confluence is where they paste screenshots of Figma that are already outdated.

Architect owns Miro, Lucidchart, or draw.io for diagrams, and drops the technical specs into Confluence. The architecture doc is usually either 3 years old or written last week in a panic before a review.

Engineering lives in Jira (tickets), GitHub/GitLab (code and PRs), and Confluence (technical docs nobody updates). The real knowledge is in the code and in developers' heads. That's the scary part.

QA / Testing tracks everything in Jira, TestRail, or Zephyr. Bug reports, test cases, regression results. It's detailed, organised, and the last place a product manager will ever look.

Marketing keeps their stuff in HubSpot, Notion, or shared Google Docs. Campaign briefs, messaging guidelines, competitor research — living in folders with names like "Final_v3_ACTUAL_final."

Sales runs on Salesforce or HubSpot CRM. Call notes, deals, customer objections, win/loss reasons. Probably the richest source of real-world product feedback. Also probably the least connected to the product team.

Customer Support works in Zendesk, Intercom, or Freshdesk. Every complaint, every workaround, every "this is broken" message from real users is sitting there. Waiting. Mostly ignored by product until something breaks badly enough.

Data / Analytics stores everything in Snowflake, BigQuery, dbt, and visualises in Tableau, Looker, or Metabase. They have answers to questions nobody has asked yet.

Finance runs on Excel. Always. Maybe SAP or NetSuite if the company is grown up. Budget models, ROI forecasts, headcount plans — in spreadsheets with 47 tabs.

Legal / Compliance uses SharePoint, internal wikis, or just… email threads. Contracts, compliance docs, policy guidelines live here. Usually in a folder structure designed in 2014.

Exec / Leadership consumes knowledge through dashboards (Tableau, Looker), slide decks (PowerPoint, Google Slides), and Slack. They don't go looking for knowledge — knowledge needs to come to them, formatted nicely, in under 5 slides.

Customers leave their knowledge in Zendesk tickets, App Store reviews, Typeform surveys, NPS responses, and UserVoice requests. This is the most honest knowledge in the whole organisation. It also has the longest journey to actually influence anything.

The brutal reality is this: 36% of organisations use three or more knowledge management tools, and 31% aren't even sure how many tools they have in place. Most knowledge doesn't flow — it pools. Each team builds their own lake, and crossing between them requires either a very motivated person or a very painful incident.

And here's the uncomfortable truth that the diagram politely hides: most of these tools don't talk to each other. The product manager writes a PRD in Confluence. The engineer closes the Jira ticket. The sales rep logs the customer objection in Salesforce. The analyst sees the drop in Amplitude. And nobody connects those four dots — because there is no system that does it automatically. Someone has to care enough to do it manually. That someone is usually called "the one person who actually reads everything," and they're always slightly burned out.

The tools are fine. The connections between them — that's where knowledge goes to die.

Ok, and now let's talk about being AI native…

Section 3 — So you want AI to help. Let's see what it's actually working with.​

Here is where it gets interesting. And by interesting I mean a little painful.

Let's take a developer. Modern, senior, not afraid of AI tools. He opens Cursor or uses Claude Code, connects MCP to Jira, pulls the ticket, connects MCP to GitHub, creates the PR. Doesn't even open IDE. Impressive, right? He's telling everyone in the Slack channel he's fully AI native now.

But wait. What happens when the ticket says "implement feature BBB according to the architecture"? AI goes to find the architecture. Where is it? In Miro. Does Cursor have MCP for Miro? Maybe. Does the diagram have enough context written in it or it's just boxes and arrows that only the architect who drew it at midnight understands? Almost certainly the second option.

So the developer copies the diagram, pastes it into Claude. Then remembers there's an HLD somewhere in Confluence. Finds it. It's from 2022. Pastes it anyway. Then the product requirement mentions a shared library. Developer goes to find the README. It's three lines long and the last commit was 14 months ago. Pastes it too.

Now Claude has a context window full of contradictory, outdated, and half-finished information. And here's the thing — even if you have a model with a million token context window, more tokens doesn't mean better results. Research measured 18 different LLMs and found that "models do not use their context uniformly — performance grows increasingly unreliable as input length grows." Basically you're not giving AI more knowledge, you're giving it more noise to get lost in.

There's even a name for this now. Context rot. When an agent lacks good institutional knowledge, it enters a vicious cycle — guess, fail, get corrected, retry. Each iteration fills the context window with more garbage and degrades reasoning further. The DORA 2025 report documented this across the industry: despite 90% AI tool adoption, there was no clear link between adoption and reduction in developer friction or burnout. Developers went faster individually but teams didn't deliver faster.

And that's the developer case. A relatively structured job with tickets and PRs and code.

Now let's look at the architect. An architect needs to design a system for feature BBB. To do this properly, he needs to know: what systems already exist, what their limitations are, what shared libraries are available, what the compliance requirements are, what similar decisions were made before and why, what the team owning Service X can actually support, and what the data model looks like today versus what the PRD assumes. That's at least six different sources of truth. Some of them are in Confluence. Some are in someone's head. Some of the Confluence pages are outdated. Some of the heads have left the company.

Can AI help here? Absolutely. But only if all this information is actually accessible, structured, and trustworthy. If you ask AI to design an architecture based on garbage inputs, you get a beautiful, well-written, completely wrong architecture. And then engineers build it. And then you spend six months wondering why it doesn't work.

So no. Just having AI tools is not being AI native. You're just spending more on tokens while doing the same amount of manual context management as before.

Section 4 — Half the problem: cleaning what you already have​

Here's the uncomfortable reality. Before you can think about making AI work with your knowledge, you need to deal with the knowledge you already have. And most of it is, let's be honest, a mess.

I've worked in more than 15 companies over 25 years. Startups, enterprises, everything in between. The one constant is that everyone has a knowledge management problem. Everyone knows it. Everyone has tried to fix it at least twice. And somehow there are always five tools running in parallel, three Confluence spaces nobody maintains, and a Wiki page titled "Current Architecture" that describes a system that was replaced in 2021.

So before you index anything into your shiny new knowledge graph, you need to sort what's actually worth indexing. Here's how I think about it.

Production code = ground truth. If a service is running in production right now, that's reality. That's a 100 trust score. Whatever documentation says about it doesn't matter — the code is what it is. If the docs say the service uses PostgreSQL and the code says MongoDB, the code wins. Always.

Closed tickets (epics and stories) = high trust. A ticket that went through definition, development, review, and was marked done — that's a record of something that actually happened. Not bugs, not subtasks, those are too granular and noisy. But a properly closed epic or story is a meaningful, trustworthy unit of organizational knowledge.

Passing test plans = medium trust. Tests that run regularly and consistently pass reflect how the system actually behaves. Tests that are skipped, failing, or haven't run in months? Those tell you something too — but not what the system does. They tell you what someone hoped the system would do at some point.

Wiki and Confluence pages = verify before trusting. This is where it gets messy. A wiki page has no inherent trust signal. It might have been written yesterday by a senior engineer who just redesigned the whole system. Or it might have been written in 2019 by an intern who left a week later. You can't tell from the content alone.

How do you filter? A few signals help. When was it last edited, and by whom? Does it reference services or features that still exist? Are there links in it that still work? Does the code referenced in it actually match what's in the repo? These aren't perfect filters but they're good enough to categorize a page as probably current, probably stale, or definitely dead.

Here's a practical heuristic: if a Confluence page hasn't been touched in 18 months and describes something that should change more often than that — like an API contract, a deployment process, or a data model — treat it as stale by default. Require a human to verify before it gets indexed.

Figma files = almost unindexable without effort. Most Figma links in PRDs or epics have no description next to them. Just a URL. So you have a link that points to a specific frame, in a file that may have been renamed, in a team that may have reorganized. And even if you can access the content, how do you know which version is current? Design files have histories, branches, drafts. Without explicit ownership and a "this is the approved version" marker, Figma is just expensive noise in your knowledge graph.

The only way Figma becomes trustworthy knowledge is if teams adopt a discipline: final, approved designs get exported as described components into a system that can be indexed. Not a raw Figma link. A summary, a component name, a version. It's more work. But without it, you're indexing "someone drew something" and that's not knowledge.

README files in shared libraries = depends. If the library has active users, recent commits, and the README was updated in the last release — good signal. If it's a shared library from 2018 that "everyone uses" but nobody touches — that README is documentation for a black box, not for a living system. Treat accordingly.

The hard truth about filtering. You can't fully automate this. You can score content automatically based on age, link health, git activity correlation, and deployment records. But the final call on "is this still true" often requires a human who understands what this piece of the system actually does today. The good news is you only have to do the full audit once. After that, if you build good processes for new knowledge (more on this below), you don't let the mess accumulate again.

The goal of this whole exercise is not to have a perfect knowledge base. That doesn't exist. The goal is to have a knowledge base where AI can say with reasonable confidence "this is probably accurate" versus "this might be outdated, treat with caution." That distinction matters enormously when AI is making architectural recommendations or writing code.

Section 5 — The other half: building new knowledge correctly​

Cleaning the old stuff is hard. Building new knowledge correctly from the start is, surprisingly, harder. Because it requires people to change behavior. And people don't love changing behavior.

Let's follow feature BBB through its lifecycle and ask the simple question: when does something become true?

The product manager writes a PRD. Is that truth? No. It's an intention. A hypothesis. It might change three times before anyone writes a line of code. Indexing it as ground truth at this stage would pollute your knowledge graph with wishes.

The PRD gets approved. Is it truth now? Getting warmer. It's a committed intention. But the implementation might still diverge. Things get discovered. APIs turn out to have different limitations than expected. The design gets revised. The scope gets cut.

The feature gets built and deployed to staging. Is the HLD truth now? Partially. The high-level design reflects something real but the details are still in flux. API contracts might still be changing. Edge cases are being discovered.

The feature goes to production. Now we're talking. The code is truth. The closed epic is truth. The passing tests are truth. The architecture as-implemented is truth — not the HLD as written, but the HLD corrected by whatever actually got built.

So the right answer to "when should we index this" is not a single moment. It's a staged process:

• PRD approved → index as intention with low trust score, tagged "in progress"
• Development starts → HLD and architecture docs indexed as design, medium trust, mutable
• Feature released to production → all related knowledge promoted to verified, high trust, code becomes the arbiter of any conflicts
• Six months in production with no major issues → treated as stable knowledge, used confidently in future architecture decisions

This sounds obvious when you write it down. But almost no company does it. They either index everything all the time (chaos) or nothing (ignorance). The middle path — staged trust elevation — is what actually works.

The other critical part of building new knowledge is making it someone's responsibility. Not "everyone's responsibility." Everyone's responsibility is nobody's responsibility. You need someone — a role, a ritual, a checkpoint — that ensures knowledge gets captured correctly at each lifecycle gate.

In practice this looks like: no epic closes unless the ADR is written. No architecture review sign-off unless the HLD is updated to reflect what was actually decided. No production release unless the README of any affected library is updated. These aren't bureaucratic checkboxes. They're the price of admission for AI native operations. If you skip them, you're back to copy-pasting context by hand.

Section 6 — The temp memory idea, and why it's actually the most interesting part​

Ok so here's the idea I've been thinking about and I haven't seen anyone describe it quite this way.

What if a feature had its own memory?

Not a document. Not a Jira epic. A living, append-only knowledge context that follows feature BBB from the moment it's conceived to the moment it ships — and then gets promoted into the permanent knowledge graph.

Think of it like a construction site. When you're building, you have temporary scaffolding, work-in-progress materials, partially completed structures. You don't put scaffolding in the building's official blueprints. But the scaffolding is real and necessary while you're building. When construction is done, you take down the scaffolding, document the actual building, and file the final blueprints.

Feature memory works the same way. From day one of feature BBB, there's a dedicated knowledge container. Every relevant artifact gets appended to it:

• PRD created → appended
• Architecture diagrams → appended with links and versions
• ADR written → appended
• API contract defined → appended
• Compliance check done → appended with outcome
• Test plan created → appended
• PRD updated (version 2) → appended, old version marked superseded
• API contract changed during development → appended, old version marked superseded

The key word is appended. Nothing gets deleted. Everything gets timestamped. The memory always knows what was true when, and what superseded what. This is temporal knowledge — not just "what is the API contract" but "what was the API contract on March 15th when we made this architectural decision."

There's actually a real framework that works exactly like this. Graphiti, built by Zep AI, implements temporally-aware knowledge graphs where facts have validity windows. When something changes, old facts are invalidated — not deleted — and the new fact takes over. You can query what's true now, or what was true at any point in time. That's exactly what feature memory needs.

When feature BBB ships to production, the temp memory doesn't disappear. It gets promoted. A summarization pass runs — probably AI-assisted — that distills the key decisions, the final architecture, the API contracts as-implemented, and the lessons learned. This summary goes into the main knowledge graph as a verified, high-trust node. The full history stays accessible if you need to trace why a decision was made, but the promoted summary is what future architects and developers query.

Now the sync question. This is the hard part and I'm not going to pretend it's solved.

If the PRD lives in Confluence and the product manager updates it, how does the feature memory know? If the Figma design gets revised, how does the memory update? If a developer changes an API contract in code, how does that propagate back?

There are a few approaches and none of them is perfect:

Webhook-based sync. Every time a relevant document changes in Confluence, Jira, GitHub, Figma — a webhook fires, the change gets appended to the feature memory. Works in theory. Requires every tool to support webhooks (most do), requires someone to set up the integrations, and requires good document-to-feature tagging so the webhook knows which feature memory to update.

Scheduled polling with change detection. A background process checks for changes in linked documents every few hours. Less real-time but simpler to implement. Good enough for documents that don't change frequently, like architecture docs.

Human checkpoints. At each lifecycle gate (PRD approval, architecture review, staging release, production release), a checklist requires the relevant actor to confirm "all changes are reflected in the feature memory." Manual, but forces accountability.

AI-assisted monitoring. An AI agent watches for semantic changes in source documents and flags them. "The API contract in Confluence now differs from what's indexed in feature BBB memory — please review." This is the most interesting option and it's technically feasible today with the right tooling. It's also the one nobody has fully shipped in a production company context yet.

My honest take: start with webhooks plus human checkpoints at gates. Don't try to automate everything on day one. The discipline of "before we close this epic, let's verify feature memory is current" is more valuable than perfect automation that nobody trusts.

Section 7 — So what does AI native actually look like?​

Let's close with the question we started with. What does it actually mean to be AI native?

It's not using Cursor. It's not having Claude write your PRDs. It's not building agents for every department. Those are tools. Tools don't make you AI native.

AI native means your knowledge is structured, trusted, and accessible — to AI — at every step of your product lifecycle. Without a human manually bridging the gap.

Here's what that actually looks like in practice:

When a product manager starts working on feature BBB, they spin up a feature knowledge context. Every artifact they create — research, competitive analysis, PRD — gets indexed immediately, tagged, and linked to relevant existing knowledge in the graph. AI helps them at this stage by surfacing related past features, relevant compliance constraints, and similar architectural decisions the company has made before. Not because someone briefed the AI. Because the knowledge is there.

When the architect starts the HLD, they don't start from a blank page. They query the knowledge graph for the current state of the affected systems, the relevant ADRs, the shared libraries, the team boundaries. AI generates a first-draft HLD that's actually grounded in reality. The architect's job is to review, correct, and approve — not to gather information manually for three days.

When the developer picks up a ticket, their AI agent already has the full feature context. PRD, HLD, API contracts, relevant test cases, coding conventions for this codebase. The developer describes what they want to build. The agent builds it with full awareness of how it fits into the system. No copy-pasting. No "let me find that Confluence page."

When QA runs tests, the results feed back into the feature memory automatically. Failing tests are flagged. The feature memory now contains not just what was intended but what was verified.

When the feature ships to production, the knowledge graph gets updated. The promoted summary is there for the next person who needs to build something on top of this. The architectural decisions are recorded. The trade-offs are documented. The lessons learned are captured.

And six months later, when a new developer joins the team and asks "how does feature BBB work and why was it built this way" — the answer exists. Not in someone's head. In the graph.

That's AI native.

Is this utopia? A little bit. But here's the thing — none of this requires technology that doesn't exist. GraphRAG is real. Temporal knowledge graphs are real. Webhook integrations are real. The technology is ready. What's missing in most companies is the discipline, the process design, and the cultural understanding that knowledge management is not a nice-to-have. It's the foundation everything else is built on.

You can spend a million dollars on AI tools. You can give every developer a Cursor subscription and every product manager a Claude account. And if your knowledge is siloed, outdated, and inaccessible to AI — you'll get faster individual contributors who still work in an organisationally slow company. You'll have AI-assisted outputs built on garbage inputs.

The companies that figure this out first — the ones that treat their knowledge graph as a first-class engineering concern, that build discipline around it, that make it the connective tissue between every actor and every lifecycle stage — those are the ones that will actually benefit from AI at scale.

Everyone else is just buying expensive autocomplete.

Organizations are shipping code faster than ever. They're also forgetting faster than ever. AI agents write features in hours, but six months later, no one can explain why the system looks the way it does. The code works. The tests pass. But the story is gone.

Originally published on Medium.

It came up in a weekly review. The VP of Engineering asked a simple question:

"Who owns billing-orchestrator-service?"

Silence. People glanced at each other. Someone dug through Jira, then GitHub — and found only commits labeled agent-generated-2024-05-12. Eventually an engineer said it out loud:

"The AI built most of that."

The service that moved money in and out of the company didn't have a clear owner, a clear history, or a clear story. It existed. It mostly worked. But no one could explain why it looked the way it did.

That's AI amnesia.

AI Didn't Just Replace Developers — It Replaced Memory​

From outside, it looks simple: "AI is replacing developers." Up close, it's messier.

Companies lean into automation. AI agents write code. AI handles support. AI makes decisions. The first few months look great. Charts go up, tickets close faster, slides get shinier.

Then reality hits.

Take Klarna. They pushed hard into AI customer support. The CEO celebrated replacing people's jobs. Then customers with complex issues got stuck in chatbot loops. Nuance turned into canned answers. Frustration grew.

The story changed fast: "we're making sure you can reach a human." Employees got reassigned back to support.

Google laid off engineers. Then they needed them back. As the AI race heated up, they rehired "boomerang" employees — people they'd let go — for their knowledge of systems and culture.

There's that viral founder: "I fired my dev team and replaced them with AI." Internet fame followed. Months later, he was hiring developers on LinkedIn.

Call it what you want. The pattern is clear: code without understanding is a time bomb.

These Organizations Underestimated Human Memory​

AI generates outputs. But those outputs don't come with intent, rationale, or shared understanding. You still need someone who can answer:

• Why is it built this way?
• What did we try before?
• What must never happen again?

When those answers evaporate, you lose the ability to move.

The Same Pattern in Engineering​

Picture an org that went all-in on AI dev agents.

At first, it felt easy. Drop in a PRD, write prompts, and agents created services, wiring, tests, docs. Humans reviewed "for sanity," but reviews got lighter. Hard to argue with green tests and a happy product team.

Six months later, the mood shifts. A service depends on three other services in ways no one can explain. A config flag looks dangerous, but no one knows why it exists. A migration script looks alien. Every change becomes a gamble.

First comes drift: small shortcuts, missing ADRs, half-written docs. Then opacity: you can't explain your own architecture without a week of archaeology. Then fear: people avoid critical areas. Every incident feels like surgery in the dark.

By collapse, you have two options: hire senior engineers to reverse-engineer the system, or rewrite it.

The code "works" most of the time. The AI shipped features. What collapsed was the shared mental model of how everything fits together.

Software isn't just code. It's a stack of memory:

• Product intent and constraints
• Architectural decisions and tradeoffs
• Invariants that must never break
• History of past incidents
• Who understands this well enough to touch it

AI contributes code. By default, it doesn't preserve the ecosystem.

That's the problem.

Give AI (and Humans) Real Long-Term Memory​

The fix: capture institutional memory in a structured way.

Build a Knowledge Graph. Use GraphRAG to give humans and agents access to it.

Here's how it works. Every PRD, ADR, PR, release, incident, and postmortem becomes a node. Relationships become edges. The graph is backed by an archive (the original text), a search index, and a summary layer for token limits.

When an AI agent implements a change, it doesn't start from "here's some code, guess what it means." It starts from "here's the chain of decisions and events that led to this code."

Why GraphRAG? Traditional RAG returns "chunks of text that look similar to my query." That works for local details. Not for questions like:

• How did we go from the original PRD to last week's incident?
• What decisions have we made about this database, and what went wrong?

GraphRAG works at the level of entities, relationships, and clusters. It doesn't just retrieve text — it walks and summarizes neighborhoods of the graph. You get the story around a piece of code, not just a doc that shares some words with your query.

But this only works if you treat it as a discipline, not just storage.

Building a Memory System, Not Just a Database​

A real long-term memory system has two sides: what you store, and how you behave.

On the storage side, you keep an immutable archive of everything that matters: PRDs, ADRs, PR discussions, release notes, incident reports, monitoring summaries. You put a hybrid search index on top so you can find things both by exact IDs and by meaning. You extract entities and relationships to build your knowledge graph: which PRDs led to which ADRs, which ADRs governed which components, which PRs implemented them, which releases shipped them, which incidents were linked to them.

You also build a layer of summaries at different resolutions. Each PRD has a short summary. Each component has a description that includes what it does, which invariants it respects, and what it depends on. Each release has a clear description of what changed and what you expected. Each incident tells the story of what broke and what you learned.

That's the cold part of the system: the pipes, the storage, the indexes.

The hot part is how you change your definition of done.

"Done" no longer means "tests passed, PR merged." It means "this change is visible in our memory."

A change without an ADR is not done. A risky release without proper notes is not done. An incident that doesn't produce new invariants and updated docs is not done.

The system enforces this. Open a PR that changes a core data model without linking to a PRD or ADR? Blocked. Ship a release touching a critical service without describing expected impact and dashboards? Pipeline complains. Close a major incident without writing what you learned? Process refuses.

Memory is wired into how work flows.

Walking One Feature Through the Loop​

Follow a single feature from idea to incident.

Your PM drops a PRD for "Instant Payouts v2." Clear goals, non-goals, constraints, SLOs. Rollout strategy and success metrics. The PRD becomes a node.

An AI assistant reads it and proposes a plan: which ADRs are relevant, which incidents to re-read, which services will be affected, where new decisions are needed. You adjust the plan, argue with it, correct it, approve it. The plan links back to the PRD and forward to components and risks.

Next comes the ADR. You write — or co-write with the agent — a focused document:

• How you'll handle balance caching to hit latency targets
• What failure modes you considered
• Why you rejected a simpler approach
• What risks you're accepting

Link the ADR back to the PRD and forward to the components that will implement it.

Then code. Agents generate the implementation, but not in a vacuum. For each PR, they see the PRD, the plan, the ADR, and any incidents that touched the same services. They propose changes in that context. Each PR declares what it's doing in human language and links to the artifacts.

Releases roll out with PRs attached, descriptions of what's expected, which dashboards matter. Monitoring episodes get summarized and linked back to suspected releases and components. If something breaks, an incident is declared. Timeline, root cause, fix get captured. New invariants are born: "never do X again," "always verify Y before Z."

Invariants become first-class citizens. Linked to the incidents that birthed them, the ADRs that codified them, the components that must respect them.

The loop looks something like this:

Now imagine someone, six months later, wants to change a small function deep inside payouts-core. In a normal "AI wrote most of this" environment, they'd be guessing. In your environment, the agent begins by pulling the decision chain from the knowledge graph: the original PRD, the ADR that justified this odd-looking logic, the incident from two months ago where you accidentally double-paid a thousand users, the invariant that says "never attempt payout if ledger state is older than five minutes."

This doesn't magically guarantee safety. But it radically changes the starting point. The agent is no longer an amnesiac autocomplete engine. It's closer to a junior engineer who has just spent a day reading the history of this subsystem.

The same applies to humans. When a new hire asks, "Why is it built this way?", you don't point them to a ten-thousand-line file and a graveyard of old Slack threads. You give them the story in a structured way: here is the PRD, here are the key decisions, here is when it blew up, here is what we learned.

What This Fixes — and What It Doesn't​

A GraphRAG-backed knowledge graph with real governance eliminates categories of pain.

You stop re-litigating old decisions because the reasoning is recorded. You reduce repeated mistakes because incidents become part of context for future work. You avoid shipping risk-blind changes because agents and humans see which invariants and incidents are attached to the code.

Most importantly, you attack the specific AI failure mode that matters: not "the model hallucinates," but "we built a working system no one understands." This doesn't stop models from being wrong. But it makes it harder for them to be confidently wrong about the history of your own organization.

But there are limits.

Retrieval is not correctness. A model can fetch the right docs and still misapply the lessons. The graph can be wrong if extraction pipelines are noisy or docs are stale. Runtime reality can diverge from docs. A system might claim to be idempotent while production traces tell a different story.

The most dangerous failure: documentation theater. If AI writes the code and the "decisions" about the code without human oversight, you risk a beautiful, coherent, fictional history. It will look polished. It will be persuasive. It may be wrong where it matters most.

Governance is not optional. The graph needs human-validated edges. ADRs need actual authors who lived the tradeoffs. Incidents need to be painful enough that people care about capturing lessons. CI needs to enforce that changes are anchored in memory.

Without this, your knowledge graph becomes a museum: pretty, disconnected from life.

The Point​

The idea is simple.

Give your organization a long-term memory that both humans and AI can see and use. Make that memory structural, not optional. Connect what you meant to build, what you actually built, what broke, and what you swore you'd never do again.

If you pull it off, you don't choose between "AI everywhere, chaos later" and "no AI, we're scared." You get AI that moves fast inside a system that still remembers.

The next time the VP asks, "Who owns billing-orchestrator and why does it behave like this?", you don't get silence and blinking Zoom faces.

You get a story. A graph walk. The decisions, the incidents, the invariants, and a human who can say:

"Here's what this is, here's how we got here, and here's how we can change it without burning the house down."

AI generates code. Long-term memory makes sure it's generating a system you can still live in a year from now.