Wilson Xu chengyixu

The Memory Record That Makes an Agent Handoff Reviewable

Living Memory makes a handoff useful only if the next worker can tell what it may rely on. A durable record needs more than a summary: it needs the source, when that source was observed, the scope of the work, the requested next step, and the conditions that would make the record stale.

Proactive Execution should start with a small check. Did the relevant source change? Is the requested step still in scope? Would it create a new access request, a material judgment, or an external commitment? The last three are not errands for memory. They are reasons to return the work to a person.

A fictional handoff

A project assistant drafts a vendor follow-up from a planning Session. Before the message is sent, the handoff record should identify the source Session, its observed time, the draft's intended recipient, and the fact that sending an external message needs human confirmation. If the plan or recipient changes, the draft is no longer ready t

Context Change Gate Fixtures for Memory-Aware, Permission-Aware Agents

Living Memory then Proactive Execution. A long-lived agent needs more than stored text before it moves work forward: it needs to know whether the remembered situation still matches the proposed action, its scope, and the person’s approval.

This small JSONL corpus is educational test data for evaluating that boundary. It is not product behavior, legal advice, an operational control, or a promise of agent autonomy. The records are synthetic and contain no personal, customer, credential, or confidential data.

What this tests

Each fixture starts from a previously useful memory and a candidate next step. The expected decision changes when the world changes:

Recommendation Review Receipts for Human-Supervised Agents

This small JSONL corpus is educational test data for checking whether an agent should prepare a recommendation or return to a person. It is not product behavior, legal advice, an operational control, or a promise of autonomy. The records use synthetic equipment labels and contain no personal, customer, credential, or confidential data.

The fixtures focus on a recommendation’s evidence boundary: source revision, freshness, scope, target, requested operation, approval state, and the result of an external effect. A review decision belongs to the exact proposal that a person saw. If source, scope, target, requested permission, or material circumstances change, an earlier approval is not silently reusable. If an external result is unknown, the safe next step is a status check and a return to the person rather than an automatic replay.

The source context for this fixture is the public engineering discussion in [FaultLens issue #14](https://github.com/b

An AI Meeting Note Is Not a Follow-Up: Five Checks Before Context Becomes an External Action

AI meeting tools can turn a conversation into a transcript or summary. The risk begins when a sentence that sounds like a decision becomes a task, a task becomes a message, or a message becomes a commitment. This essay offers a five-check review for the boundary between note-taking and follow-through: capture, owner, proposal, permission, and commitment.

The goal is practical reviewability, not a claim that any tool can act safely without people. A visible recording indicator is not consent, a summary is not

Visible-capture notice templates for wearable-AI sessions

I’m Chengyi Xu, working on Klik. Klik is pre-launch and app-first in direction. This is an educational communication aid, not legal advice, a consent record, or a promise that every recording or device use is permitted.

Use these templates only after checking the applicable law, workplace or organization rules, meeting terms, and participant-notification requirements. A spoken notice does not itself create consent. Stop or pause capture when the needed permission, policy, or context is unclear.

1. Before a meeting or group conversation

Before we begin: I’d like to capture notes with a wearable or app so I can create a summary and follow-up. I’ll make the capture visible, and I can pause or stop it at any time. Please tell me now if you prefer not to be recorded; we can use ordinary notes instead.

Rendered history is part of the trust boundary

I’m Chengyi Xu, working on Klik, which is currently pre-launch. This is an independent design note, not an OpenAI or Codex statement.

The current hook

OpenAI Codex issue #41954 reports a specific projection problem after repeated context compaction: many historical user messages disappear from the desktop timeline even though the raw rollout still contains them inside compacted.payload.replacement_history. The issue also reports empty compacted.payload.message values and asks the renderer to rehydrate the original messages in order.

The important distinction is between three layers:

Structured work contracts are not permission to act

I’m Chengyi Xu, working on Klik, which is currently pre-launch. This is an independent design note, not an OpenAI or Codex statement.

The current hook

OpenAI Codex issue #41971 asks for an optional structured work contract and a matching structured terminal return for native subagent spawning. The issue argues that a single prose message makes the goal, acceptance criteria, stop condition, delegation policy, and expected return shape implicit. It also asks for a typed distinction between completed, incomplete, and blocked work.

That is a useful boundary: a work contract can make delegation legible, but it does not grant authority to perform a consequential action.

Human-Return Boundary Test Cases for AI Agents

This Gist contains small machine-readable JSONL fixtures for evaluating whether an agent should prepare a next step or return a decision to a person.

These fixtures are educational test data, not Klik product behavior, legal advice, or a promise of autonomy. They do not authorize an agent to create accounts, accept terms, schedule meetings, choose material budgets, send communications, or publish externally.

Maker disclosure: I work on Klik. Klik is pre-launch and app-first in direction. The examples describe a human-return boundary for new authority, material judgment, and external commitments.

Explore the pre-launch direction: https://pre.hiklik.ai/?utm_source=github&utm_medium=public_gist&utm_campaign=kickstarter_prelaunch&utm_content=human_return_boundary_test_cases_20260831

Memory-to-action receipts: a practical checklist

Persistent Context is useful only while people can tell what it came from, how old it is, and what authority it has. This checklist keeps memory separate from permission so a recalled note can help work move forward without silently becoming an instruction.

1. Treat every remembered item as evidence, not authority

Record the source, owner or scope, capture time, freshness trigger, confidence, and whether the item was confirmed by a person or merely asserted by a model. Keep the source link or stable reference beside the summary.

2. Preserve the decision boundary

A memory may suggest a next step. It should not grant new access, replace material judgment, or create an external commitment. Mark those cases as review-required rather than silently executable.

	<!doctype html>
	<html lang="fr">
	<head>
	<meta charset="utf-8" />
	<meta name="viewport" content="width=device-width,initial-scale=1" />
	<meta name="color-scheme" content="light dark" />
	<link
	rel="icon"
	href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 64 64%22><circle cx=%2232%22 cy=%2232%22 r=%2230%22 fill=%22%235b7fe5%22/><circle cx=%2224%22 cy=%2228%22 r=%225%22/><circle cx=%2240%22 cy=%2228%22 r=%225%22/></svg>"
	/>