Deed is a contract-first programming language built specifically for scenarios where agents write code and humans review it. In Deed, a function signature is not merely a formality but a promise the compiler will honor; the function body is checked for compliance with that contract, and the language has no mechanism by which a function can exceed the scope acknowledged by its signature.
Purpose and design motivation: A large amount of code today is machine-generated. Generating code is nearly free, but reading it, trusting it, and discovering subtle errors weeks later is costly. Most existing languages are optimized for people typing character by character, and have problems such as implicit behavior, clever abbreviations, and multiple ways to write the same expression. Deed makes different trade-offs: the signature carries the complete contract, the function body is checked, and a function cannot accidentally or deliberately access external capabilities not permitted by its signature (such as the network). This makes a sandbox no longer merely a container, but a type.
Main capabilities:
- The compiler performs lexical analysis, syntax analysis, name resolution, type checking, contract checking, and effect row checking;
- Runnable programs, with support for a reference interpreter or a WebAssembly backend;
- deed build writes out core modules, and --component writes out components when exported values cross the canonical ABI;
- Programs obtain permissions through explicit capabilities, and both engines use the same host rules;
- deed review compares the set of checked modules before and after a change, generates a receipt, and points out newly declared permissions as well as obligations whose contract level has been downgraded; it supports --format json to output a stable object, and provides policy gates such as --deny-new-authority, --deny-weaker-promises, and --deny-new-guarded;
- deed mcp implements the Model Context Protocol over stdin/stdout, allowing coding agents to ask the compiler directly instead of scraping information from terminal output; it holds no capabilities, programs enter as text and answers leave as text, and if a program's effect row involves files it will be rejected before running;
- The language server deed lsp provides diagnostics, type hover, go to declaration, find references, rename, completion, quick fixes, formatting, outline, and other features;
- Editor support includes VS Code syntax highlighting and a language server client; Helix and Neovim can start the language server with a small amount of configuration, with no plugin required;
- A std library documentation index, and deed doc can generate documentation pages for any module.
How to use: Installation: in On Linux or Apple silicon Mac, a single-line command can download the release asset for the corresponding machine, verify that the hash matches the release, and place a single file into the user directory without requiring a password; you can also manually download the deed binaries for Linux, macOS, and Windows from the releases page, unzip and use immediately, and the compiler, formatter, test runner, and language server are all in that single file. When using Rust 1.88 or newer, it can be obtained from crates.io or by cloning, the package name is deed-lang, and the installed binary is deed. Starting a project: deed new will write out a project, and the name also serves as the directory and module path. There is no manifest file, because a manifest only indicates the location of code outside the dependency tree, and a new project has no dependencies. Quick experimentation: there is no REPL. Deed input is declaring modules, deed run enters from main, and top-level expressions are not evaluated. You can use a temporary .deed file together with deed check, deed test, or deed run.
Applicable scenarios: Suitable for scenarios where agents generate modules and humans review changes; suitable for codebases that need strict contracts, effects, and capability constraints; suitable for teams that want signatures rather than function bodies as the focus of review; suitable for CI processes that need change receipts for agent patches.
Limitations and status: The toolchain is usable, but adoption is an open question; outside this organization, no known Deed source code has yet been included in public repositories. The largest unfinished technical work is value reclamation and broader component adapters. The version is 0.x, the language may still change, files that compile in one minor version may fail to compile in the next minor version, breaking changes will be noted in the release notes, and deed fix handles the mechanical parts as much as possible. The checksum comes from the same source as the released binary and can only detect corrupted downloads, not a compromised release. Each .deed file in the repository is written by one person, which is the language's biggest open question; the benchmarks directory provides a set of tasks and graders to quantify this. User-visible changes to the language, diagnostics, libraries, and tools are recorded in CHANGELOG.md.
Detailed design documents, tutorials, how-to guides, and the standard library API are in the corresponding files in the repository.
