The safe write layer for coding agents

One work SDK for every tracker.

Create, update, comment on, and transition work across GitHub, Linear, Jira, and Azure DevOps with one typed API — with previews, idempotency, and conflict protection built in.

Preview every write
Inspect exact changes before commit.
Safe to retry
Prevent duplicates and stale overwrites.
Provider-aware
See capabilities and mapping warnings.
agent-safe-update.ts
import { createWorkClient } from "work-sdk";
import { github } from "work-sdk/github";

const work = createWorkClient({
  adapter: github({
    owner: "acme",
    repo: "api",
    token: process.env.GITHUB_TOKEN!
  }),
});

const change = await work.prepareUpdate(
  "481",
  { state: "done" },
);

await work.commit(change, {
  idempotencyKey: "merge:api#481",
});

Proposed change

acme/api#481

stateopenclosed
!

Mapped ‘done’ to GitHub’s closed state

Inspect exact changes and provider warnings before anything is written.

One normalized model for

GitHub Issues Linear Jira Azure DevOps

More adapters welcome

Built for real side effects

Agents can write code.
Trackers still make them guess.

Provider APIs disagree on states, identities, revisions, rich text, and error shapes. Work SDK puts those differences behind a typed, inspectable boundary.

01

Wrong transition

“Done” can mean a state, transition ID, or a closed flag. Resolve intent against the provider before writing.

02

Duplicate comment

A timeout does not say whether a write succeeded. Idempotency makes retries deterministic.

03

Stale overwrite

An item can change between read and write. Revision checks stop agents from erasing newer work.

A safer primitive

Prepare. Inspect. Commit.

Turn an irreversible API call into a change you can reason about, approve, log, and replay.

01 / PREPARE

Build a change plan

Fetch current state, normalize provider semantics, and calculate the exact diff.

work.prepareUpdate(…)
02 / INSPECT

See what will happen

Review field changes, lossy mappings, unsupported capabilities, and expected revision.

change.warnings
03 / COMMIT

Write once, safely

Verify the plan and revision, then commit with a stable idempotency key.

work.commit(change)

Small API, serious guarantees

Infrastructure for trustworthy agent actions.

Integrity-checked changes

A prepared change carries a fingerprint. Mutate it after inspection and the SDK rejects the commit.

if (fingerprint !== expected) throw WorkValidationError

Idempotent commits

Retry without creating duplicate comments or repeated updates.

Capability discovery

Check support instead of asking an agent to guess.

Normalized errors

Handle auth, rate limits, conflicts, and unsupported fields consistently.

Strictly typed

ESM and CommonJS builds, zero runtime dependencies, Node.js 20+.

Honest by design

Know what each provider can do.

Capabilities are data, not scattered documentation. Detect support before an agent proposes an action.

Explore adapter docs
Work SDK provider capability comparison
CapabilityGitHubLinearJiraAzure
Create and updateSupportedSupportedSupportedSupported
CommentsSupportedSupportedSupportedSupported
Custom statesSupportedSupportedSupported
Multiple assigneesSupported
Optimistic concurrencySupportedSupportedSupportedSupported

Straight answers

Frequently asked.

Is Work SDK a hosted service?

No. It is an open-source TypeScript library that runs in your application. You bring credentials for the trackers you already use.

Can I inspect provider-specific data?

Yes. Normalized entities can retain the raw provider payload for fields that are not part of the portable core.

Does it replace human approval?

No. Work SDK gives approval systems a concrete diff and warnings to evaluate. Your application decides when a human must approve a commit.

Can I add another tracker?

Yes. Adapters implement a compact contract and can be tested against the shared conformance suite.

Give agents a safer tool

Ship work, not side effects.

Start with one provider. Keep one API when your stack changes.