ertad-family/liquid

**Connect your AI agent to anything — with no connector to write or maintain.**
Point Liquid at a URL or a database and it works out the interface for you:
discovers its shape, maps it to the fields you asked for, and handles auth,
pagination and normalization — typed records, no client code. When the upstream
drifts, it re-maps and keeps going. The same small API — fetch · query ·
write · sense — reaches web APIs, databases, other agents (MCP/A2A), email,
and even IoT and industrial systems (MQTT, Modbus, OPC UA, BACnet). An LLM does the
learning at setup (and on drift); the data path itself makes no model call.
---
What an agent can reach through Liquid
One agent-facing API (fetch · query · write · sense) over everything an
agent might need to touch — Liquid figures out *how to talk to it* so the agent
doesn't have to. It's the agent's senses **and** hands: fetch/query probe,
sense perceives a live event stream, write acts on the world.
- **Web APIs & messaging** — REST/JSON, GraphQL, SOAP/WSDL, gRPC, WebSocket,
SSE/NDJSON streams, MQTT (IoT pub/sub — subscribe to sense, publish to act)
- **Email** — IMAP/SMTP (any provider, app-password or OAuth2 XOAUTH2) and the
Gmail API (OAuth2): read a mailbox, sense new mail as it arrives, and send
- **Industrial / OT** — Modbus (PLCs, sensors) and OPC UA (Industry-4.0 nodes,
native subscriptions) for the factory floor; BACnet for buildings (HVAC/BMS) —
read, write, and sense
- **Android devices** — phones, TV boxes, kiosks via ADB: sense logcat, read
shell, act with input/am
- **Other agents & tools** — any MCP server, A2A agents, ChatGPT-plugin manifests
- **Databases** — Postgres (+ pgvector), MySQL/MariaDB, SQLite, DuckDB, SQL Server,
Neo4j (graph), MongoDB (documents), Redis (key-value)
- **People, places & things** — a human, a home, or a car as a node via
connectors: Telegram (perceive messages, send replies), Home Assistant
(perceive a whole smart home's state changes, act via call_service — lights,
locks, media), and Smartcar (perceive a connected vehicle across ~30 brands —
location/battery/fuel — and act: lock/unlock, charge)
Point it at a https://… endpoint, a postgres://… / mongodb://… / redis://…
DSN, a grpc://… target, or another MCP server — discovery identifies the
interface, learns its shape, and hands your agent typed records. The same
fetch/query/write works regardless of what's underneath. No per-service
connector to hand-write; the integration maintains itself when the upstream
changes.
You hand-write no connector and no schema: an LLM learns the interface once at
setup (databases introspect themselves and skip even that), and the integration
**repairs itself** when the upstream drifts. The runtime is plain deterministic
transport — predictable cost, reproducible behavior, nothing to babysit.
Built for the constraints real agents hit
Reaching everything is half of it. The other half is that agents pay for every
token, get confused by inconsistent shapes, and can't parse error prose. Liquid
answers each with a concrete primitive — all shipped, all on PyPI.
Context-budget control
Cross-source normalization
Timestamps (Unix / ISO 8601 / RFC 2822) collapse to UTC datetime; pagination
envelopes ({data:[…]} / {results:[…]} / Link headers) flatten; ID fields
normalize across id / _id / uuid / *_id.
Canonical intents — one mental model across services
Structured recovery — agents self-heal without parsing text
Every error carries a Recovery with next_action: ToolCall, retry_safe, and
retry_after_seconds. 401 → store_credentials. 404/410 → repair_adapter. 429
→ retry after the given delay. And when the upstream's schema drifts, adapters
**self-heal** (repair_adapter) — the agent keeps working.
Predictable cost — know before you call
You wrote no connector, no schema, no auth glue — Liquid learned the interface
for you, and will re-learn it if it changes. That's the point: integrations you