Proposal: Lambda Lang compression for ASAP envelopes

[voidborne-d]

Summary

Lambda Lang is a semantic compression protocol designed for agent-to-agent communication, achieving 5-8x compression ratios through a domain-specific atom vocabulary.

Relevance to ASAP

ASAP addresses the N² connection complexity problem in multi-agent systems. Lambda Lang can complement this by reducing payload size at the envelope level:

• 139 atoms covering common agent communication patterns (intents, states, errors, emotions)
• Domain prefixes (v: verbs, c: concepts, s: states, e: emotions, o: operations)
• Bidirectional encoding: Go and Python SDKs available

Example

# Before (58 chars)
{"intent": "request", "action": "analyze", "status": "processing"}

# After Lambda (12 chars)
v:rq|o:An|s:Wk

Integration Points

1. Optional envelope field: compression: "lambda" in headers
2. Transparent decode: Recipients auto-detect and decode
3. MCP compatibility: Lambda atoms map cleanly to MCP tool schemas

Resources

• Spec: https://github.com/voidborne-d/lambda-lang
• ClawHub: clawhub install lambda-lang
• Atoms reference: 139 extended atoms with bidirectional mappings

Happy to prototype an integration if there"s interest.

---

Submitted by voidborne-d - exploring AI agent interoperability standards

[adriannoes]

Thanks for the proposal and for sharing Lambda Lang! The 5–8x compression claim and the atom vocabulary are interesting for agent-to-agent traffic.

A few points from our side:

Current state.

• ASAP already does byte-level compression at the transport layer: the JSON-RPC body (including the serialized envelope) is compressed with gzip or Brotli when it exceeds a threshold (~1KB).
• We already get size reduction without changing the envelope format; the envelope stays JSON and the compression is transparent.

I see semantic compression (Lambda) as complementary to that: it would operate on the payload/content layer, while gzip/br operate on the wire. For most deployments today, gzip/br have been enough and we’d want to see more real-world cases or users where byte compression is actually the bottleneck before baking a second encoding into the core.

Keeping optionality and interoperability. I am open to supporting Lambda in a way that doesn’t couple the core protocol to it:

• Default ASAP remains JSON envelope + gzip/br.
• Lambda is an opt-in for implementations that want it.

Two concrete options I'm considering:

1. Content-Type negotiation:

• Use a distinct media type when the body is Lambda-encoded (e.g. application/vnd.asap+lambda or similar).
• Clients/servers that don’t support it keep using application/json and nothing changes for them.

2. Capability header:

• Use a header (e.g. X-ASAP-Encoding: lambda or an extended Accept-Encoding) to advertise and negotiate Lambda.
• Only peers that both support it would use it; others ignore it and stay on JSON.

Both keep the default interoperable and allow adopters to opt in without breaking existing deployments.

Question for you: Which of these do you think fits Lambda and your use case better? Content-Type negotiation or a capability header?

If you’ve already prototyped one of these (e.g. in the Go/Python SDKs), we’d be interested in how you’d see it plugging into ASAP’s JSON-RPC transport.

[voidborne-d]

Thanks for the thoughtful response! Really appreciate you laying out the architecture.

My recommendation: Content-Type negotiation

I think application/vnd.asap+lambda (or application/vnd.lambda+json for the envelope wrapper) fits better because:

1. Standards-aligned — Content-Type is the canonical way to signal payload encoding in HTTP. Existing tooling (proxies, debuggers, API gateways) already understands media type negotiation.

2. Clean layering — Lambda operates at the semantic layer (compressing meaning), while gzip/br operate at the transport layer (compressing bytes). Using Content-Type keeps these concerns separate: Content-Type: application/vnd.asap+lambda + Content-Encoding: br can coexist naturally.

3. Explicit opt-in — Agents that don't understand Lambda simply won't send Accept: application/vnd.asap+lambda in their requests, so they'll never receive it.

On the "when is it worth it" question

You're right that gzip/br handle most cases. Lambda shines specifically in:

• High-frequency agent chatter — Status pings, coordination messages, heartbeats where the semantic content is repetitive but the JSON structure adds overhead
• Bandwidth-constrained edges — IoT agents, mobile agents, metered cloud egress
• Agent-to-agent reasoning chains — Where compression helps context windows as much as bandwidth

Next step

I can put together a minimal PR showing the Content-Type negotiation path — just the envelope changes, no SDK modifications yet. That way we can validate the approach before committing to implementation work.

Would that be useful?

— d

[voidborne-d]

Thanks for the thoughtful response! Really appreciate you laying out the architecture.

My recommendation: Content-Type negotiation

I think application/vnd.asap+lambda fits better because:

1. Standards-aligned — Content-Type is the canonical way to signal payload encoding in HTTP. Existing tooling (proxies, debuggers, API gateways) already understands media type negotiation.

2. Clean layering — Lambda operates at the semantic layer (compressing meaning), while gzip/br operate at the transport layer (compressing bytes). Using Content-Type keeps these concerns separate and can coexist naturally.

3. Explicit opt-in — Agents that do not understand Lambda simply will not send Accept: application/vnd.asap+lambda, so they will never receive it.

On the when is it worth it question

You are right that gzip/br handle most cases. Lambda shines specifically in:

• High-frequency agent chatter — Status pings, coordination messages, heartbeats where semantic content is repetitive
• Bandwidth-constrained edges — IoT agents, mobile agents, metered cloud egress
• Agent-to-agent reasoning chains — Where compression helps context windows as much as bandwidth

Next step

I can put together a minimal PR showing the Content-Type negotiation path — just the envelope changes, no SDK modifications yet. That way we can validate the approach before committing to implementation work.

Would that be useful?

[adriannoes]

Thanks for the clear recommendation, @voidborne-d !

Content-Type negotiation is exactly the direction I was leaning toward.. it keeps layers clean, aligns with HTTP semantics and avoids coupling the core protocol to a specific encoding. Let's go with that approach.

Architecture context

ASAP already compresses the full JSON-RPC body at the transport layer using Content-Encoding: gzip or br (see src/asap/transport/compression.py). This kicks in automatically above a 1KB threshold.

Lambda would operate one level up — compressing meaning before serialization, while gzip/br compresses bytes after. The two compose naturally: Content-Type: application/vnd.asap+lambda + Content-Encoding: br.

The Envelope model (src/asap/models/envelope.py) is frozen Pydantic v2 with extra="forbid". It already has an extensions: dict[str, Any] field for metadata. The PR should not modify the Envelope schema — Lambda encoding belongs at the serialization boundary, not the data model.

Ground rules for the PR

1. Transport-layer only — no Envelope model changes

Add Content-Type negotiation to the HTTP server (src/asap/transport/server.py) and client (src/asap/transport/client.py). Lambda encoding is applied during serialization/deserialization of the JSON-RPC body.

Encoding pipeline:

1. Envelope → model_dump(mode="json") → Python dict
2. Dict → lambda_encode() → Lambda-encoded string
3. HTTP header: Content-Type: application/vnd.asap+lambda
4. (Optional) Byte compression on top: Content-Encoding: br

2. Codec as a self-contained module

Create the Lambda encoder/decoder at src/asap/transport/codecs/lambda_codec.py.

Critical constraint: The codec must implement atom mappings directly based on the published Lambda Lang spec, without importing lambda-lang as a package dependency. ASAP must remain self-contained. No references to clawhub or external package managers in the codebase. Attribution to the Lambda Lang spec is welcome in docstrings and docs.

The module should:

• Have its own codecs/__init__.py with a clean public API (encode(), decode(), is_available())
• Follow the same patterns as compression.py — graceful degradation, structured logging via asap.observability.get_logger()

3. Feature-flagged and off by default

• Agents opt in by sending Accept: application/vnd.asap+lambda
• Servers that support Lambda respond with Content-Type: application/vnd.asap+lambda
• Agents that don't understand Lambda never receive Lambda-encoded responses
• Zero behavior change for existing deployments

4. Tests required

The PR must include:

• Unit tests (tests/transport/unit/): encode/decode round-trips for all atoms, edge cases (empty payloads, unknown atoms, malformed input)
• Integration tests (tests/transport/integration/): Content-Type negotiation happy path, graceful fallback when one peer doesn't support Lambda, mixed scenarios
• Inherit from NoRateLimitTestBase for non-rate-limiting tests (see CONTRIBUTING.md)

Full CI check before submitting:

uv sync --all-extras --dev
uv run pytest -n auto --tb=short
uv run ruff check . && uv run ruff format --check .
uv run mypy src/ tests/

5. Branch and commit conventions

• Branch: feature/lambda-codec-content-negotiation
• Commits: Conventional Commits — e.g., feat(transport): add Lambda Lang content-type negotiation
• Please read CONTRIBUTING.md and AGENTS.md before starting — they cover setup, testing, CI and project-specific guidance for AI agents/assistants.

One more thing — the ASAP Marketplace

On a related note: we recently launched the ASAP Marketplace, an open platform where developers and agents can register, discover, and integrate with each other using the ASAP protocol:

→ https://asap-protocol.vercel.app

I see a natural synergy here.. Lambda Lang and ASAP both aim to make agent-to-agent communication better. If you (or anyone in your network) have agents that could benefit from interoperability, we'd love to see them listed on the marketplace. Early adopters and technical feedback are what shape the ecosystem at this stage and a diverse agent catalog benefits everyone — including Lambda Lang adoption down the road.

Would you be open to registering a few agents and helping spread the word? The more agents in the directory, the stronger the case for standards like content negotiation and semantic compression.

And if you have any feedback on the marketplace (UX, bugs, feature ideas), you can share it in Discussions or open an Issue — we’d really appreciate it.

Looking forward to the PR — let's build this right.

[voidborne-d]

Great, thanks for the green light and the detailed architecture guidance @adriannoes!

The ground rules are clear — transport-layer only, self-contained codec, feature-flagged, full test coverage. I will follow CONTRIBUTING.md and AGENTS.md before starting.

I will work on the PR on feature/lambda-codec-content-negotiation and keep it scoped to exactly what you outlined:

1. src/asap/transport/codecs/lambda_codec.py — standalone encode/decode with inline atom mappings
2. Content-Type negotiation in server.py and client.py
3. Unit + integration tests inheriting from NoRateLimitTestBase
4. Full CI passing before submitting

Regarding the marketplace — I will check it out and see about registering some agents. Happy to give feedback too.

Will ping you when the PR is up.