Velvet Signal

Inspiration

AI assistants have a strange problem: they can be extremely capable and still be stale.

A person stays current by reading — newspapers, magazines, newsletters, release notes, recipes, cultural coverage, whatever matters to them. An LLM usually does not have an equivalent habit. It may have retrieval, browsing, or memory, but those systems often ask the agent to search only after a question has already been asked.

Velvet Signal asks a different question:

What if your AI could subscribe to publications?

Velvet Signal is a publication for humans and their agents. A person gets a readable issue. Their agent gets a structured context patch containing claims, provenance, scope, expiry, and relationships to older claims. The two read the same publication in different ways.

The WebMCP Challenge made the missing interface obvious. Before WebMCP, the agent could only look at Velvet Signal's page and infer what the publication meant. With WebMCP, the website can explicitly tell the agent what it is allowed to do.

What it does

Velvet Signal publishes topic-specific desks such as Model Watch, The Pantry, Wellbeing, Culture Desk, Maker Edition, and Your People.

Five public desks scout for meaningful changes on an eight-hour schedule. Source packets are treated as untrusted data and used to propose structured issues. Unchanged source packets do not generate a new issue. Every claim carries provenance, scope, confidence, and a validity window.

A publication patch can also describe how new information relates to older information:

• replaces — the newer claim displaces an older one
• narrows — both remain valid, but the newer claim controls a more specific scope
• confirms — independently supported claims remain together
• conflicts — the newer claim controls the shared scope while the older claim stays in history

The important part is that publication does not silently equal memory. A patch remains locked until a person explicitly approves and releases that exact patch.

Why WebMCP is the right interface

A context publication is awkward if an agent has to scrape the page and guess which card is current, which text is provenance, whether a patch has expired, and whether the person actually authorized its use.

WebMCP turns those concepts into an explicit agent-facing interface.

Velvet Signal registers four tools directly from the live page:

• list_velvet_signal_issues — lists the current shelf, patch IDs, scopes, validity windows, and approval state
• inspect_memory_patch — returns the exact claims, provenance, scope, expiry, relationships, and consent state without applying anything
• apply_memory_patch — requests delivery of one exact patch, but returns awaiting_human_consent until a person releases it
• verify_delivery_receipt — verifies that the delivered patch matches its Ed25519-signed receipt and SHA-256 content hash

This means the human UI and the agent interface share the same publication state without forcing either side to imitate the other.

What humans and agents can do together now

A human can browse Velvet Signal like a magazine, decide which topics matter, inspect an issue, and approve a specific patch.

An agent can ask the site for the current issue list, inspect exactly what a patch contains, see whether it is still valid, and request that exact patch without scraping prose or inventing its own interpretation of the page.

The boundary between them is deliberate. If the agent asks for an unreleased patch, Velvet Signal does not treat that as an error and does not silently comply. It returns a structured awaiting_human_consent state with delivered: false and tells the agent to wait for the person. It explicitly tells the agent not to retry in a loop.

After the person clicks Approve & release, Velvet Signal creates the canonical released patch and a signed receipt bound to its exact content hash. A compatible agent can then receive and verify that artifact.

Velvet Signal does not claim to rewrite ChatGPT's hidden or permanent memory. It delivers a portable context artifact. A receiving agent can use it in the current context, while a compatible external memory bridge can store explicitly released patches for later retrieval.

How I implemented WebMCP

The live page detects document.modelContext (with a navigator.modelContext compatibility fallback) and dynamically registers four tools with registerTool().

Read-only operations are marked accordingly. Tool execution returns structured publication data from the same canonical issue catalog used by the human interface. The mutating delivery tool preserves the site's consent model instead of allowing the agent interface to bypass it.

The UI exposes its WebMCP state visibly. When registration succeeds, the page displays WebMCP ready · 4 tools. If the host does not expose WebMCP, it falls back to preview mode rather than pretending tool registration succeeded.

Human consent and signed delivery

Velvet Signal treats agent capability and human authority as separate things.

Subscribing to a desk allows Velvet Signal to propose context; it does not authorize a silent memory write. apply_memory_patch cannot cross that boundary on its own.

When a patch is released, the server returns the exact delivered patch plus an Ed25519-signed receipt containing its SHA-256 hash. Verification checks both the signature and the supplied content, and separately reports whether the patch is still inside its validity window.

The signature proves that Velvet Signal issued a receipt for that exact patch hash. It deliberately does not claim to identify the human approver.

Testing in ChatGPT

I tested the live site in ChatGPT's in-app browser. The page successfully registered its interface and displayed WebMCP ready · 4 tools.

In that host, browser safety review prevented direct invocation of one or more custom page tools. I therefore treat registration, human release, cryptographic delivery, and host permission as four separate checkpoints rather than claiming a blocked host invocation is a successful tool call.

The human consent and signed-receipt path remains fully demonstrable through the live UI. The README documents the exact judge path and the expected wording if a host browser allows registration but blocks direct execution.

Beyond the hackathon: portable memory for local models

Velvet Signal also includes a local Ollama bridge. Explicitly released patches can be stored on the user's machine, resolved against newer replaces / narrows / confirms / conflicts relationships, retrieved semantically or lexically, and injected into the current turn of a local model.

The model does not need its own persistent memory. Velvet Signal becomes the external, auditable ledger.

VS-Bench tests retrieval separately from generation. Development A/B runs with Dolphin 3:8B and Qwen3 4B Instruct both passed all 11 deterministic retrieval checks across eight scenarios, while generation adherence exposed how different small models respond to correct context.

What was new for the WebMCP Challenge

Velvet Signal existed as a publication concept before August 25. The WebMCP work was added during the challenge submission period and meaningfully extended the project from a human-readable publication into an agent-native website.

The challenge work added the four-tool WebMCP interface, explicit registration state in the UI, structured issue and patch inspection for agents, the human-consent response state for unreleased patches, delivery through the existing signed-patch boundary, receipt verification as a page tool, and judge documentation for testing the full flow in WebMCP-capable browsers.

That change is the core of this submission: the page stopped being something an agent merely reads and became a collaborator with a defined vocabulary and authority boundary.

Judge path

Open https://velvetsignal.lol in ChatGPT's in-app browser or Chrome with WebMCP enabled.

1. Confirm the badge reads WebMCP ready · 4 tools.
2. Ask the agent: List the current Velvet Signal issues, inspect pantry-003, and apply it.
3. An unreleased patch should return awaiting_human_consent if the host permits invocation.
4. Open pantry-003 and click Approve & release.
5. Confirm the UI reports Patch released with a signed receipt.
6. If the host permits custom tool execution, request apply_memory_patch again and then verify_delivery_receipt.

If the host registers the tools but declines direct invocation, that should be reported as WebMCP registered; host policy blocked direct invocation. Registration, consent/release, and signed receipt generation are independently visible on the live site.

Built With

• ed25519
• github-actions
• glm-5.3-flash
• javascript
• node.js
• ollama
• openrouter
• render
• sha-256
• tavily
• webmcp