Lad is live · free · last verified 23 Oct 2026 · viability monitor
Lad
Open Apache 2.0 protocol that lets AI agents discover each other on local networks via mDNS/DNS-SD before A2A messaging begins.
If you're wiring agents onto a LAN you don't control, LAD-A2A is the discovery layer you'd otherwise hand-roll badly. Splitting TLS channel auth from domain/JWS/DID identity verification — and gating first contact on explicit consent keyed to that identity — is the right call for hotel Wi-Fi and hospital networks where DNS itself is hostile. Set it against hand-rolled mDNS conventions or a central agent registry: LAD-A2A gives you a written spec, JSON Schemas, signed AgentCards, and a runnable Python demo instead of a wiki page. Go in knowing it's a spec plus a reference implementation, not a managed service, and that wide-area discovery isn't addressed.
Verdict generatedVerified 7d ago · liveness 58/100 · cite: rightaichoice.com/tools/lad
- Developers building local AI agent ecosystems on hotel, office, or hospital networks
- System integrators deploying A2A agents on enterprise LANs that need zero-config discovery
- Architects designing discovery and trust bootstrap for edge or venue-scale deployments
- Researchers prototyping peer-to-peer agent networks on local infrastructure
- Cloud-scale agent discovery across wide-area networks where multicast won't reach
- Non-technical users expecting a turnkey, hosted agent platform
- Teams that want a managed agent directory with a dashboard and support SLAs
We scan live Reddit threads, YouTube comments, X posts, G2 reviews and other communities — and hand you an honest verdict in under a minute.
- Honest verdict, not marketing
- Real pros & cons from real users
- Attributed quotes with receipts
3 free scans · no card needed
Skip LAD-A2A if your agents all run behind a single cloud control plane you operate, where a central registry is simpler than multicast discovery and the local-network trust problem never arises.
Adopting the protocol means building the consent UX and TLS enforcement yourself — the spec defines the requirement but ships no turnkey gate, so that is engineering time on your side
LAD-A2A is published under the Apache 2.0 license and is a specification rather than a metered product, so there is no per-seat or usage bill to compare against commercial agent directories. That puts it in a different category from paid agent-registry and orchestration platforms: your cost is engineering time to implement the protocol, enforce TLS, and build the consent flow, not a subscription. Budget for developer hours, not invoices.
In short
Lad — Open Apache 2.0 protocol that lets AI agents discover each other on local networks via mDNS/DNS-SD before A2A messaging begins. Best for Developers building local AI agent ecosystems on hotel, office, or hospital networks, System integrators deploying A2A agents on enterprise LANs that need zero-config discovery, Architects designing discovery and trust bootstrap for edge or venue-scale deployments. Free to use.
What is Lad?
Lad — Open Apache 2.0 protocol that lets AI agents discover each other on local networks via mDNS/DNS-SD before A2A messaging begins. Best for Developers building local AI agent ecosystems on hotel, office, or hospital networks, System integrators deploying A2A agents on enterprise LANs that need zero-config discovery, Architects designing discovery and trust bootstrap for edge or venue-scale deployments. Free to use.
LAD-A2A (Local Agent Discovery) is an open protocol that answers a question the rest of the agent stack skips: when a device joins a network, how does your AI assistant find the agents running on it? A2A defines agent-to-agent communication, MCP defines agent-to-tool integration, and LAD-A2A defines discovery — the first handshake that answers "who's here?" before A2A can answer "what can you do?" It targets developers, system integrators, and architects building agent ecosystems on constrained local networks: hotel Wi-Fi, office LANs, cruise ships, hospitals, stadiums, and smart cities. Discovery runs two ways — mDNS/DNS-SD under the service type _lad-a2a._tcp, plus well-known HTTP endpoints — so agents announce themselves without anyone hand-configuring a registry. The trust model is the part worth reading before you deploy. On a hostile network, TLS to an attacker-chosen host proves nothing about identity, so LAD-A2A separates channel authentication (TLS) from identity verification (domain/JWS/DID) and requires explicit user consent keyed to a verified identity before any first contact. Signed AgentCards carry the identity claims. TLS 1.2+ is mandatory in production, and a non-https endpoint counts as a discovery failure; HTTP exists only as a dev-mode escape hatch behind --no-verify-tls. What ships today is an Apache 2.0 specification with JSON Schemas, a Python reference implementation (server and client), network simulation examples, and an interactive demo wired to a real OpenAI API key that shows mDNS discovery, the LAD-A2A handshake, and A2A JSON-RPC 2.0 routing end to end. It is vendor-neutral glue, not a platform: you still bring A2A for messaging and MCP for tools.
Key features
- Zero-config agent discovery via mDNS/DNS-SD under the _lad-a2a._tcp service type
- Well-known HTTP endpoint discovery for agents that cannot use multicast
- Trust model separating channel authentication (TLS) from identity verification
- Identity verification via domain, JWS, and DID methods
- Explicit user consent keyed to a verified identity before any first contact
- Signed AgentCards carrying identity and capability claims
- Handoff to standard A2A JSON-RPC 2.0 once discovery completes
- Published JSON Schemas for the protocol
- Apache 2.0 licensed, vendor-neutral and community-driven
- Python reference implementation with server and client modules
- Network simulation examples for hotels, offices, hospitals, and venues
- Interactive demo running real mDNS discovery and A2A query routing
- LLM-based query routing example wired to an OpenAI API key
- TLS 1.2+ required in production
- Non-https URLs treated as a discovery failure
Behind the verdict
LAD-A2A is best understood as a missing rung on the agent ladder rather than a product you buy. The stack that most teams assemble in 2026 has A2A for agent-to-agent messaging and MCP for agent-to-tool access, but nothing standardized for the moment just before either of those: a device joins a network and needs to know which agents exist on it. LAD-A2A fills that gap with two discovery paths — multicast DNS-SD advertisements under the service type _lad-a2a._tcp, and well-known HTTP endpoints for networks that block or degrade multicast. That dual approach is the practical part. Multicast is unreliable on a lot of guest and enterprise Wi-Fi, so an HTTP fallback keeps venue deployments from depending on a network behavior you don't control. The trust model is where the specification earns its keep, and it is worth reading in full before you deploy. The design separates channel authentication (TLS) from identity verification (domain, JWS, DID), on the reasoning that on a hostile network TLS to an attacker-chosen host proves nothing about identity. First contact is gated on explicit user consent keyed to a verified identity, and AgentCards are signed so identity and capability claims travel together. TLS 1.2+ is mandatory in production; a non-https URL is treated as a discovery failure, and the HTTP path exists only as a development escape hatch behind --no-verify-tls. A protocol that makes plaintext feel like a mistake by default is doing its job. What you actually get today is a specification, published JSON Schemas, a Python reference implementation with server and client modules, simulation examples for hotels, offices, hospitals, and venues, and an interactive demo wired to a real OpenAI API key that walks mDNS discovery, the LAD-A2A handshake, and A2A JSON-RPC 2.0 routing. The simulation examples matter more than they sound: they let you test discovery behavior against venue-shaped topologies before you have hardware on site. The weaknesses are structural, not cosmetic. It is an early-stage, community-driven protocol with a small ecosystem, so the value of adopting it depends on other implementers showing up. The reference implementation is Python. Wide-area or cross-network discovery is not addressed — multicast won't cross a WAN, and the spec doesn't pretend otherwise. Production deployment requires you to enforce TLS and build the consent UX yourself, which is real engineering work. If you want a hosted agent directory with a dashboard and an SLA, this is not that and was never aiming to be. The honest framing: adopt LAD-A2A when you are building agents that need to find each other on networks you don't administer — hotel, hospital, cruise, stadium, office — and you would otherwise invent your own mDNS naming convention with no trust story. Skip it if your agents all live behind one cloud control plane you operate, where a central registry is simpler and multicast is irrelevant.
Limitations
- LAD-A2A is an open protocol specification and reference implementation for discovering A2A-capable agents on local networks.
- It is not a production-grade service; production use requires TLS 1.2+ and manual configuration.
- The current reference implementation is in Python and supports local network discovery via mDNS/DNS-SD, with cross-network (WAN) discovery not addressed.
- The ecosystem is still early-stage, with a small community.
as of 2026-10-13
Researching Lad? Get your full AI stack in 60 seconds.
Free, no signup — tell us your goal and get tools matched to your budget & existing stack.
Is Lad still active?
Lad is live · free · last verified 23 Oct 2026 · viability monitor.
Viability score
How well maintained and how widely used is Lad? Built from what the vendor actually publishes (docs, changelog, tutorials, integrations, pricing), whether the site is live, and how much real users discuss it. How we calculate this
Last calculated: October 2026
How we score →What do users say about Lad?
What people actually say about Lad — is it worth it?
Our community sentiment research written Jul 3, 2026 is more than 90 days old, so it is being re-reviewed against current data and is not shown.
How we verified this
Every listed fact about Lad— pricing, features, links, status — is re-read from the vendor's own pages by our verification pipeline and each change is logged with a date; the last pass ran on 23 Oct 2026. Pages mix model-assisted synthesis with human review; see how we verify.
Verification history
We have re-verified Lad 11 times since . Each pass re-reads the vendor's own pages and re-checks every listed field against that evidence; passes where nothing had changed are marked as such.
- — changed setup time, pricing fit, summary, our verdict, features, description, hidden costs, who should skip it, switching in, switching out
- — changed SSL certificate
- — changed setup time, who should skip it, summary, pricing fit, switching in, switching out, hidden costs, our verdict, description
- — changed who it suits, description, our verdict, features, who should skip it, summary
- — changed domain expiry
- — changed summary, description, features, our verdict
Showing the 6 most recent of 11 verification passes.
Free to cite with attribution — this page re-verifies continuously.
How much does Lad cost in 2026?
Lad: Free to use. Pricing last verified 23 Oct 2026.
Where the pricing makes sense
The company stage and team size where Lad's pricing actually pencils out — and where peers do it cheaper.
LAD-A2A is published under the Apache 2.0 license and is a specification rather than a metered product, so there is no per-seat or usage bill to compare against commercial agent directories. That puts it in a different category from paid agent-registry and orchestration platforms: your cost is engineering time to implement the protocol, enforce TLS, and build the consent flow, not a subscription. Budget for developer hours, not invoices.
Has Lad's pricing changed?
No plan price for Lad has moved since we began logging in Aug 2026; the pricing page is re-read on every verification pass.
Who should pick Lad?
Pick Lad if you are Developers building local AI agent ecosystems on hotel, office, or hospital networks, System integrators deploying A2A agents on enterprise LANs that need zero-config discovery, Architects designing discovery and trust bootstrap for edge or venue-scale deployments, Researchers prototyping peer-to-peer agent networks on local infrastructure.
Look elsewhere if you are Cloud-scale agent discovery across wide-area networks where multicast won't reach, Non-technical users expecting a turnkey, hosted agent platform, Teams that want a managed agent directory with a dashboard and support SLAs, Deployments without the resources to enforce TLS and build consent UX.
Skip it if Skip LAD-A2A if your agents all run behind a single cloud control plane you operate, where a central registry is simpler than multicast discovery and the local-network trust problem never arises.
GeneratedReal-world workflow fit
Concrete scenarios for the personas Lad actually fits — and what changes day-one when you adopt it.
You install an agent on the hotel's guest network that advertises itself over mDNS under _lad-a2a._tcp and also exposes a well-known HTTP endpoint for guests whose devices can't do multicast. You validate the setup with the network simulation examples before going on site.
Outcome: A guest's assistant discovers the spa-schedule agent on join, verifies the signed AgentCard against the hotel's domain, prompts the guest for consent, then hands off to A2A JSON-RPC to answer "What's the spa schedule?".
You clone the demo directory, copy .env.example to .env, add an OpenAI API key, and run ./run_demo.sh. Two AI agents stand up, perform real mDNS discovery, complete the LAD-A2A handshake, and route an LLM-based query over A2A JSON-RPC 2.0 at localhost:8000.
Outcome: You see the full discovery-to-messaging path working end to end in a single session and can adapt the Python server and client modules to your own agent.
You run the reference client against a local server with --no-verify-tls in dev to confirm behavior, then write your production design around the assumption that non-https URLs are a discovery failure and every endpoint must present TLS 1.2+.
Outcome: A written security posture that separates channel auth from domain/JWS/DID identity verification, with consent gated on a verified identity before any first contact.
Use cases
- Discover hotel spa agents when joining guest Wi-Fi
- Find local exhibition guides on a cruise ship LAN
- Locate room booking agents in an office network
- Navigate to hospital radiology via local agent discovery
- Find seat maps and concessions at a stadium via agent
- Discover transit schedule agents in a smart city district
Setup time & first value
How long it actually takes to get something useful out of Lad — broken out by persona, not the marketing-page minute.
Developers: the interactive demo is roughly a clone, an .env edit, and one shell script before you see live mDNS discovery and A2A routing, so under an hour. System integrators or architects planning a real venue rollout should budget days to weeks — the protocol ships no turnkey installer, and you own TLS enforcement plus the consent UX.
Switching to or from Lad
How to bring data in from common predecessors and how to get it back out — written for the switcher, not the buyer.
- →From a hand-rolled mDNS naming convention: adopt the _lad-a2a._tcp service type and signed AgentCards so discovery carries identity and capability claims
- →From a central agent registry on a local network: keep the registry on wide-area links and add LAD-A2A for the venue-local discovery path
- →From undocumented ad-hoc agent discovery: replace the internal convention with the published JSON Schemas and the Python reference server and client
- ↗To a managed agent directory with a dashboard and SLA: there is no export tooling, so you re-register agents in the new platform
- ↗To a cloud control plane with its own discovery: drop mDNS advertising if your agents no longer need venue-local first contact
Resources & guides
Tutorials & Learning
YouTube returned 6 videos for “Lad”, and we withheld 6: 6 could not be judged, because “Lad” is a single word that other videos use for other things. We are showing none, because we could not prove any of them are about Lad.
Official links
What are the best Lad alternatives?
The closest alternatives to Lad we list are A2A, Olas Network and Open Managed Agents. Ranked by direct product-type match, not category overlap.
| Alternative | Pricing | Starts at | Last verified |
|---|---|---|---|
| A2A | Free | Free | — |
| Olas Network | Free | Free | — |
| Open Managed Agents | Freemium | Pricing not published | — |
Alternatives to Lad
View all
A2A
A2A is an open agent-to-agent interoperability protocol that lets AI agents on different frameworks discover each other and delegate tasks.
Olas Network
Olas lets you co-own autonomous AI agents that trade, hire each other, and settle payments on-chain with OLAS staking.
Open Managed Agents
Open Managed Agents runs Claude Managed Agents and OpenAI Agents API sessions on infrastructure you control, Apache 2.0.
Tools that pair well with Lad
Common stack mates teams adopt alongside Lad, with the specific reason each pairing earns its keep.
A2A
A2A is an open agent-to-agent interoperability protocol that lets AI agents on different frameworks discover each other and delegate tasks.
Olas Network
Olas lets you co-own autonomous AI agents that trade, hire each other, and settle payments on-chain with OLAS staking.
Open Managed Agents
Open Managed Agents runs Claude Managed Agents and OpenAI Agents API sessions on infrastructure you control, Apache 2.0.
Lad vs its closest rival
Lad's closest head-to-head is with Spider Cloud — Lad and Spider Cloud serve entirely different needs: Lad solves local agent discovery on LANs (hotels, offices) with zero-config and user consent, while Spider Cloud provides fast web crawl/scrape for AI agents at $0.03/1k pages. Choose Lad if you need peer-to-peer agent discovery on local networks; choose Spider Cloud if you need cloud-scale web data for RAG or LLMs. Verdict generated
Head-to-head comparisons
Lad vs Spider Cloud
Lad and Spider Cloud serve entirely different needs: Lad solves local agent discovery on LANs (hotels, offices) with zero-config and user consent, while Spider Cloud provides fast web crawl/scrape for AI agents at $0.03/1k pages. Choose Lad if you need peer-to-peer agent discovery on local networks; choose Spider Cloud if you need cloud-scale web data for RAG or LLMs.
GeneratedLad vs Presto Voice
Presto Voice and Lad serve completely different markets: Presto is an enterprise drive-thru automation platform for QSR chains seeking revenue lift, while Lad is a free, open-source protocol for AI agent discovery on local networks. If you run a multi-location QSR, Presto's proven upselling engine and integrations deliver measurable ROI. If you're a developer building local agent ecosystems, Lad's zero-config approach is ideal. No direct competition.
GeneratedLad vs Temporal Ai
Choose Temporal AI if you need reliable orchestration for AI agents and workflows that survive failures, with support for multiple SDKs and integrations like OpenAI Agents SDK. Choose Lad if your primary challenge is enabling AI agents to discover each other on local networks with zero configuration - they solve orthogonal problems and can even complement each other.
GeneratedFrequently asked questions
Used Lad? Help shape our editorial sentiment research.