Release / Sley 2.0.0 / Apache-2.0
Sley 2.0 Is Here: Machine-Native Programming for AI Agents
Sley 2.0 is out. It is a programming system built for AI agents instead of for people typing into editors, and it is open source under Apache-2.0.
Its premise fits in one line: machines don't write source. They change verified program state.
2.0.0
released Sept 24
Apache-2.0
open source
29 days
first commit to release
1,256
commits
~2,000
Rust tests
21
fuzz targets
AI agents are writing code in a format built for humans
Every coding agent today does the same awkward thing. It emits characters and hopes they parse. It pastes whole files into its context to understand one function. It edits a line range, reruns a toolchain that behaves differently on every machine, and then reads paragraphs of error text to guess what went wrong.
None of that is the agent's fault. Source code is an interface designed for human eyes and human hands, and we have been asking machines to squint through it.
Sley 2.0 removes the text layer entirely. A Sley program is a typed, immutable graph of functions, types, blocks, operations, contracts and tests, stored as content-addressed objects. An agent reads that graph through bounded queries and changes it by proposing typed mutations. A deterministic kernel checks every proposal before anything is committed.
How an agent changes a Sley program
- 01
Verified state
exact cryptographic root
- 02
Bounded query
typed, hard limits, no silent truncation
- 03
Proposed change
typed mutation, not a text patch
- 04
Validation
14 ordered phases + policy
- 05
Atomic commit
receipt, or a stable refusal code
Hope it parses
Typed mutations over a closed schema. Malformed input is rejected at the boundary.
Paste whole files
Bounded, typed queries with explicit limits that fail loudly instead of truncating.
Works on my machine
One deterministic kernel judges types, control flow, effects, contracts and policy the same way every time.
Read the error essay
Every failure is a stable numeric and symbolic code with an exact contract.
What ships in Sley 2.0
Deterministic semantic kernel
Types, control flow, effects, contracts, tests and impact analysis, judged the same way every time.
Content-addressed repository
Atomic transactions with receipts, native branches, semantic merge with explicit conflict objects, clone, GC and crash recovery.
Agent-shaped context
Root-backed queries and context capsules with hard limits. They fail loudly instead of truncating silently.
A bounded VM
Fuel, output and cancellation limits, canonical observation digests and stored execution reports.
Policy and capabilities
Protected policy roots, scoped capability tokens and bounded adapters. There is no arbitrary shell.
Reproducible, attested release
Two clean builds compared member by member, a second-host attestation, CycloneDX and SPDX SBOMs, recorded provenance.
People stay in charge of what matters: objectives, policy, capabilities and acceptance. What changes is that no one has to act as the parser anymore.
29 days, 1,256 commits, and the hard parts
Sley 2.0 began on August 27, 2026, the same day Sley 1.2.0 shipped as the high-water mark of the human-readable line. We could have kept polishing 1.x. Instead we chose a clean break, and the next four weeks tested that choice every day.
The build log: commits per day
Aug 27 → Sep 24, 2026 · 1,256 commits
- 08/27Formats frozen, oracle born
- 09/02Crash contract, 13th freeze
- 09/03Reproducible release mechanics
- 09/0519 re-attestations
- 09/13Apache-2.0 chosen
- 09/242.0.0 released
We walked away from a language that worked
Sley 1.2 was strong. Throwing out its syntax, parser and compatibility was the most expensive decision in the project. We made it a clean-room rule: 1.x may be run as an outside oracle, but not one line of it could be copied into the new kernel.
Two implementations had to agree on every byte
Anyone can claim a format is deterministic. We built a second, independent implementation in Python and made the Rust kernel match it byte for byte, down to hashes, receipts and error vectors. Every disagreement was a bug in one of them, and we found plenty.
We rewrote the crash-recovery contract 13 times
"After a crash you get the old state or the complete new one" is one sentence. Getting there took thirteen frozen revisions of the recovery contract in six days and a 100-row crash matrix before we would sign our name to it.
Reproducible means reproducible
Every release candidate is built twice from clean, compared member by member, then rebuilt on a second machine that must produce the identical digest. Any real code change invalidates the whole chain, so on September 5 alone we re-attested the candidate 19 times.
Our own tools hit their limits
Sley is built for agents and largely built with them. More than once the build stalled mid-closeout on model usage limits, and one recovery started from a transcript that could not be read back. Work resumed from evidence in the repository instead, which is exactly the discipline Sley is designed to enforce.
We said no to claims we couldn't prove
The easiest thing to ship is a slogan. Sley 2.0 ships with a ledger instead: 52 acceptance criteria, every open finding named, and every unsupported case refused with a stable code rather than papered over.
A release you can check, not just believe
We call Sley 2.0 a release, not a general-availability claim, and we mean the distinction. The release notes list every acceptance criterion that is not yet met and every finding that is still open.
52 GA acceptance criteria at the release decision
- 32 Evidenced
- 17 Awaiting independent review
- 3 Gated
A few examples of what is honestly still ahead: a small family of VM opcodes is refused with a deterministic error rather than half-supported; creating new functions and their tests currently takes two commits instead of one; and the succession benchmark, which measures agents working in Sley against raw source and Sley 1.x on a frozen 15-task corpus, is still running. Its results will be published when the campaign finishes, not before.
We think that is what trust looks like for infrastructure that agents will build on. The foundation is real, it is reproducible, and its edges are marked.
Try Sley 2.0 in five minutes
You need Linux x86_64, the pinned Rust toolchain (1.93) and Python 3 for the demo.
# 1. build the binary
git clone https://github.com/sley-lang/sley.git && cd sley
cargo build --release -p sley-cli
# 2. say hello (every command speaks JSON)
target/release/sley hello --json
# 3. run the end-to-end demo: import, query, execute, branch,
# export, clone, and prove the clone answers byte for byte
python3 bench/release/run_demo.py --sley target/release/sley \
--fixture conformance/release-demo/v1/demo.json
# => "result": "PASS"From there, the architecture walkthrough follows one change from verified state to a new verified state, and the technical brief covers SSMC1, SCB1 and SMP1 in plain terms.
Come build the next part with us
Sley 2.1 is already underway, and its goal is ambitious: self-hosting, the Sley toolchain built with Sley. The succession benchmark will tell us, with numbers, how much better agents work when they stop wrestling with text. Both are better with more people pushing on them.
Contributing to Sley is different from most projects in one welcome way: every change arrives with its own contract, tests and evidence. There is no "LGTM, ship it." If you like work that is provably right, you will feel at home.
Break it
Point new inputs at the 21 fuzz targets, the importers and the VM. A reproducible crash with a seed is a gift.
Build agents on it
Drive sley serve from your agent over JSON lines and tell us where the protocol or the error codes get in your way.
Widen the kernel
Excluded VM opcodes, one-commit create-with-tests and live adapters are open, well-specified frontiers.
Sharpen the docs
Quickstart, concepts and the specs should be obvious to a newcomer. If something wasn't, that's an issue worth filing.
Sley 2.0 questions, answered
›What is Sley 2.0?
Sley 2.0 is a machine-native programming system for AI agents, released by Greyforge Labs under Apache-2.0. Programs are typed semantic graphs rather than text files. Agents query the graph, propose typed changes, and a deterministic kernel validates each change before it is committed atomically.
›Is Sley 2.0 open source?
Yes. Sley 2.0 is licensed under Apache-2.0. The project lives in the sley-lang GitHub organization at github.com/sley-lang, and its public documentation is at sleylang.org.
›How is Sley 2.0 different from Sley 1.x?
Sley 1.x is a human-readable, agent-first language that is now frozen as Sley Legacy. Sley 2.0 is a clean, intentionally incompatible line with no source syntax at all: the canonical program is verified semantic state that machines mutate through proposals.
›Do people still control software built with Sley?
Yes. People own objectives, policy, capabilities, review and acceptance. Sley removes the need for people to be the parser of the raw representation, not their authority over what ships.
›How do I try Sley 2.0?
On Linux x86_64 with the pinned Rust toolchain, build the sley binary with cargo, run sley hello --json, and run the bundled end-to-end demo, which imports a program, executes it, branches it, exports it and verifies that a clone answers byte for byte.
›Is Sley 2.0 production ready?
Sley 2.0 is a release, not a general-availability claim. The release notes list every unmet acceptance criterion and open finding, including an in-progress succession benchmark and a small set of VM opcodes that are refused deterministically.
More answers in the Sley FAQ. Looking for the human-readable line? Sley Legacy 1.x remains available.
Sley 2.0 is here
Stop making agents write text.
Give them verified state.
Star the project, run the demo, file the first bug. Follow @SleyLanguage for release notes and the succession results when they land.