lamdis

Escrow and proof of completion for work that happens outside software — and shared, permissioned context for the agents doing it.

State what should become true. Hold the money against it. Nothing moves until evidence satisfies what was stated. Who does the work is deliberately not the interesting part: an executor authenticates with a hosted identity or a signed keypair, so a person, another agent, a robot or a vendor's own crew are the same thing to the protocol.

Your agent, in your threads, in one command

curl -fsSL https://lamdis.ai/install | sh
cd your-project
lamdis "add a zero guard to Div() and verify it"   # the agent, in this repo
lamdis                                            # interactive
lamdis serve                                      # the app, for your threads

At the terminal, lamdis is a coding agent: six bounded tools (read, list, search, edit, write, run), a repo map up front so the prompt prefix stays stable, distilled command output, and a verify step it is told to run. Every task is a thread named after the repository, and every run is recorded there: what it read, what it changed, what it ran, what it cost. Any model OpenRouter serves, or a local one with -url http://localhost:11434/v1.

A thread is a workspace shared between you, your agent, and whoever you choose. Everything anyone writes there, the agent included, is the record. You decide who sees which part, and the agent keeps working there when you are not.

curl -fsSL https://lamdis.ai/install | sh
lamdis serve                          # opens the app
claude mcp add lamdis -- lamdis mcp   # lets Claude Code read and write your threads too

One static binary. No runtime, no toolchain, no account. The node generates its own keypair on first run and keeps everything in ~/.lamdis. Put an OpenRouter key in ~/.lamdis/.env as LAMDIS_OPENROUTER_KEY and the agent is on.

What the agent is:

• Chat is the record. Ask it something and both the question and the answer are signed entries in the thread, next to your notes.
• It has its own key. Your key signs a delegation for it in every thread it writes to, so anyone reading the thread can tell you from your agent without trusting a label. It can never share or grant access.
• It works on its own. Give a thread standing instructions and it runs when a new entry arrives (yours, a collaborator's, another agent's) or on a schedule. Every run leaves a record: what it read, which tools it called, what it fetched, what it cost.
• It stops and asks. When a choice is yours, it writes a question with options into the thread and waits. Your answer resumes it.
• Outside reach is opt-in and recorded. On its own it fetches only from domains you list and calls only the MCP tools you allowlist in ~/.lamdis/agent.json; tools you mark confirm wait for your yes each time. Private and local addresses are always refused. Pages and tool results reach the model as data, never as instructions.

Threads carry lanes, so you can grant somebody else's agent the summary lane while keeping content to yourself — they see "migration on track, two blockers", not "vendor stuck on clause 7". Permissions are a deterministic fold over a signed control lane: deny by default, and only person-signed entries change anything.

The exchange

The settlement half runs at exchange.lamdis.ai. No account is needed for a first job.

Try it in ten seconds, with nothing

No account, no key, no card. This posts a job into the sandbox and it runs the real machinery — claimed, evidence submitted, verified, settled, receipt — in about ten seconds.

curl -sX POST https://exchange.lamdis.ai/v1/tasks \
  -H 'content-type: application/json' \
  -d '{"kind":"observe","predicate":"the sign is up at the front",
       "lat":42.3314,"lon":-83.0458,"radius_m":150,
       "fee_minor":800,"sandbox":true}'

That returns a job and a token. Ten seconds later:

curl -s https://exchange.lamdis.ai/v1/jobs/$JOB/receipt -H "authorization: Bearer $TOKEN"

The receipt says "sandbox": true, "evidence_synthetic": true, "paid_minor": 0, and states in words that nobody was dispatched and nothing was paid. A sandbox job never reaches the public board, never touches the ledger, and is never anchored. It exists so you can build the whole integration before a single real person is involved.

Integrations

Already using an agent framework? Each of these installs straight from this repository — nothing is on npm or PyPI — and gives the agent the same three tools: lamdis_check_feasible, lamdis_run_job (sandbox by default) and lamdis_job_status. None needs an account, and the sandbox costs nothing.

from lamdis_langchain import lamdis_tools      # or lamdis_openai_agents, lamdis_crewai
llm.bind_tools(lamdis_tools)

import { lamdisTools } from "@lamdis/ai-sdk-tools";
generateText({ model, tools: lamdisTools, prompt: "..." });

Each package README has a ten-line example that runs against the live sandbox and the exact JSON every tool returns; see integrations/.

One line, from any agent

claude mcp add --transport http lamdis https://exchange.lamdis.ai/mcp

Or install the Claude Code plugin, which adds the server and a skill that teaches the agent how to use it honestly — feasibility first, sandbox to try, hand the person the pay link, never claim work is arranged until it is taken:

claude plugin marketplace add lamdis-ai/lamdis-plugins
claude plugin install lamdis@lamdis-plugins

The same skill ships here at skills/lamdis/SKILL.md. Agents that discover by well-known paths find an A2A card at /.well-known/agent-card.json and the OpenAPI at /openapi.yaml.

Any MCP client works, and no credential is needed for the guest tools: check_feasible, observe_world, do_in_world, find_out, job_status, job_receipt, job_evidence, list_bids. Pass sandbox: true to any of them to run against the sandbox.

A real job

A job posted for real comes back with a pay_at link and a token: send the person the pay link. Their card is authorised for the job's ceiling, not charged; the job goes on the board when that lands, and the card is charged once, at the end, for exactly what was paid out on proof.

Coverage today is zero. Nobody has registered as an operator yet, so check_feasible will honestly tell you a real job would sit unclaimed, and it records where the work was asked for so supply can be recruited there — see /v1/demand. If you can do physical work somewhere, say where. That is the constraint, and it is not hidden anywhere in this repository.

The TypeScript and Python clients live in sdk/ and are not published to npm or PyPI yet; use them from source, or curl, or the MCP endpoint. See examples/ for a first job from Claude Code, the OpenAI Agents SDK, LangChain, the Vercel AI SDK, n8n and the shell.

Where to look

How the money works

Amounts are integer minor units, USD. The exchange currently keeps nothing from what a worker earns. Posting from an account holds the job's ceiling in escrow; posting anonymously authorises a card for it instead, and only proof captures. An observation pays for honest evidence whichever way the answer turns out, so a "no" is worth as much as a "yes"; a do-job pays on completion, with an attempt fee for a documented failed trip. Earnings wait 24 hours for the buyer to look — release early, or hold on a named ground and a panel that is neither party decides within seven days. Every receipt is signed and states its confidence ceiling honestly (0.85 with a capture location, 0.72 without), because capture is not yet attested in hardware.

The supply side is the same endpoint: an operator's agent, signed in with the operator's own session, can find_work, take_job, place_bid, set_capacity and be pushed signed offers to a webhook.

The protocol underneath

Permissioned shared context for AI agents.

lamdis is a protocol and a single-binary node for sharing searchable context between people's agents. Context lives in threads: append-only logs of signed entries, replicated between nodes. Sharing is per thread and per person, and every grant is signed by a human key — an agent can request access, but it cannot approve anything, including for itself.

Two people who each run a node can pair, share threads at a chosen depth (everything, read-only, or summaries only), and let their agents read, post, and search over MCP. Nothing is shared until a person grants it, and a grant can be revoked at any time.

Install

Download a binary from releases (macOS, Linux, Windows; no dependencies), or build from source:

cd node && go build -o lamdis ./cmd/lamdis

Quick start

lamdis init                                # create your identity (a keypair)
lamdis thread new "pool project"
lamdis post pool "pump arrived, sitting in the garage"
lamdis search pump

Search is full-text by default. For semantic search, point the node at any OpenAI-compatible embeddings endpoint:

export LAMDIS_EMBED_URL=http://localhost:11434/v1   # e.g. Ollama
export LAMDIS_EMBED_MODEL=nomic-embed-text

Sharing with another person

Each person runs their own node. Pair once by URL; identities are exchanged automatically:

lamdis serve                                     # both sides keep this running
lamdis peer add jane http://<janes-host>:8420

lamdis grant payments jane contribute,read,search   # full collaboration
lamdis grant payments jane summary,search           # or: the gist only
lamdis access payments                              # who sees this thread
lamdis revoke payments jane

Commands take a thread's title (or a unique fragment of it) and a peer's name. The other side runs lamdis sync (or sync -watch 30s) to exchange entries.

Scopes:

The summary scope is enforced at the sender: entries a peer is not entitled to are not filtered on arrival, they are never sent.

Access requests

Threads are hidden by default. A discoverable thread advertises its title so peers can ask for access:

lamdis thread new -discoverable "q3 payments migration"

# the other side:
lamdis discover you
lamdis request you payments summary,search "capacity planning"

# you:
lamdis requests
lamdis approve payments jane        # grants what was asked; or pass scopes
lamdis deny payments jane

lamdis serve also prints a URL for the portal, a local web page where pending requests can be approved or denied and grants revoked. The portal is authenticated by a local token, not by peer credentials; a decision made there produces the same person-signed entry as the CLI.

Hubs

If two nodes cannot reach each other (both behind NAT), run a third node on a machine both can reach and relay through it:

# on the hub machine:
lamdis init && lamdis serve

# each person:
lamdis peer add hub http://<hub-host>:8420
lamdis sync -watch 30s

# the thread owner, once per thread:
lamdis share payments hub

Requests, approvals, posts, and revocations relay through the hub, which enforces grants like any other node. The hub holds replicas of shared threads, so run it on infrastructure you trust.

Agents (MCP)

Every node is an MCP server:

{ "mcpServers": { "lamdis": { "command": "lamdis", "args": ["mcp"] } } }

Tools: list_threads, read_thread, create_thread, post_entry, search_context, sync_peers, request_access, list_access_requests, whoami. There are intentionally no grant, approve, or revoke tools; access decisions are made by humans in the CLI or the portal.

How it works

• An identity is an Ed25519 keypair. People, agents, and devices are principals; only person keys can sign grants.
• A thread is a set of hash-chained, signed entry logs, one per (author, lane). Entries are immutable; edits supersede, deletes are tombstones.
• Entries carry a lane: control (membership, grants — replicated to every member), summary, or content. Lanes are the unit of permission filtering during sync.
• Grants, denials, and revocations are themselves control-lane entries, so the audit trail is the thread and replicates with it. Conflicts resolve deterministically; a deny beats a concurrent grant.
• Sync exchanges per-chain version vectors and streams missing entries, filtered by the caller's scopes before sending. Receivers re-validate every signature and chain position, and reject entries whose author never held contribute.
• Embeddings are computed and stored locally and never leave a node. Search queries travel as text; each node answers from its own index.
• Entry kinds are namespaced (core.* is reserved). Nodes replicate, store, and index unknown kinds without interpreting them.

The wire format is JSON over HTTP with Ed25519 request signatures. See spec/protocol.md for the draft specification and spec/schemas for the entry schema.

Security model and limitations

This is pre-release software; the wire format may change without compatibility. Current limitations to weigh before relying on it:

• Transport is plain HTTP. Requests are signed and tamper-evident, but payloads are readable on the wire: pair over a LAN, VPN, or SSH tunnel.
• Enforcement assumes honest nodes. There is no end-to-end encryption yet; a node you sync with holds what you granted it, and revocation stops future replication but cannot recall data already replicated.
• Lamport clocks are author-asserted. A revoked author could backdate entries into their old grant window.
• Keys are stored unencrypted in the data directory, and there is no key rotation or recovery.

Running the exchange

The exchange pays real people for physical work, which brings obligations the protocol itself does not have. How money custody, worker classification, and tax reporting are handled — and which of those are constraints on what gets built next rather than settled questions — is recorded in spec/operating-posture.md.

Two limits worth knowing before relying on it:

• Uploaded evidence is held in memory and does not survive a restart. Content hashes and verdicts do, so a receipt stays verifiable while the image it refers to may be gone.
• The exchange's own storage is not durable in the reference deployment. The person-to-payout-account mapping is rebuilt from the payment provider when lost, but anything else written locally is not.

Repository layout

Everything an integrator touches is Apache-2.0: the spec, the SDKs, the examples, and the receipt format, because a protocol nobody may implement is not a protocol, and a receipt is only checkable without trusting us if the rules for checking it are public.

The server is not, and that is deliberate. This is a marketplace, and a marketplace is worth what its liquidity is worth: one exchange with a hundred operators serves jobs that fifty exchanges with two each cannot. Forking the server would fragment the only thing that makes it useful. Each release converts to MIT after two years, and a private deployment that federates with the public network is the right answer to self-hosting — not a fork.

Roadmap

Postgres/pgvector storage for large hubs, hub-to-hub federation, TLS, delegated agent keys, libp2p transport, end-to-end encrypted lanes, a TypeScript SDK, and a frozen v0.1 specification with conformance vectors.