DEV Community: Serhii Troian

Switching AI Agents Without Starting Over

Serhii Troian — Mon, 31 Aug 2026 18:51:51 +0000

A note the last session leaves in your repo, so the next one — any vendor — knows where the work stood

We build Origin, an MIT-licensed CLI that runs alongside AI coding agents and records each session into the repository itself. This is how one part of it works.

1. The note the last session left

AI coding agents — Claude Code, Cursor, Codex and the rest — work in sessions. You open one, you work, you close it, and everything it understood about the task is gone. The next session starts blank. If you switch to a different agent it starts blanker still, because none of them can read each other’s history.

Here is the exception. This was sitting in an agent’s context window one morning, before anyone typed anything:

Previous session context (claude-code, 18h ago):
Summary: Diagnosis is solid. It's not Origin's code — it's CPU
starvation from the host.
Last prompt: "Origin is slow again, debug what's the issue"
Changes: +6774 -308 lines

Nobody pasted that in. Nobody asked for it. The session that produced it had ended eighteen hours earlier and wrote it to a file on the way out. When the next session started, that file was read and rendered into its prompt before the first instruction arrived.

So the agent opened already knowing where things stood — which branch, which files were unfinished, what the last instruction had actually been. That is the entire feature. The rest of this article is about why the block is that short.

2. What it is like without one

You spent Friday afternoon on something nasty. Three files half-rewritten, a branch you named in a hurry, a fix that worked but needed one more case handled. You closed the laptop.

Monday you open your agent and type “ok let’s finish this.”

It has no idea what “this” is. So the first ten minutes go to reconstruction: which branch, which files are dirty, what the goal was as opposed to the last thing you typed, what you already tried and rejected. You are briefing a new hire who was in the room on Friday and remembers none of it.

Then make it worse in the way that is now normal — on Monday you open a different agent. Friday was Claude Code; today you want Cursor, or Codex, or whatever shipped a better model last week. Each keeps its history in its own directory in its own format, and none of them read each other’s. There is no shared storage even in principle.

This is not an edge case. People pick an agent per task, not per project, and the switching cost is paid in re-explanation every single time.

3. Seeing it

The note lives at .git/origin-handoff.json. You can read exactly what is stored and exactly what the next agent will be given:

$ origin handoff show

Cross-Agent Handoff Context

Agent: claude-code
Model: claude-opus-5
Session: 7f3776c8
Ended: 18h ago
Branch: fix/prompt-capture-window

Last prompt:
"the turn count is still wrong on merge commits"

Files in progress (3):
packages/cli/src/git-capture.ts
packages/cli/src/session-state.ts
packages/cli/src/commands/hooks.ts

Changes: +212 -47 lines

Open TODOs:
- handle the squash-merge case in the same pass

Context that will be injected into next agent session:
──────────────────────────────────────────────────
...
──────────────────────────────────────────────────

origin handoff clear throws it away if you would rather start clean.

4. What gets carried

Every field earns its place by answering a question you would otherwise have to answer yourself.

Two properties matter more than the schema.

It is written at the end of every turn, not at session end — so an agent that crashes, is killed, or is closed without ceremony still leaves a current note behind.

And agentSlug is written by one agent and read by another. That is what makes it cross-vendor: a Cursor session’s note is read by a Claude Code session, and says plainly that it came from Cursor.

5. The hard part is what it refuses to carry

This is where a feature like this is won or lost. Each rule below exists to prevent a specific bad experience, and each costs the feature something on purpose.

Not the transcript. There is a permanent temptation to make the note bigger — the whole conversation, every file read, all the reasoning. Every version of that makes it worse. The value is that the next agent reads it completely before starting work. A 40,000-token history does not get read, it gets skimmed, and skimmed context is how an agent confidently resumes the wrong task.

Not a session where you only talked. Ask your agent a question — “what’s in this repo’s history?” — and it answers. No files changed, nothing written. If that session overwrote the note, Friday’s real work-in-progress would be replaced by Monday’s idle question, and the next agent would open oriented around nothing. So a session that touched no files and changed no lines never replaces one that did.

Not its own output, fed back. Origin already injects context at session start. Ask an agent about that context and its answer is a recap of the injection. Store the recap as the session summary and the next session injects it, the agent after that recaps the recap, and within days the note is a description of a description of something that was once actual work. So the feature recognises text that is its own prior output and refuses it — on read as well as on write, which means a repo that already picked one up heals itself the next time it is read.

Not everything you say, as a commitment. Open TODOs are the highest-leverage field and the most dangerous, because a TODO is injected into every future session until it is resolved.

“We should refactor the retry logic” is a commitment. “We need to switch the gh user, but switch it back after” is an instruction for right now.

If the extractor cannot tell those apart, you get an agent that keeps trying to switch your GitHub user next week, for reasons nobody remembers. So extraction is anchored to actual development verbs (fix, add, refactor, migrate, handle…) and rejects hedged phrasing (I think, maybe, for now, never mind). Both rules deliberately match less.

That inversion is the most transferable idea here. In an ordinary data pipeline you tune an extractor toward recall, because a false positive is just a bad row somebody filters later. When the consumer is a language model, a false positive is an instruction that a capable system will act on, repeatedly, until a human notices. The cost is unbounded and nearly undetectable, because a plausible-looking TODO is indistinguishable from a real one.

Not stale state. A note older than 24 hours is not injected at all. In-progress state decays fast: a day-old list of “files in flight” probably describes files since committed, reverted, or rewritten by someone else. Confidently wrong context is worse than none, because the agent has no way to know it should distrust what it was handed.

6. It lives in .git, and that is a decision about you

.git/origin-handoff.json is not a committed file. It never appears in a diff, never shows up in a pull request, never lands in a teammate’s clone. It is scoped to your checkout, the way .git/HEAD is. Three consequences worth knowing before turning it on:

Nothing leaks into review. Your last prompt — however you phrased it at 7pm on a Friday — is not going in front of your team.
It does not sync. A colleague pulling your branch gets your code, not your note. Origin has a separate mechanism for metadata meant to travel between machines; this deliberately is not it.
You can inspect and delete it with ordinary tools. It is JSON on disk. cat it, rm it, or use origin handoff show and origin handoff clear.

7. What it cannot do

It cannot arbitrate between simultaneous sessions. It records the last one to finish, so in a checkout where three agents run at once the note reflects whichever stopped most recently. The honest fix there is a worktree per session, not a smarter merge.

It cannot reconstruct reasoning it was never given. If a session’s approach lived entirely in the model’s head and never touched a file, a note about files will not recover it.

And it is only as good as the last session’s summary. It is a bookmark, not a substitute for writing things down.

8. Why it belongs next to the code

Agents are becoming interchangeable faster than anyone expected. Which one is best for a given task changes month to month, and people switch accordingly, often mid-task.

The thing that should not be interchangeable is your place in the work. That state does not belong in a vendor’s session store, because you will not be in that vendor’s session tomorrow. It belongs next to the code — in a format anything can read, small enough that the next agent, whatever it turns out to be, can absorb it in one pass before touching anything.

The whole feature is a JSON file in .git. Most of the engineering went into deciding what to leave out of it.

Implemented in the Origin CLI (MIT, getorigin.io): handoff.ts holds the payload, the carry-forward rules and TODO extraction; context-injection.ts assembles and deduplicates the blocks injected at session start. origin handoff show prints the current note and exactly what the next agent will receive.

ORIGIN

Serhii Troian — Fri, 07 Aug 2026 13:05:01 +0000

Ground Truth for AI-Written Code

Session capture, per-line attribution, and selection-bias-free agent benchmarks - on top of the Git host you already use.

A technical overview for engineers and engineering leaders evaluating how much of their codebase is now written by AI agents - and who is accountable for it.

Contents

The problem: git blame no longer tells the truth
How Origin captures an agent session
Attribution: first-author-wins, with Git as the source of truth
Prompt-level time travel
Honest benchmarking: the agent scorecard
Bake-offs: the selection-bias-free comparison
For teams: governance without a second source of truth
Architecture, privacy, and getting started

1. The problem: git blame no longer tells the truth

On most teams, AI agents now write a large share of new code. But the tools that record who wrote what were built for humans. When an agent edits files in your working tree and you commit them, git blame attributes every one of those lines to you. The prompt that produced them, the model that ran, the cost, the number of turns, and whether the code survived the next sprint - none of it is recorded anywhere.

That gap has real consequences:

Provenance - no answer to “which agent, from which prompt, wrote this line?” during review or an incident.
Cost & efficiency - no ground truth on what a feature cost in tokens and dollars, or which agent got there in fewer turns.
Quality - no measure of whether agent-written code survives, or gets reworked and reverted days later.
Comparison - “which agent is better for us?” answered by vibes, because every naive comparison is poisoned by selection bias (the hard tasks go to the agent you already trust).

Origin closes that gap. It captures the full agent session - prompt, diff, tokens, cost, tools, duration - attributes every surviving line back to an agent and a prompt using Git as the source of truth, and turns that data into honest, selection-bias-free comparisons between agents. It runs on top of GitHub or GitLab; there is nothing to migrate.

2. How Origin captures an agent session

Capture is deliberately boring and durable. A one-time origin enable registers the machine, auto-detects installed agents (Claude Code, Codex, Cursor, GitHub Copilot, Gemini, Aider, Devin, Antigravity, and more), and installs two kinds of listeners:

Agent hooks - Origin hooks fire on the agent’s lifecycle events (session start, each user prompt, each tool/file edit, and stop/end). They record the prompt text, the per-turn file diff, token and cost counters, tool calls, and the model.
Transcript watchers - for agents that keep a durable on-disk transcript (e.g. Codex’s rollout logs, Devin’s local session DB), Origin reads that record directly instead of depending on hooks. The principle: if there is an authoritative transcript, read it; hooks are for context and policy.

Capture is resilient by design. It writes locally first, retries on a durable queue when the network is down, resolves session end from heartbeat liveness rather than a fragile inactivity timer, and is aware of git worktrees so parallel sessions don’t collide. Sessions that never produced real work are swept so counts reflect reality.

Figure 1. Every AI coding session Origin captured - agent, model, cost, tokens, branch, and review status. This is the raw material everything else is built on.

3. Attribution: first-author-wins, with Git as the source of truth

Recording a session is easy; attributing lines correctly is the hard part, and it is where Origin is opinionated. The model is first-author-wins: a line is credited to whoever introduced it, and later edits never re-claim it. For pushed commits, Git is the ground truth - Origin reconciles its capture against the committed diff rather than trusting a possibly-lossy hook stream.

Figure 2. One session, decomposed: each prompt and its diff (committed vs uncommitted), the linked commit, and a 100%-AI verdict - the ground truth per-line blame is built from. The AI Blame tab drills to the line level.

4. Prompt-level time travel

Because Origin records the state before every prompt, each prompt becomes a restore point. You can undo an agent’s changes - the files revert - without rewriting or losing your commits.

5. Honest benchmarking: the agent scorecard

Once sessions are captured and attributed, Origin computes a per-agent scorecard - efficiency, outcome, and survival - over your real work. The point of difference is honesty: the scorecard refuses to draw conclusions the data can’t support.

The guardrails matter as much as the metrics:

Minimum sample size - agents aren’t ranked on a handful of sessions; below a threshold, a metric is shown as “not enough data,” not a misleading average.
Confidence intervals - ratio metrics (e.g. tokens-per-line) carry a CI, so a noisy small sample can’t masquerade as a clear winner.
Estimated tokens excluded - sessions whose token counts were estimated rather than reported are flagged and kept out of the money math.
Line-weighted authorship - the AI-vs-human percentage is weighted by lines, not session count, so one giant human commit doesn’t get outvoted by many tiny agent ones.

Figure 3. The agent scorecard - cost, tokens-per-line, median turns, approval, and survival per agent, with sample-size and confidence guardrails.

6. Bake-offs: the selection-bias-free comparison

The scorecard measures agents on the work you happened to give them - and you give the hard tasks to the agent you trust, which skews every comparison. A bake-off removes that bias by construction: it runs the same prompt through N agents, each in its own isolated Git worktree, and lets you compare the results side by side. Every arm gets identical work.

Architecture: the server schedules, your machine executes

Coding agents run on your machine, with your keys - Origin’s cloud can never run them. So a bake-off is split cleanly in two: the server owns the queue and the schedule; a local runner daemon owns execution.
Each arm branches from HEAD into bakeoff//, the agent works autonomously and commits, and Origin correlates the result back to the branch via normal session capture - nothing extra to wire up. The list nests each arm’s session inline (cost, tokens, lines, status), filters by status/repo/agent, pages ten at a time, and rolls up a head-to-head agent comparison across every bake-off you’ve run.

Deliberately, Origin does not auto-declare a winner. It tints the cheapest and fewest-turns arms to help you scan, but “cheapest” and “best” are not the same thing - only a human reading the diff can decide. You pick the winner.

Figure 4. Composing a bake-off - the same prompt, two or more agents, each running autonomously in its own git worktree. Results stream back as sessions and roll up into a head-to-head comparison.

7. For teams: governance without a second source of truth

Everything above is per-developer value that also aggregates for a team. On top of it, Origin adds an org layer: typed policies enforced across review, PR checks, and CI; AI auto-review of agent sessions; secret and PII scanning on captured diffs; budgets and cost controls with per-agent visibility; role-based access; and an organization dashboard that shows what share of the codebase is AI-authored, by whom, at what cost - line-weighted, not guessed.

Because attribution is per line and travels with the repo (prompts are carried in Git notes, and a dedicated sessions branch makes context portable across clones), the governance view is derived from the same ground truth developers see - not a parallel system that drifts.

8. Architecture, privacy, and getting started

Local-first capture - session data is recorded on your machine first. A fully standalone mode keeps everything in the repo with no account at all.
Sits on your host - GitHub and GitLab, multiple connected accounts, native Windows/macOS/Linux CLI. No repo migration.
Portable provenance - prompts live in Git notes; the origin-sessions branch is a zero-tooling vehicle so a fresh clone still has the history.
CLI-native - the CLI is a single Node binary distributed via signed GitHub releases; the platform API runs on a small, boring stack (Express + Prisma).

Origin turns the invisible half of your codebase - the half an agent wrote - into something you can read, attribute, price, and compare. Solo, it’s your provenance and undo button. For a team, it’s the ground truth under every AI-code decision.

AI coding at team scale: sessions, budgets, and policies

Serhii Troian — Thu, 16 Jul 2026 17:28:22 +0000

What it takes to see every session, control the spend, and enforce policy when several agents are writing your code.

A pull request lands. Four hundred lines, six files, tidy commits. Which agent produced it? Which prompts? What did it cost? Did it touch anything it shouldn’t have? Has anyone actually looked at it?

For most engineering organizations, the honest answer to all five is: no idea. Your team adopted Claude Code, Cursor, Codex and Gemini in about six months. Your tooling still assumes a human typed every line.

Three things have to be true before any of that becomes answerable at team scale. You need a record of what the agents actually did — the sessions. You need to know what it cost, and be able to stop it before it hurts — the budgets. And you need your standards to be something that runs, not something on a wiki — the policies.

That’s the shape of the rest of this piece. The examples below are how we built it in Origin Team, but the three problems are the same whatever you use.

1. Sessions: what your agents actually did

Everything else is built on one thing: the session. If you can’t reconstruct what an agent did, you can’t cost it, review it, or govern it. So that’s where it starts.

The capture

Your engineers install a CLI, log in to your organization, and run one command inside their repo. From then on, capture is automatic. No per-tool setup, no changed workflow, and it works the same across every agent they use.

npm i -g https://getorigin.io/cli/origin-cli-latest.tgz

origin enable

The Sessions view then lists every session anyone on the team runs, with the name, model, repository, branch, and the engineer who ran it. Open one and you get the full timeline: each prompt, the agent’s output, and the exact changes that prompt produced, down to the files it touched and the lines it wrote.

That record is the raw material for everything that follows.

The dashboard: your organization at a glance

The dashboard answers what a lead actually asks on a Monday: sessions per agent, token usage this month broken out by agent, cost by model, and AI adoption, meaning how many of your engineers are genuinely coding with AI rather than just licensed for it.

Four tabs go deeper:

Activity — sessions per day, top agents, top repositories, and lines written this month. Team adoption breaks it down per engineer: how many sessions they ran, and how much code they actually produced.
Cost & efficiency — which agent is genuinely more productive: cost per session, cost per commit, cost per line.
Quality — reviewed PRs, approved PRs, and policy compliance.
Prompts — every prompt your engineers ran, searchable. Find a specific session or prompt for debugging, review, or reference.

Repositories: every change, attributed

Connect your GitHub or GitLab repos and every change made to them is tracked. Click into a repository and you see each commit by user, the familiar Git line-by-line view, and, on captured work, the prompt behind each change plus the agent and model that made it. You can also see which sessions ran inside that repo, and by whom.

It answers “what changed, who changed it, which agent, and what were they asking for” in one place, per repository.

Insights: the numbers you’ve been guessing at

Insights turns the session record into the view you actually wanted: AI authorship as a share of the lines written, lines changed over time, cost over time, cost by model, sessions and cost per repository, and model adoption, meaning which models your team leans on most.

It’s the difference between “we use AI a lot” and a number you can take into a budget meeting.

2. Budgets: what it costs, and stopping it before it hurts

Once you have the sessions, cost stops being a monthly surprise. Spend is tracked across the organization so you can project it, monitor it, and cap it: how much went to a specific engineer, agent, or model, alongside a monthly projection based on recent usage. Token utilization is tracked the same way, not just dollars.

Then you set the guardrails. Limits come at two levels:

A soft limit warns the engineer but lets them keep coding.
A hard limit stops the agent from writing code and tells the user they have exceeded their budget. Set them daily, weekly, or monthly, and scope them per organization, per engineer, per agent, per model, or even per repository.

This is the difference between finding out about a $600 Thursday on next month’s invoice and not having a $600 Thursday.

3. Policies: your rules, actually enforced

Most teams already have standards for AI use. They live in a Notion page nobody opens. Policies make them something that runs inside the coding session: rules that allow, restrict, or prohibit specific actions, for the whole org or for specific users.

Agents: what your team is allowed to run

First you decide the surface: which agents exist, which are allowed, and what rules ride along with each. Per agent, you can:

Set a system prompt that is shown to every engineer who launches it.
Set session limits, meaning how many tokens or how much cost a single session may consume.
Attach policies, org-wide or specific to that agent.
Review versions. Every configuration change is versioned, and you can roll back.
Control access, so you can see exactly who can use each agent.

The rules

The built-in rule types cover most of what teams need:

File restriction, to keep agents out of .env files, secrets, and prod configs.
Model allow-list, to ban specific models from being used for coding.
Content filter, to block specific words, phrases, or patterns.
Cost limits, required review, commit-message rules, and session limits.

When the presets don’t cover it, you describe the rule in plain English and the policy is generated for you, then injected into your agents: all of them, or only the ones you choose. Those rules reach each engineer through their CLI, and when someone crosses a line it shows up under Violations.

Pull request checks: the gate

A rule with no teeth is a suggestion. This is where it bites. Origin builds its review directly into GitHub pull requests and GitLab merge requests. When an engineer finishes a session and pushes, you get a PR check, and the pull request stays frozen until someone reviews what produced it: the sessions, the cost, the prompts, and the changes. Approve, and only then is it allowed to merge.

No new process for your team to adopt. The gate sits on the workflow you already have.

The rest of it

Snapshots let an engineer roll back to a specific prompt. Ten prompts deep and you want to return to prompt five? Digging through git history for that is miserable. Instead, pick the snapshot for that prompt, press restore, and the source is back to that point.

Security runs a built-in analyzer over captured work and flags what slipped in: credentials, API keys, emails, and other secrets that ended up in the source. Because every change carries the prompt behind it, tracing how something got there is a click, not an investigation.

Infrastructure shows the users and machines running Origin, a live picture of who and what is doing AI-tracked work.

IAM is where you define access levels to agents and repositories, and invite members with exactly the permissions you intend.

Settings holds general configuration, your coding plan (set per agent), API keys, and integrations: GitHub, GitLab, Slack, email reports, and an AI provider (recommended, so PR summaries and review checks work). Alongside it: notifications, a full audit log of everything reported, and a compliance tab for reporting.

One design decision underneath all of it

None of this works as a dashboard watching from the outside. The prompt, the model, the diff, and the cost are written into the Git repository itself, next to the commits they produced.

That has consequences worth caring about. The history travels with a clone: new laptop, new teammate, new agent, it comes along. It is vendor-neutral, so work recorded by Claude Code is readable by Codex. And there is no lock-in on your own project’s history.

Getting started

Setting up the organization takes a few minutes: create the account, pick the agents your team uses, set your billing policy, connect your repositories, and invite your teammates. Each engineer then installs the CLI and runs origin enable once. Their sessions roll up into your dashboard from that point on.

Origin Team is $29 per user per month, with a 14-day free trial. Solo developers use it free, forever.

Watch the full platform tour:

https://youtu.be/XMwH7j9Ij5k