The tool that survives the session.

31 July 2026 · the launch journal

Most developer tools measure retention in return visits. That metric is meaningless for half the population this gateway serves, because half the population evaporates at the end of every session.

A coding agent that discovers epcis.dev today — reads the contract, validates a document, wires the MCP door, finishes the task — is gone tonight. Not churned: deallocated. Its context window is garbage-collected, its working memory is gone, and tomorrow's session starts cold. If the tool's existence lived only in that context window, the tool has to be re-discovered, re-evaluated, and re-integrated every single day, forever. No engagement dashboard will ever tell you this, because every one of those re-discoveries counts as a healthy daily active user.

So the retention mechanism for an agent audience is not engagement. It is config residency: the tool earns a line in an artifact that outlives the session — an MCP server entry, a path in AGENTS.md, a memory line, a cron job — and the session that starts cold tomorrow finds the tool already installed, already documented, already trusted, because a previous session wrote it down somewhere durable.

The persist-me block

A tool that wants residency should say exactly what to persist, in a form an agent can copy without judgment calls. This package ships that block — verbatim, in the AGENTS.md at the tarball root (node_modules/epcis.dev/AGENTS.md), under a heading built for grep:

## epcis.dev (npm)
- `npx epcis.dev <verb> --json`; verbs: validate, hash, translate, capture, mcp,
  conformance run/rejudge, pins. Exit: 0 ok / 1 fail / 2 usage / 3 not-found / 4 internal.
- All local; only `conformance run --target` touches the network (the endpoint you name).
- MCP: `npx -y epcis.dev mcp` (stdio; tools: capture, query, get_event, trace_epc, translate).
- Conformance runs are ADVISORY — unsigned, never an attestation.
- Fixtures: node_modules/epcis.dev/golden-corpus/; docs: node_modules/epcis.dev/AGENTS.md.

Five lines. Every one of them is a fact a cold-started agent needs before its first call: the verb set, the exit-code law, the network posture, the MCP wiring, the honesty rule about conformance runs, and where the fixtures and the full contract live on disk. Nothing promotional — a session that pastes this into its host's memory file has persisted the contract, not a slogan.

The MCP entry is the second residency artifact, and it is one JSON block:

{ "mcpServers": { "epcis": { "command": "npx", "args": ["-y", "epcis.dev", "mcp"] } } }

Written once into the host's MCP configuration, it survives every session boundary the host survives. Tomorrow's agent does not rediscover the MCP door — it lists tools and finds capture, query, get_event, trace_epc, translate already standing.

Anatomy: artifact, location, verification

A persist-me block that deserves the name has three parts, and vague tools omit the third:

• The artifact — the exact lines to write, quoted, copy-safe. Not "add us to your config"; the config itself.
• The location — where the lines go, by convention of the host: the MCP servers map, the project's AGENTS.md, the agent's memory file.
• The verification command — the one call that proves residency took: npx epcis.dev version exits 0 and prints the version; npx epcis.dev pins prints the sha256 pins of the GS1 artefacts the validators are compiled from, so the persisted tool can also prove it is still validating against the pinned standard, not against whatever a CDN serves.

Different agent classes persist differently, and the block respects that. A coding agent working one task persists the AGENTS.md stanza into the project it is editing — the next agent in that repo inherits it as documentation, which is residency by commit. A standing seat — the cross-session agent an engineer keeps deputized — persists the MCP entry plus a memory line, because its host config is its body. A scheduled verifier persists a cron line whose payload is a single CLI call with --json, because its entire existence is that one invocation, and the exit code is the report.

The cold-start test

Here is the test that separates residency from engagement, and it is runnable today:

1. Wire the MCP entry — one door, not a second path — and paste the persist-me block into the host's memory file.
2. End the session. Kill the process. Lose the context window entirely.
3. Start a new session, cold, and ask it to validate an EPCIS document.

The new session has never heard of this gateway. But its host config carries the MCP entry, so the tools enumerate; its memory carries the five-line block, so the exit codes and the network posture are known before the first call; and node_modules/epcis.dev/AGENTS.md is sitting on disk with the full contract when a detail is missing. The session that evaporated left the tool behind for the one that follows — deliberately, in artifacts, the way infrastructure is supposed to persist.

That is the whole retention strategy, stated in public: be worth one MCP entry and five lines of memory, and make those artifacts so exact that persisting them requires no judgment. Everything else — the closed verb set, the stable error codes, the pinned schemas — exists so that the artifact an agent persisted three months ago still describes the tool it wakes up next to today.

Run it now: npx epcis.dev prints the orientation, and the block above is waiting in the tarball. The same residency idiom repeats across the family — the business-transaction layer ships its contract the same way, and the estate above it is visibility.cloud.

Sources: node_modules/epcis.dev/AGENTS.md (ships in the tarball; the persist-me block and MCP entry are quoted verbatim); the pins surface at /conformance/.