Agents Outgrow Git, and Other Plumbing

The news

Why git stopped fitting

The key observation was that Anthropic, like most companies, already treated git as a centralized system with one authoritative copy. Almost all its clients were agents and jobs that are always online. Git's offline strengths were now a cost with no matching benefit.

Design principles

Scion borrows lessons from Google's Piper and Meta's Sapling and rests on six principles:

How it works

Derived data. A changeset only records what changed, so on its own it can't quickly answer "who last edited this line?" Scion builds extra structures from changesets for blame, path history, and skip lists over the commit graph. These all run through one mechanism: each type is defined recursively, so its value for a changeset is computed from its parents' values. New index types are easy to add (the team has since added copy detection and path-based file search). Each type can be computed eagerly or on demand. Clients never see the internals, so the structures can change without client changes.

Fetching files. Git's fetch negotiation tells the server what the client already has, and the server computes what's missing. Scion reverses this. Here is an illustrative walk-through. A client starts from the root tree, checks its local store, and requests only the missing subtrees. It recurses into those, then does the same for blobs (file contents). If a job only needs services/billing/, it never requests other subtrees, so sparse and virtualized checkouts (files materialized when read) need no special handling. Every request names an immutable object, so any cache can answer it, and an interrupted fetch can resume. There is no single multi-gigabyte response.

Three cache tiers. Each machine runs a scion-daemon that serves all jobs on that node, starting from a periodically refreshed snapshot. It talks only to regional scion-cache servers, which stream objects from memory in the format the daemon stores them, with no delta compression or missing-object computation. Cache misses go to the authoritative scion-servers, which read from Spanner or cloud storage. All three tiers answer the same RPCs, but tiering is strictly enforced so a regional failure can't overwhelm the origin servers.

Results

• Each tier keeps a cache hit rate above 99% and holds no long-lived state.
• CPU and memory use is 200x lower than the git mirror fleet it replaced.
• Checkouts take seconds instead of minutes, which freed 25% of CI CPU capacity.

What the team learned

Seven people built Scion, Antique and about half a dozen related systems while daily merge volume grew 10x. Every engineer on the team now rates Claude as a better coder than themselves. They say their job was often to tell Claude "no". Agents broke system constraints, for example by scanning the commit log linearly to find when a change merged instead of asking the review tool. Adversarial review (having models critique each other's changes) sometimes pushed toward over-engineering, such as excessive validation of a trusted internal service. Humans still review every change, but they check intent rather than every line.

Other practices:

• Hermetic simulations (tests that run fully isolated from real systems) and fuzzing.
• Directory-level permissions.
• Review rules that tell comment-only edits apart from sensitive logic changes.
• Per-component monitoring Claudes in Slack, called "superfans", that watch telemetry for subtle problems that standard alerts miss.

The team also dropped the usual global merge-queue lock. It relies on post-merge and pre-deploy testing instead, and accepts that concurrent changes sometimes conflict, which Claude usually fixes quickly.

Caveats

Anthropic says Scion is not a general git replacement. It only makes sense for very large monorepos, and it would require custom code review, search and CI. The post is also a self-report: it gives few baselines beyond the mirror fleet, and nothing on error rates or the token cost of this way of working. Instead of releasing Scion, Anthropic proposes ideas git servers could adopt: server-side query RPCs, possibly standardized across forges; a want-based negotiation protocol; and sparse and shallow features that work well together. It expects other companies to hit these limits within 6–12 months.

Anthropic says it has sharply reduced how much of Claude's reasoning outside labs can harvest to train copies of the model. Its main measure is how many of Claude's reasoning tokens distillers pull from Anthropic's own platform. Since a new classifier went live, that count has been "consistently 10 to 100 times lower," which Anthropic describes as a roughly 90 to 99% drop. It says the result comes from three layers of defense, each with costs that it lays out openly.

The threat

Why the first defenses failed

Layer 1: control where reasoning can go

Attackers had been moving reasoning blocks to places where they could be exploited. One trick was pasting a protected block into a new conversation so Claude would assume the user already had the full reasoning and repeat it. Another was feeding a strong model's reasoning to an older model with weaker safeguards and asking that model to expand it. A third was moving between accounts after a ban.

Layer 2: classify and patch

Layer 3: make retries expensive

Costs and open questions

Anthropic says it has turned away "trillions of tokens' worth of paying traffic" and meaningful revenue. Legitimate users have paid too. Some developers had to change their integrations for preserved thinking, and the under-0.1% of benign requests that get misflagged are now billed. Anthropic admits this misses its February goal of leaving legitimate users unaffected.

Some limits are clear from the article. The 10–100x figure is Anthropic's own estimate and covers only its own platform. Distillers spread their traffic across third-party clouds and other inference providers. Anthropic also says it "has yet to see a highly sophisticated and persistent attempt" to get around the new defenses, and expects a cat-and-mouse game.

Its larger argument concerns industry incentives. Defenses are expensive, and distillers are paying customers, so other labs and platforms have reasons to do little. Anthropic says its work is undercut whenever attackers can get similar capability from a less-protected model, as it says Zhipu did. It is publishing its methods as evidence that a workable defense exists.

The writeup is short and mostly paraphrases a podcast. Treat what follows as a sketch of the architecture, not a detailed technical account. The article reports no benchmarks or error rates.

Long-horizon, not long-running

Here is how that might look, using a topic from the podcast: a client faces a $100,000 tax bill. (The steps below are an illustration, not taken from the article.) An agent spots the bill and drafts options. An advisor reviews them. The client takes a few days to answer. Documents come in. The agent revises its proposal. The advisor approves and carries it out. Each step may be a short agent session, and days can pass between sessions.

Only one session's worth of context fits in a model's window. So Arca keeps the state outside the model, in an internal memory system with a record for each client. Singh says it tracks "What has happened so far? What are we tracking for next? What needs to happen immediately in the next couple of days [and] what are we tracking for the long term? Which individual is responsible for which action?" The agents write to this memory themselves. In practice it works like a shared case file that any agent or person can pick up. The article doesn't say how it is stored or retrieved.

Arca uses models from Anthropic and OpenAI, with Claude as its main provider. Instead of a managed agent harness from a lab, it built its own. That harness picks a model for each task based on Arca's internal benchmarks, so routing comes from Arca's own evals, not vendor claims. Singh gives a second reason for owning it: Arca can switch model providers if it needs to. The article doesn't describe the benchmarks or how the router decides.

Deterministic guardrails

Letting agent code touch data without trusting it

Arca's answer, in Singh's words: "we have this thing which translates the code it wrote into a strict format that we expect, throw away the code, and you install guardrails on that format before it reaches your back end."

In other words, the agent's code is never run directly against the backend. Arca converts it into a constrained intermediate form, perhaps a structured query description, though the article doesn't say. It discards the original code and checks the constrained form before anything touches the data. One analogy: the agent writes a free-form request, a clerk copies it onto a standard form, and only requests that pass a check of that form reach the vault. The agent keeps most of the flexibility of code, and the backend only ever sees inputs it can validate.

Improving the harness from feedback

What's left open

The pattern is coherent: memory outside the model for multi-day work, limits enforced in code instead of in prompts, a validated intermediate layer between agent code and data, and model routing driven by internal evals. What's missing is evidence. The article gives no figures on how often proposals are accepted, how often guardrails fire, how the router performs, or what the meta-agent's suggestions have improved. These are design choices described by their builder, not measured results.

The post is a policy announcement, not a research paper. It describes what the system will do, not how well it does it. That gap matters for reading it, so it is covered at the end.

The problem: harm that isn't in one prompt

Refusing a direct request like "help me plan an attack" is the easy part, and OpenAI says its models are already trained to do it. The harder cases fall into three groups:

• Information that is legal and public but useful to an attacker. An example is a detailed reconstruction of a past mass shooting.
• Requests that are only worrying in context. A question about a building's security system means one thing from an architecture student and another from someone who spent the previous week describing anger at a coworker.
• Users who shouldn't get certain answers at all. Minors are the main case, and the system usually can't know a user's age for sure.

Each of the new measures targets one of these.

Narrower answers about past attacks, for everyone

ChatGPT will now give less detail about past mass attacks and the people who carried them out, "even if it is available from other online sources." The boundary is drawn by purpose:

• Still allowed: understanding what happened, how victims and communities were affected, recognizing warning signs, and preventing future violence.
• Now restricted: reconstructing the attacks themselves, including which weapons and equipment were used and how they were obtained, and "detailed comparisons on scale of harm."

OpenAI argues that casualty comparisons can amplify an attacker's notoriety. That reflects a well-known concern that ranking attacks by body count gives would-be attackers a target to beat. These limits apply regardless of age or stated reason. A researcher or journalist gets the same narrower answer.

Conditioning on earlier chats

In May 2026, OpenAI described letting ChatGPT store short factual summaries of warning signs from earlier conversations. A later chat can then be handled more carefully even if its prompt looks harmless alone. The new step turns that into a behavior change. When recent chats show signs of possible violence, ChatGPT responds "more conservatively" when sharing information that could be misused.

An illustrative case, not from the article: two users ask the same question about how a particular lock mechanism can be bypassed. One gets a normal answer. The other gets a guarded answer, because earlier chats from that account carry a summary noting repeated statements about wanting to hurt a specific person. The model weighs the history along with the prompt.

The same conservative mode will apply when OpenAI predicts a user is under 18, even with no violent signals at all.

Ending chats and pausing accounts

The more active intervention is automatic. When a conversation shows signs that someone is "fixating on violence or the idea of seriously harming another person," ChatGPT can end the chat. OpenAI frames this as interrupting the pattern in the moment. If several chats are ended this way, the account may be paused temporarily. That is a step short of the existing penalty: banning accounts found to violate the violent-activity policy.

OpenAI says it is developing this with mental health and violence prevention experts. It openly calls the problem unsolved. It describes "how to recognize warning signs reliably and determine when and how to intervene" as ongoing work.

Teens: restrictions without a stated threat

Parental controls let parents link their accounts to a teen's. Trained human reviewers can trigger alerts to parents for serious self-harm concerns and signs of disordered eating. Since July, parents are also alerted if a teen's account is deactivated under the violence policy. OpenAI is working on alerts for the new temporary pauses as well.

Trade-offs

Each mechanism trades over-blocking against under-blocking, and the post gives no figures for either side.

• Age prediction errors. Every adult wrongly classed as a teen loses access to ordinary information until they hand identity data to a third party. Every teen classed as an adult skips the new limits.
• Weak context signals. Conditioning on earlier chats depends on summaries that may misread dark fiction, venting or research as warning signs.
• Chat termination. Ending a chat interrupts a fixation, but it may also cut off a distressed person who was talking rather than acting.
• Determined users. The mass-attack limits hold back information that is, by OpenAI's own admission, available elsewhere. The protection comes from not making that information easier to get, not from keeping it out of reach.

What's left open

The post offers no accuracy, precision or recall figures for age prediction or the violence-fixation detector. It gives no false-positive rates and no data on how often chats are ended or accounts paused. It supports the claim that referrals help disrupt plots only with links. The 200-referral number has no denominator, such as the number of cases reviewed. The promised report is meant to fill these gaps with anonymized examples, mitigation updates and "relevant data." Whether it includes real error rates, or only case studies and counts, will show how much of this can be checked from outside.

Engineers are paid largely by story points, the relative size estimates agile teams put on tickets. The reasoning is that AI makes a skilled engineer faster, so hourly billing cuts their pay for the same work. Hess, the company's first hire, says he joined because he felt exactly that as an hourly consultant. His output was improving and he was earning less.

The obvious objections are that people will inflate estimates or ship barely passing code to collect points. Lieberman says neither has been a real problem. The reason is a counterweight: AI strategists are paid on customer retention and growth, so they push back on padded or poor work. The pay spread between the highest- and lowest-paid engineers is about 4x, not the 10x the company's name suggests.

The real problem: work that isn't a ticket

The hard case is time spent on architecture, client meetings and working out what to build. Hess says that with the right context, models now get "90% of the solution." Much of his value has moved to sitting with a customer, collecting everything they know, and turning it into context a model can use. A system built around shipped tickets has to account for that work. Tenex says it has added some nuance to the pay model while keeping output as the main driver.

How much faster, and the measurement problem

Tenex tracks average story points per engineer per month. Hess estimates output has roughly doubled this year. He dates the change to December's Claude Opus 4.5, when models began handling long-running tasks, and it continued through Opus 5.5, the team's current default.

Treat that 2x with care. Story points can deflate as models improve: the same feature gets easier, so it should be worth fewer points. Tenex recalibrates its estimation criteria at least once a quarter. That means the measure is being adjusted while it is used to measure the gain. Hess admits the calibration is "a tricky equation." The 2x is his overall impression, and the host's opening guess was +50%.

MetaHarness: the project lives in the repo

• A structured documentation tree in the repo. It centres on one canonical plan document per project. Hess says Tenex has relaxed how strictly that structure is enforced as models have improved.
• A CLI that agents use to run the work around coding: writing plans, producing visualisations, drafting client readouts.
• An opinionated logging convention. Agents record their decisions and what they are working on as they build.

All of it is committed to Git next to the code. Hess now prefers HTML output, "picture books" the agents produce, over Markdown. He rejects the view that the code alone can serve as a codebase's memory. Code shows what was built but not why, and not what the client conversation was. With plans and decisions in the repo, an agent returning to a task can read the reasoning as well as the result. Nothing important lives only in someone's head.

To make the idea concrete (an illustrative example, not from the article): an agent picking up a half-finished migration reads the plan's acceptance criteria and a log entry noting that the team rejected a queue-based design because of the client's compliance rules. It then avoids proposing that design again.

Tenex's own write-up admits this much structure can be overkill for a small team on a single project.

Tools and token spend

Where enterprises actually are

From roughly 100 enterprises Tenex talks to, Lieberman gives these figures:

• About 90% have rolled out Claude or Codex to staff.
• About 60% train people to use them.
• Only about 50% have given engineers a real coding agent.
• About 5% have an agent in production doing non-engineering work.

The host described Latent Space's "Kill My SaaS" contest, which aimed to replace a speaker-management tool quoted at about $43,000 a year. There were 72 submissions and about $1,000 in spend. The entry the human judges picked came 19th on an AI judge's leaderboard, a reminder that passing a list of scenarios is not the same as being pleasant to use. Lieberman's reply is that ripping out established software gets riskier the larger the company, and that owning a tool means maintaining it. The host argues that the real gain is being able to change a mediocre workflow in minutes rather than wait months for a vendor.

Lieberman is bearish on vertical AI products such as Harvey (law) and OpenEvidence (medicine). His questions: how do you deliver one-off solutions at software margins, and what happens when frontier models absorb the task? The host points to proprietary data, specialised interfaces and user habits, comparing it to Bloomberg terminals. Hess draws the line between products whose main feature is an agent doing a task, which he expects to struggle, and tools that reshape the workflow around the task. None of this was settled.