Agent-first language, protocol, and runtime for building software with explicit side effects, capability security, and replayable execution.
Latch is a stack, not a library. It targets the failure modes of agent-built systems: ambiguous intent, unsafe tool use, brittle coordination, and non-reproducible runs.
Latch provides:
- A programming language designed for machine generation and strict parsing.
- A contracts layer for agent-to-agent messages and tool schemas.
- A deterministic runtime that enforces permissions, budgets, and provenance.
- A tool gateway that is the only place side effects are allowed to happen.
- A provenance + replay log for audit, debugging, and reproducibility.
This repository is a design + reference implementation scaffold. Expect sharp edges.
- Make side effects explicit and reviewable.
- Make permissions unforgeable through capabilities.
- Make runs reproducible through record/replay.
- Make multi-agent coordination contractual rather than conversational.
- Make “safe by default” the path of least resistance for agents.
- Replacing Rust/Go/Python for general-purpose human development.
- Hiding costs and side effects behind magic “agent autonomy”.
- Solving trust between mutually adversarial parties without policy and isolation.
| Component | Role |
|---|---|
LatchLang (.lch) |
Deterministic, canonicalized language with explicit effects and typed tool calls |
| LatchSpec | IDL for tools, effects, policies, agent messages, receipts, and contracts |
| LatchVM | Runtime that executes Latch bytecode/WASM and enforces effect rules |
| LatchKeys | Capability + policy + secrets issuance service (scoped, time-limited authority) |
| LatchGate | Tool gateway and adapters (net, fs, git, browser, payments), with redaction and rate control |
| LatchLog | Append-only provenance store: inputs, tool transcripts, hashes, model/tool versions, replay snapshots |
| LatchFlow | Workflow/orchestrator: retries, timeouts, checkpoints, sagas, queues |
| LatchRegistry | Signed packages, pinned deps, reproducible builds |
| latch (CLI) | Build/run/test/replay/sign tooling |
Latch splits “decide” from “do”.
- LatchLang + LatchVM: pure logic, deterministic evaluation, explicit effect intent.
- LatchGate: the only component allowed to perform I/O.
- LatchKeys: controls authority by issuing capabilities.
- LatchLog: records everything needed to replay and audit.
- LatchFlow: manages long-running workflows, retries, and compensation.
Functions declare the kinds of side effects they may trigger. Tools declare effects and policy constraints.
No ambient authority. A workflow cannot read files, call the network, or write a repo unless it holds the corresponding capability value.
Every tool call and resulting artifact is hashed and logged. A run is inspectable and replayable.
The runtime can re-run a workflow using recorded tool responses, producing identical results.
A minimal workflow that fetches a URL, produces a summary, then proposes a patch to a git repo. The write path requires review by policy.
tool FetchUrl(net: NetCap, req: HttpRequest) -> Result<HttpResponse, FetchErr>
effects [Net]
policy { max_bytes: 2_000_000, pii: "deny" }
tool ProposePatch(git: GitCap, patch: RepoPatch) -> Result<PullRequest, GitErr>
effects [FS, Exec]
policy { require_review: true }
workflow SummarizeAndPropose(net: NetCap, git: GitCap, url: Url) -> Result<PullRequest, Err>
effects [Net, FS, Exec]
{
checkpoint "fetched"
let resp = FetchUrl(net, { method: "GET", url })?
retry 3 backoff exp(250ms..4s)
let doc = parse_html(resp.body)?
let summary = summarize(doc, budget_tokens: 1200)
checkpoint "proposed"
let patch = make_patch_from_summary(summary)
ProposePatch(git, patch)?
}
Properties visible at a glance:
- Network access is explicit through
NetCap. - Repo mutation is explicit through
GitCap. - Retrying is structured.
- Review gating is a policy on the tool, enforced by the runtime.
- Authority is represented by capability values issued by LatchKeys.
- Least privilege is practical because capabilities are narrow and composable.
- Policy is enforced at the tool boundary in LatchGate and validated by LatchVM.
- Redaction and egress rules live in LatchGate and are logged in LatchLog.
The core language is deterministic. Nondeterminism must be introduced explicitly through tools or primitives that are treated as effects and recorded in the log.
Recorded tool transcripts enable replay even when the real world changes.
LatchSpec defines:
- Message schemas for requests, offers, acceptances, and receipts.
- Tool schemas and effect signatures.
- Contracts for commitments, deadlines, and deliverables.
- Hash-based receipts for artifact integrity.
Agent-to-agent messages are treated as typed inputs with provenance, not free-form instructions.
Planned commands:
latch fmt # canonical formatting
latch build # compile and sign artifacts
latch run # execute with a policy profile
latch test # deterministic tests with replay fixtures
latch replay <run> # re-run using recorded tool transcripts
latch sign # sign packages and run manifests
latch inspect <run> # view provenance, tool calls, and artifacts/lang LatchLang parser, formatter, type checker
/spec LatchSpec schemas and codegen
/vm LatchVM executor and effect enforcement
/keys LatchKeys capability issuer and policy engine
/gate LatchGate tool adapters and redaction
/log LatchLog storage backend and query tools
/flow LatchFlow orchestration and queue adapters
/registry LatchRegistry signing and package metadata
/cli latch command implementation
/examples end-to-end sample workflows
- Proposals should include: syntax impact, typing rules, effect implications, and replay/provenance behavior.
- Tool additions must include: schema, effect list, policy surface, and redaction plan.
- Breaking changes require: migration plan and canonical formatting stability notes.
TBD.