Skip to main content
Cx
Start building

Product · how releases work

Experts edit the context. You decide when it ships.

Every change your experts make can become a numbered release that never changes. Your eval cases run against it, and production is held back when they fail. Agents that read through the SDK or the resolve API get a release only when you move a label to it. Rolling back returns the label to where it pointed before.

Start free trial14 days of Team, no card up frontInstall for Claude CodeTalk to us

01 / 05 · Releases and labels

A release never changes. The label moves.

Try it below. A release whose eval cases fail cannot take the production label. Rolling back returns production to the release it pointed at before, and that step is never held by the eval gate. Moving production to any other release is an ordinary move, and the gate checks it. The releases here are an illustration with made-up content.

  1. First release

    Cut as release 1 · sealed

    Instructions v2, Refund reply v2, Ticket triage v1, policy.md v4, 4 tools

    Eval cases 2 of 2 pass
  2. production

    Store credit after 30 days

    Cut as release 2 · sealed

    Instructions v2, Refund reply v3 adds the 30-day store credit rule, policy.md v5, 4 tools

    Eval cases 2 of 2 pass
  3. staging

    Shorter refund reply

    Cut as release 3 · sealed

    Instructions v2, Refund reply v4 trims the reply and drops the 30-day line, policy.md v5, 4 tools

    Eval cases 1 of 2 pass

Try it

production is on r2. staging is on r3.

r3 is the newest release, and one of its eval cases fails. Try moving production to r3, then to r1, then roll back.

Label history

  • production → r2 (start)

02 / 05 · Two views, one change

The expert sees a document. You see a release.

Both views show the same edit to the Refund reply skill. The expert writes in plain language and never meets a release number unless they go looking. You get the versions, the checks and the label. The skill here is an example.

What the expert sees

Refund reply

Draft a reply a customer can act on when they ask for a refund or a return.

  1. 1. Look up the order before promising anything.
  2. 2. After 30 days, offer store credit instead of a refund, and say why.Edited
  3. 3. Link the policy in references/policy.md.

The expert edits in the editor and publishes the skill. They do not choose when it reaches the agent.

03 / 05 · Signed API and SDK

Your code reads the release in three lines.

The SDK fetches whatever release a label points at, checks its signature, and caches it so Contexory stays out of your request path. The Claude Code and OpenClaw plugins work differently: they serve each skill's published version, unless they are pointed at an agent, and then they serve that agent's release at production.

  • Signed. Every response is checked with Ed25519. A bad signature throws and is never cached.
  • Cached. Releases never change, so they are held in memory and on disk. A hot resolve does no network I/O.
  • Last good release on failure. If Contexory is unreachable you get the last verified release, marked stale.
  • Runtime keys. Use an organization-owned, read-only key scoped to the agents you name.
agent.ts
import { Contexory } from "@contexory/sdk";

const cx = new Contexory({ apiKey: process.env.CONTEXORY_API_TOKEN });
const ctx = await cx.resolve("support-agent", "production");

What comes back

ctx.release
The release the label points at, with its number
ctx.system
The release's system prompt
ctx.skills
The pinned skill files
ctx.applyTools(tools)
Released tool descriptions applied to your own tools
ctx.stale
True only when serving the last good release
Read the SDK docs →

04 / 05 · Runs

Every run says which release it used.

Stamp each span with its release using instrument(), and your OpenTelemetry Collector sends run summaries to Contexory with a write-only ingest key. Contexory ingests a second copy of your trace and never stores message content, tool arguments or tool results. Compare releases on the runs each one served.

Stamp every run with its release

agent.ts
import { instrument } from "@contexory/sdk";

const stamp = await instrument({ release: ctx });

Sample runs · outcome met on 5 of 6

RunReleaseLoadedStepsOutcome
#1048r2Resolved
#1047r2Resolved
#1046r2Resolved
#1032r1Not resolved
#1031r1Resolved
#1030r1Resolved

Outcomes are rules you define for your agent, such as loading a skill or finishing without an error. The run ids, steps and outcomes here are an illustration.

05 / 05 · Tools

Tools say whether they read or change things.

Each tool gets a plain name and an effect, and tools are grouped by effect so a deletion never sits beside a lookup. Every tool starts off, and someone turns on what the agent needs. A tool we have not reviewed is listed under its own name, because we do not guess what it does.

Reading

These can't change anything in the service.

  • Search issuesLinearOff
  • Read an issueLinearOff
Writing

These change things in the service. Turn on only what the agent needs.

  • Create an issueLinearOff
  • Delete an issueLinear · Can't be undoneOff
Unclassified

We don't know whether these change anything, so they start off.

  • custom_queryA server we have not reviewedOff

Contexory never stores your passwords or keys. You sign in with the service directly, and it keeps the credential.How we handle your data →

Rollback in one move

Put your agent's context under release control.

Bring one agent and one skill. Cut a release, write two eval cases, and move the label before the trial ends.

Start free trial14 days of Team, no card up frontInstall for Claude CodeTalk to us
See pricing →