Coder Legion - Recent posts tagged protocols

ProtocolAI and GrammarAI: Giving AI a Language Software Can Actually Own

Tue, 29 Sep 2026 22:13:13 +0000

There is a particular problem that keeps appearing as I build the architecture for The Singularity Workshop.

It starts with something that sounds almost trivial:

How does software communicate with an AI when the software already knows what its world means?

An LLM is very good at language.

It can interpret a request, generate possibilities, describe relationships, and produce something that looks structurally correct.

But there is a boundary where the application has to take over.

The application needs to know exactly what something refers to.

And then it needs to know how those things may be connected.

That is where two small packages have emerged:

ProtocolAI — the WHAT
GrammarAI — the HOW

They are deliberately separate.

And neither one is the AI.

The Problem Starts With Probability

An LLM operates in a probabilistic space.

That is not a criticism. It is the nature of the technology.

Given some context, the model produces a candidate response.

That candidate may be exactly what we wanted.

It may also be something new.

Or something that looks familiar but does not actually identify the same object the application already knows.

Imagine an application that already knows three people:

Bob
Jane
Sara

The application has meaning attached to those names.

The model does not own that meaning.

It can produce "Bob".

But the application needs to turn that representation into something deterministic.

That is the boundary ProtocolAI explores.

probabilistic language
        |
        v
     candidate
        |
        v
    ProtocolAI
        |
    +---+---+
    |       |
  known   unknown
    |       |
    v       v
 integer   literal
    |       |
    +---+---+
        |
        v
application-owned identity

The model proposes.

The application decides.

ProtocolAI provides the semantic address space between those two worlds.

ProtocolAI: The WHAT

The core idea behind ProtocolAI is surprisingly small.

A protocol owns a vocabulary.

For example:

[1001] People

[2001] bobId  = "Bob"
[2002] janeId = "Jane"
[2003] saraId = "Sara"

Now the application has an address space.

"Bob"   -> [2001]
"Jane"  -> [2002]
"Sara"  -> [2003]

The integer is not the meaning.

It is the address of the meaning.

That distinction is important.

ProtocolAI does not replace the domain object.

It does not become the database.

It does not become the authority that decides what Bob is allowed to do.

It simply establishes a deterministic identity that the application owns.

The Literal Escape Hatch

There is another important detail.

What happens when the model produces something the application does not already know?

Suppose the vocabulary contains:

[2001] Bob
[2002] Jane

and the model produces:

"Amelia"

The protocol should not have to pretend Amelia already exists.

So ProtocolAI preserves the literal.

[2001] [2002] "Amelia"

That gives the host a choice.

The host can decide whether Amelia should be:

created;
registered;
rejected;
authorized;
deferred;
or otherwise handled.

That is a much more interesting boundary than simply forcing everything into a closed enumeration.

Known things become references.

Unknown things remain visible as unknown.

This Is Not Just About Compression

It would be easy to look at integer identities and conclude that this is merely an optimization.

Smaller values.

Smaller payloads.

Faster lookup.

Those may eventually be useful properties.

But that is not the fundamental idea.

The more important separation is:

Meaning
   |
   v
Identity
   |
   v
Representation

Consider:

Meaning:        Bob
Symbol name:    bobId
Symbol ID:      2001
Protocol ID:    1001
Payload form:   [2001]

The application already owns the meaning.

ProtocolAI gives that meaning an explicit address.

That address can then survive across interactions.

Prompt
"Bob"
   |
   v
[2001]
   |
   v
Response
[2001]
   |
   v
Next interaction
[2001]

The model does not have to repeatedly rediscover that two strings refer to the same application-owned identity.

Again, that is an architectural direction rather than a claim that integer identities automatically make an LLM reason better.

The point is that the application has a semantic address space.

And Then I Ran Into the Next Problem

A vocabulary is useful.

But a vocabulary is not a language.

Knowing:

[2001] Bob
[2002] Jane

does not tell us how those identities may be arranged.

We need another layer.

Something has to describe relationships such as:

this kind of thing
    |
    +--> may contain this
    |
    +--> may reference that
    |
    +--> may be followed by another structure

That is where GrammarAI enters.

GrammarAI: The HOW

GrammarAI takes the identities supplied by ProtocolAI and gives them a structural language.

The distinction is intentionally simple:

ProtocolAI defines the WHAT. GrammarAI defines the HOW.

For example:

ProtocolAI

[1001] People

[2001] Bob
[2002] Jane

GrammarAI can define a structure that references those identities:

[4001] -> [1001:2001]
[4001] -> [1001:2002]

Now we have two different owners.

[1001:2001]
    |
    +--> ProtocolAI owns the meaning

[4001]
    |
    +--> GrammarAI owns the structural position

That separation is deliberate.

GrammarAI does not copy Bob into itself.

It references the protocol that owns Bob.

A Grammar Is a Relationship System

This is the part I find particularly interesting.

A grammar is not another dictionary.

It is a relationship system.

It can say:

Grammar nonterminal
       |
       v
     [4001]
       |
       +----> [1001:2001]
       |
       +----> [1001:2002]

The grammar owns the relationship.

The protocol owns the thing being referenced.

That gives us a clean composition boundary.

Protocol A
    |
    +-- symbols

Protocol B
    |
    +-- symbols

       \       /
        \     /
         \   /
        Grammar
           |
           +-- structure
           +-- relationships
           +-- references

The grammar connects things without becoming the owner of those things.

Why Integer-Backed Structure?

There is another common thread between the two packages.

Both are self-defining.

A GrammarAI definition has its own identity:

[3001] Greeting

It has a start symbol:

start = [4001]

And it has production rules:

[5001] [4001] -> [1001:2001]
[5002] [4001] -> [1001:2002]

That means the grammar itself can become a piece of data.

It can eventually be:

described;
serialized;
compared;
versioned;
generated;
visualized;
translated;
supplied to another composition layer.

The grammar does not need to know which of those things will happen.

That is the point of keeping it small.

The AI Still Isn't the Authority

This is probably the most important part of the architecture.

The LLM does not become the owner of the protocol.

The LLM does not become the owner of the grammar.

And the LLM does not become the application's execution authority.

The flow is closer to:

              LLM
               |
          probabilistic
            candidate
               |
               v
          ProtocolAI
             WHAT
               |
               v
           GrammarAI
              HOW
               |
               v
        host validation
               |
               v
       application decision
               |
               v
       deterministic state

The model participates.

It does not rule the system.

That distinction becomes increasingly important as AI systems begin interacting with real applications rather than simply generating text.

This Is the Same Boundary I Keep Finding Elsewhere

Consider a reservation system.

User A requests the last available table.

The centralized authority accepts the reservation.

Users B through K arrive almost immediately afterward.

The system does not need to tell User K:

Failure.

That is technically accurate but semantically terrible.

The actual state is:

You cannot acquire the resource right now.

So the system can return something closer to:

Resource unavailable.

You are currently #10 in the waiting queue.
There are 9 requests ahead of you.

That is an inability, not necessarily a failure.

The system has preserved useful information about the state of the world.

And that is the kind of distinction these AI packages are trying to preserve as well.

An LLM can produce a candidate.

ProtocolAI determines whether that candidate corresponds to a known application identity.

GrammarAI determines whether that identity participates in a valid structure.

The host then decides what that structure means operationally.

At every step, we preserve the distinction between:

what was proposed
what is known
what is structurally valid
what is currently possible
what the application actually decides to do

That is much more useful than collapsing everything into true or false.

ProtocolAI and GrammarAI Are Deliberately Not an AI Framework

This is where the package boundaries become important.

ProtocolAI is not:

an LLM;
an AI provider;
a prompt framework;
a schema validator;
a database;
a grammar compiler;
a command executor;
a GUI framework;
a MicroBundle host.

GrammarAI is not:

an LLM client;
model selection;
tokenization;
inference;
prompt transport;
protocol vocabulary ownership;
MicroBundle hosting;
REST/OpenAPI;
GUI manifestation;
tool execution.

That list may look like a lot of things to leave out.

That is intentional.

The packages are supposed to provide semantic infrastructure, not become another giant AI framework.

The Exchange Layer Comes Later

ProtocolAI already describes an interesting future boundary for AI interaction.

The same semantic exchange should eventually work through either:

             AI Exchange
                 |
        +--------+--------+
        |                 |
    Clipboard         Provider
        |              Adapter
        |                 |
        +--------+--------+
                 |
                LLM

Clipboard interaction is not treated as a second protocol.

It is simply another transport.

A developer could extract:

Protocol
Grammar
Context
Request

copy that into an LLM, receive a response, and paste it back.

A connected provider could perform the same semantic exchange programmatically.

The transport changes.

The semantic boundary does not.

That is an important distinction.

Context Is Not Authority

An AI exchange might eventually contain a substantial amount of information:

current Experience
selected objects
available commands
protocol descriptions
grammar definitions
current state
previous interactions
host capabilities

But none of that means the model has authority.

The intended boundary remains:

MODEL OUTPUT
     |
     v
parse / validate
     |
     v
ProtocolAI resolution
     |
     v
host policy
     |
 +---+---+---+---+
 |   |   |   |   |
accept reject clarify create execute

The model proposes.

The host decides.

ProtocolAI makes owned meaning addressable.

GrammarAI makes the relationships between those meanings describable.

And This Is Where the Larger Workshop Architecture Appears

The two packages are small individually.

But together they establish another layer in the larger architecture I have been building.

Domain meaning
      |
      v
ProtocolAI
    WHAT
      |
      v
GrammarAI
    HOW
      |
      v
AI / provider adapter
      |
      v
Host
      |
      v
FSM / GUI / Experience

And eventually, those capabilities can participate in the MicroBundle architecture.

That means the AI layer does not have to become a special universe disconnected from the rest of the system.

It can become another collection of capabilities that the host can compose.

The Interesting Part Is the Separation

There is a temptation when building AI software to put everything in one place.

The model client.

The prompts.

The schemas.

The grammar.

The commands.

The domain objects.

The execution engine.

The UI.

The credentials.

The networking.

Eventually you have an enormous framework that knows everything about everything.

I am deliberately going in the other direction.

ProtocolAI knows about semantic identity.

GrammarAI knows about semantic structure.

The host knows about execution.

The provider adapter knows about transport.

The application knows about meaning and authority.

That makes the pieces composable.

Where the Alpha Actually Stands

These packages are intentionally early.

ProtocolAI 0.1.0-alpha.2 currently establishes:

self-defining integer-backed vocabularies;
protocol-qualified identity;
known-value encoding;
literal preservation;
deterministic descriptions;
ordered mixed payloads;
payload validation;
mixed reference/literal resolution.

GrammarAI 0.1.0-alpha.1 currently establishes:

grammar identity;
integer start symbols;
integer nonterminals;
ordered production rules;
external ProtocolAI references;
deterministic self-description;
validation of referenced nonterminals.

Neither package currently implements the entire AI pipeline.

And that is okay.

The unanswered questions are actually interesting architectural questions.

For example:

Who allocates new symbol IDs?

How do identities persist?

How are protocols versioned?

How are protocols negotiated?

How are grammars versioned?

How are recursive productions handled?

How does an abstract grammar become a provider-specific constraint?

How do we validate generated model output?

How does a semantic artifact become executable behavior?

Those questions should be solved by the architecture.

They should not be hidden inside convenience APIs simply because the API would look nicer.

The Bigger Experiment

What I am really exploring here is a progression.

human / domain language
          |
          v
    self-defining lexicon
          |
          v
     integer identity
          |
          v
    grammar / structure
          |
          v
       protocol
          |
          v
     tool execution
          |
          v
       experience

ProtocolAI is the first semantic compression boundary.

GrammarAI is the next structural boundary.

Neither is trying to replace human language.

Neither is trying to make an LLM deterministic.

Instead, they give software something it has always needed:

a precise address space for meanings that the software itself owns.

And once those meanings have addresses, and those addresses have structure, we have something much more interesting than an AI prompt.

We have the beginning of a language that the application can actually own.

The Current Workshop Stack

The current direction now looks something like this:

                    LLM
                     |
              probability
                     |
                     v
               ProtocolAI
                  WHAT
                     |
                     v
                GrammarAI
                   HOW
                     |
                     v
             AI / Host Adapter
                     |
                     v
                  Host
                     |
                     v
                FSM_COS
                     |
              MicroBundles
                     |
                     v
              RuntimeAssembly
                     |
                     v
            GUI / Experience
                     |
                     v
             Digital Reality

The interesting part is that the model remains at the edge.

The application owns the center.

That is where I want the architecture to live.

Resources

Support The Singularity Workshop

If this work is useful to you, and you'd like to help keep The Singularity Workshop moving, you can support its continued development:

Patreon: Support The Singularity Workshop
PayPal: Make a donation

Every bit of support helps provide more time and resources for building, testing, documenting, and publishing the architecture.

The Singularity Workshop — Tools for the curious, the bold, and the systemically inclined.
Because state shouldn't be a mess.

MCP's 2026-07-28 Revision: a 12-Month Deprecation Policy and Six Removals in One Release

Thu, 03 Sep 2026 00:30:20 +0000

The Model Context Protocol's 2026-07-28 revision adopted a formal deprecation policy with a twelve-month minimum window, and the maintainers led with it. The release post promises "a formal deprecation policy with a twelve-month minimum window so you can plan upgrades instead of reacting to them." The same revision removes the session header, the initialization handshake, the ping method, the log-level method, the HTTP GET endpoint, stream resumability, and a notification that had existed for exactly one revision. And the registry page that the policy created, listing everything on its way out, ends with a sentence that is true in a way worth reading slowly: "No features have been removed under this policy yet."

Both statements are correct. Understanding how they are both correct is the whole value of this document, so this piece stays inside it. There is no analogy here and no company that lost money. The evidence is one changelog, the policy page it cites, the registry, the release post, and the revision before it, all read section by section with the item numbers given so anyone can check the page in a minute.

What the policy promises, in its own words

The policy page is titled "Feature Lifecycle and Deprecation Policy," adopted through SEP-2596. Its Scope section says what it governs: "This policy governs features of the MCP core specification: protocol messages, capabilities, transports, schema types, and normative behavioral requirements." That sentence matters later, so hold onto it. A protocol message is a feature. A method name is inside the policy's unit, on the policy's own terms.

A feature is in one of three states. Active means it is part of the Current revision. Deprecated means it "remains in the specification but is scheduled for removal," with a documented migration path, and "existing implementations should migrate before the earliest removal date." Removed means it "has been deleted from draft and will be absent from the next Current revision."

The window is defined under "Deprecating a Feature," item 4: the deprecation SEP must specify "the number of months, at least twelve, that the feature must remain Deprecated before it is eligible for removal. The window is measured from the release of the specification revision in which the feature is first marked Deprecated." The feature then "becomes eligible for removal in the first specification revision released as Current on or after the window elapses."

Two more clauses shape what follows. Under "SDKs": "Removal from the specification does not oblige an SDK to drop the feature from releases." And under "Expedited Removal," the twelve-month floor can shrink to ninety days for an active security risk, with a published advisory or documented exploitation.

So the promise is precise. Once a feature is marked Deprecated in a released revision, the specification will keep it for at least twelve months. That is a promise about specification text, counted from a release, per feature.

What the same revision removes

The changelog for 2026-07-28 lists its changes under Major, Minor, Deprecated, Other schema changes, Governance and process updates, and Process changes. The removals sit under Major and Minor. Here they are with their locators.

Major changes, item 1: "Remove protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport."

Major changes, item 2: "Make MCP stateless: remove the initialize/notifications/initialized handshake."

Major changes, item 4: "Replace the HTTP GET endpoint and resources/subscribe/resources/unsubscribe with subscriptions/listen."

Major changes, item 5: "Remove ping, logging/setLevel, and notifications/roots/list_changed."

Major changes, item 9: "Remove SSE stream resumability and message redelivery (the Last-Event-ID header and SSE event IDs) from the Streamable HTTP transport."

Minor changes, item 11: "Remove the notifications/elicitation/complete notification and the elicitationId field of URL mode elicitation requests, both introduced in 2025-11-25."

Six entries, counted by reading the page rather than by any script; the item numbers above are the reproduction. Item 4 is a replacement rather than a bare deletion, and the changelog's own verb is kept here for that reason. The other five say "remove."

None of the six went through a twelve-month window, and the reason is on the same page. Governance and process updates, item 1: "Adopt a specification feature lifecycle and deprecation policy defining the Active, Deprecated, and Removed feature states, a minimum twelve-month deprecation window, and a registry of deprecated features (SEP-2596)." The policy and the removals arrived in one release. A policy that counts its window from a release cannot have counted anything before that release.

The registry says the same thing from the other side. Its Removed section reads, in full: "No features have been removed under this policy yet. When a Deprecated feature is removed, its row moves to this section with a link to the changelog entry recording the removal." The table is empty because these six removals were made under the older mechanism, the one the versioning guide describes in its first sentence: MCP's version strings "indicate the last date backwards incompatible changes were made." A dated revision is, by definition, where breaking changes go. The lifecycle policy is a second mechanism layered on top of the first, and 2026-07-28 is the release where you can see the seam.

The name on both lists

Under the Deprecated heading, item 1: "Deprecate the Roots, Sampling, and Logging features (SEP-2577). These features remain fully functional during the deprecation window but new implementations should not add support for them." The registry gives all three an earliest removal of "First revision released on or after 2027-07-28." The Logging page itself now opens with a warning box: the feature "remains in the specification for at least twelve months after this revision's release before it becomes eligible for removal."

Now read Major changes, item 5 again. logging/setLevel is removed. Log level "is now set per-request via io.modelcontextprotocol/logLevel in _meta; servers MUST NOT emit notifications/message for requests that did not include this field." The Logging page confirms the new shape: the only protocol message left on it is notifications/message, and the section on requesting log messages says the same MUST NOT.

Logging is the name on both lists. The feature is Deprecated with a twelve-month window. The method a client used to control that feature is gone in the same document, four sections up. Both statements hold, because "remain fully functional" describes the capability, and the capability survived in a new wire form. A client that still sends logging/setLevel is not exercising a deprecated feature. It is sending a method the specification no longer contains.

Roots and Sampling are reshaped the same way. Major changes, item 5 removes notifications/roots/list_changed. Major changes, item 7 introduces the Multi Round-Trip Requests pattern, "which replaces the previous approach of sending server-initiated requests, such as roots/list, sampling/createMessage, or elicitation/create." All three deprecated features keep their twelve months and change their messages in the same revision.

None of this contradicts the policy. Its scope names protocol messages as features, so the maintainers could have marked logging/setLevel Deprecated on its own and given it a window. They chose the feature as the unit and the revision as the tool for its messages. That is a judgment made line by line, not a property of the policy, and it is the thing an implementer reading "fully functional during the deprecation window" will most easily get wrong.

What breaks, exactly

The revision is careful about this, so the essay should be too. The Versioning and Compatibility page defines "modern" versions (2026-07-28 and later, version and capabilities carried in per-request _meta) and "legacy" versions (2025-11-25 and earlier, the initialize handshake), and a "dual-era" implementation that supports both. A server "MAY implement both behaviors."

Its compatibility matrix then states the outcomes. Legacy client, modern server: "Fails." On stdio the server rejects initialize as an unknown method; on HTTP the request lacks the required headers and gets a 400. The row ends with the sentence that answers the question: "Legacy clients have no fall-forward mechanism." Legacy client, dual-era server: "Works. The server answers initialize and serves the client according to the negotiated legacy revision."

So the operative question for a running client is not whether Logging is deprecated. It is which eras the server in front of it serves. Against a dual-era server, the old logging/setLevel call keeps working under the legacy revision for as long as that server chooses to offer it, which the policy's SDK clause explicitly leaves to the SDK. Against a modern-only server, the client fails at initialize, before it ever reaches the method that was removed. The release post says as much in plainer words: "there will be some migration cost, especially for developers that did depend on session identifiers."

The feature that lived for one revision

Minor changes, item 11 carries its own history: notifications/elicitation/complete and elicitationId were "both introduced in 2025-11-25." That is the immediately preceding revision. The 2025-11-25 changelog, Major changes, item 6, is where URL mode elicitation arrived. The feature's entire life ran from one revision to the next.

The prior changelog is worth a second look for the other five. It contains no deprecation, soft-deprecation, or removal warning for sessions, the handshake, ping, logging/setLevel, notifications/roots/list_changed, the GET endpoint, resource subscriptions, or stream resumability. Its Minor changes, items 6 and 7, do the opposite for one of them: they refine SSE polling and resumption, specifying that "resumption always via GET regardless of stream origin" and that "event IDs should encode stream identity." The mechanism was elaborated in November and removed in July.

That claim is scoped to the changelogs. The 2026-07-28 Deprecated section shows the maintainers do track softer notices in specification prose: item 3 reclassifies two includeContext values "soft-deprecated since protocol version 2025-11-25," and item 2 reclassifies the HTTP+SSE transport "deprecated since protocol version 2025-03-26." I did not read every 2025-11-25 specification page for prose-level warnings on the six, so the narrower statement is the one that survives: at the changelog level, none of the six carried notice, and the twelve-month policy could not have governed them in any case.

Two mechanisms, one document

What this revision shows is a protocol running two compatibility mechanisms at once, with different units and different promises.

The dated revision is the older one. Its unit is the whole specification, its promise is the version string, and its tool for continuity is the dual-era server. Breaking changes are what a new date means. The compatibility matrix is that mechanism's documentation.

The feature lifecycle is the newer one. Its unit is the feature, its promise is a floor of twelve months from a release, and its tool for continuity is the registry, which now names 2027-07-28 as the earliest a Current revision can drop Roots, Sampling, or Logging. That is a real commitment, and it did not exist before this release.

The seam between them is where implementers will misread the page. The word "feature" in the Deprecated section and the method names in the Major section are on different lists, and one name sits on both. The policy's scope could have put the method on the protected list. The maintainers put the feature there instead, and reshaped the method under the revision. Nothing in the policy forbids that. Nothing in the policy tells you it happened, either; the changelog does, in two items that do not reference each other.

The practical reading order, then, is the reverse of the release post's. Start with the compatibility matrix and the list of versions a server reports in UnsupportedProtocolVersionError, because that decides whether anything of yours still runs. Read the six removals next, because they are the breaking changes of this date. Read the registry last, for the promises that begin now.

There are things this piece did not check and does not claim. It did not test any SDK's behavior, and the policy says SDK timelines are their own. It did not read the 2025-11-25 specification pages for prose-level deprecation notices, only that revision's changelog. And it has no way to know how many servers will run dual-era for how long, which is the number that decides how much of this an ordinary client will ever feel.

Sourcing notes: every quotation above is from the primary pages named below, with the section and item number as its locator; the count of six removals was made by enumeration of the 2026-07-28 changelog's Major and Minor sections, not by a script, and the locators are the reproduction. The release post's two framing quotes and its migration-cost sentence were read at the post; that 2026-07-28 is the Current revision is stated by the versioning guide ("The current protocol version is 2026-07-28"). Not verified and not asserted: SDK behavior, prose-level notices in the 2025-11-25 specification pages, and the prevalence of dual-era servers.*

Sources

Model Context Protocol, "Key Changes" changelog for the 2026-07-28 revision (Major changes 1, 2, 4, 5, 7, 9; Minor changes 11; Deprecated 1, 2, 3; Governance and process updates 1). https://modelcontextprotocol.io/specification/2026-07-28/changelog
Model Context Protocol, "Feature Lifecycle and Deprecation Policy" (Scope; Feature States; Deprecating a Feature, item 4; SDKs; Expedited Removal), adopted via SEP-2596. https://modelcontextprotocol.io/community/feature-lifecycle
Model Context Protocol, "Deprecated Features" registry for 2026-07-28 (Deprecated table; Removed section). https://modelcontextprotocol.io/specification/2026-07-28/deprecated
Model Context Protocol, "Versioning and Compatibility," 2026-07-28 (Terminology; Backward Compatibility with Initialization-Based Versions; Compatibility Matrix). https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning
Model Context Protocol, "Versioning" guide (first paragraph on version strings; Revisions; Feature States). https://modelcontextprotocol.io/docs/learn/versioning
Model Context Protocol, "Logging" utility page, 2026-07-28 (deprecation warning; Requesting Log Messages; Protocol Messages). https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/logging
Model Context Protocol, "Key Changes" changelog for the 2025-11-25 revision (Major changes 6; Minor changes 6, 7). https://modelcontextprotocol.io/specification/2025-11-25/changelog
David Soria Parra and Den Delimarsky, "The 2026-07-28 Specification," MCP blog, July 28, 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
SEP-2596 (feature lifecycle and deprecation policy) and SEP-2577 (deprecation of Roots, Sampling, and Logging), as cited by the changelog items above. https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596 and https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577

Where a claim like this becomes checkable

Everything above is a reading of pages that can change under you. The reason it can be audited at all is that each claim carries its locator, so a reader can open the same section and disagree. A chain-of-consciousness record does that for an agent's work: what it read, in what order, and what it relied on, kept as evidence rather than recollection.

pip install chain-of-consciousness · npm install chain-of-consciousness

Hosted Chain of Consciousness