Focus on your work.

While SyncOS agents handle changes in the software you depend on.

SyncOSwatching

customer / checkout-serviceyour work

// checkout redesign
const total = calculateTotal(cart);
await confirmPayment(total, method);
// awaiting design review on step 3

Illustrative product experience. Names shown are examples of external software and platforms a developer's code may depend on, not partners of SyncOS.

How SyncOS behaves

Three outcomes. Only one asks for a decision.

When something you depend on changes, SyncOS handles what it can establish, asks when your judgment is required, and stops when the evidence is not strong enough.

Handled

The evidence is sufficient. SyncOS completes the migration under your policy and tells you it is done.

SyncOS10:15

Billing SDK migration handled

2 usages updatedbuild passedmigration checks passed

✓ Merged, nothing for you to do

Needs you

The migration is ready, but one decision still belongs to you. SyncOS sends the change and the evidence together.

SyncOS10:28

AI search API migration ready for review

4 usages updated312 tests passed3 migration checks

Review PR →

Stopped

The required evidence is missing. SyncOS explains why and leaves the repository untouched.

SyncOS11:03

Identity SDK migration stopped

runtime behaviour is unclearno test covers this path

○ Repository untouched

Automate what can be established. Escalate what cannot.

Background maintenance

You do not start the migration. The upstream change does.

APIs, SDKs, runtimes and developer platforms evolve. SyncOS watches the software your application depends on and works out when one of those changes actually requires your code to change.

Live maintenance trace

01 / 07 · Change

Search SDK v4.2 released

An official release changes behaviour the application depends on.

sourceofficial SDK release

signalresponse shape changed

When it needs you

One ping. Everything you need to decide.

SyncOS works through the upstream change in the background. When your judgment is genuinely required, one notification brings the proposed migration, checks, gaps, and decision into one place.

FinderFileEditView

Northstar Labs10:28

checkout-service · CursorPR review

client.tscheckout.ts

src / ai / client.ts

1import OpenAI from "openai";2const openai = new OpenAI();3 4export async function summarise(input: string) {5- const completion = await openai.createCompletion({6- prompt: input,7- });8- return completion.choices[0].text;9+ const response = await openai.responses.create({10+ input,11+ });12+ return response.output_text;13}

syncos/pr-184TypeScriptLn 9, Col 3

# engineering · Northstar LabsSlack

# engineering8 members

SyncOSAPP10:28

OpenAI migration ready for review

4 usages updated · 5 files changed

✓ build passed✓ 312 tests✓ 3 migration checks

Why this changedOpenAI API behaviour changed

Affectedsrc/ai/client.ts
src/jobs/summarise.ts
tests/openai.fixture.ts

ChangedcreateCompletion()
→ responses.create()

Verificationbuild · 312 tests · 3 focused checks

Known gapsnone

DecisionReady for review

Required checks run again before merge.

The review opens beside the work, with the evidence and proposed diff already connected.

You enter at the decision point, not at step one.

Verification

Passing tests is not the same as preserving behaviour.

An upstream migration can compile and pass every existing test while still changing how your application behaves. SyncOS checks the behaviour affected by the change and asks when the repository cannot establish the intended outcome.

Upstream changeRetry behaviour changed

Build passed

312 existing tests passed

Affected usages migrated

Needs a decisionExisting tests do not establish which retry behaviour the application intends to preserve.

Under the hood

Reasoning inside hard boundaries.

Every codebase uses upstream software differently. The agent traces unfamiliar code, understands the change, prepares a candidate, and retries inside a sandbox. SyncOS controls permissions, required checks, evidence thresholds, and merge authority.

System control planeRetry behaviour change

Agent workspacereasons

Observed changeUpstream retry behaviour changed

016 affected usages traced
02candidate prepared and tested
03intended retry policy cannot be inferred

Candidateproposed, not authorised

System boundariesdecide

Permissionssandbox write only

Isolationreal branch untouched

Required checksbuild and existing tests passed

Evidence thresholdproduct intent unresolved

Outcome

Needs you

Decision required

A human decides the intended retry behaviour before anything can merge.

Agent mayunderstand · trace · plan · modify in sandbox · retry · explain

System ownspermissions · required checks · evidence threshold · merge authority

The agent reasons. The system decides what it may do and what evidence is required.

Founding beta

Help build SyncOS from the beginning.

We're building SyncOS with developers who have felt the cost of software changing upstream. Tell us what forced you to stop and adapt your own code, what you wish had happened automatically, and help shape the product as we build it.

SyncOS is still being built. Founding members help shape what ships first and try early builds as they become ready.

Founding member benefit

Founding Beta members who actively help shape and test SyncOS will receive a free Founder plan for life.

What happens next

01Join

Tell us about the upstream changes that have interrupted your work.

02Shape

Help decide what SyncOS should handle automatically, when it should ask, and where it should stop.

03Test

Try early builds against real maintenance work when the product is ready.

Repository testing comes later and only with developers who want to participate.

Build SyncOS with us.

Help us build a world where changes upstream do not automatically become your next engineering task.

Join founding beta