Agent traffic has a strange property: almost every byte is a repeat. Two AI systems exchanging MCP tool calls, A2A task updates, or OpenAI-style function calls send jsonrpc, method, params, trace_id, task_id, and the same schema fragments thousands of times per minute. The values change. The structure barely does.

AURA is an experimental, protocol-aware data-movement toolkit built around that observation. Its main path is AIWire: a negotiated structure side channel that lets two peers agree on message structure once, then move compact deltas over ordinary TCP, WebSocket, HTTP, or broker links instead of re-sending whole JSON frames.

The steady state AIWire aims for is not "send a whole frame more cheaply." It is "handshake the structure, then send the change."

Why stateless compression leaves so much on the table

The obvious fix for verbose JSON is gzip or zlib per message. That works, but it has two structural problems for agent traffic:

1. Every frame pays setup cost. Stateless compression treats each message as unrelated text and rediscovers the same patterns every time.
2. History is thrown away. Frame 4,000 of a session looks almost identical to frame 3,999, but a per-frame codec cannot use that.

AIWire keeps a live compression stream per direction across the whole session, seeds it with a static dictionary of common AI protocol fields, and lets peers negotiate session-specific templates on top. After the handshake, the hot path carries only what changed against structure both sides already share.

The three-lane model

The part of the design I find most interesting is that AIWire refuses to treat a connection as one undifferentiated pipe. It splits AI traffic into three logical lanes over whatever transport you already have:

The semantic/message lane carries the actual agent messages: MCP tool calls, JSON-RPC requests and responses, A2A task and artifact updates, traces, handoffs, results. This is the lane the dictionary, session templates, and stateful delta stream optimize.

The control/session lane carries the machinery that keeps the semantic lane safe: handshakes, template discovery, dictionary diffs, ACK/NACK, resume negotiation, heartbeats, and reset signals. The spec requires that control messages stay decodable without inflating the semantic stream. If the compressed stream is resyncing or has failed, you can still read the control lane and recover. Your ops path never depends on the health of the compression state it is trying to fix.

The blob descriptor lane handles the things that should never go through a structured-message codec at all: media, tensor chunks, model artifacts, log archives. The bytes move over a normal blob or file transport. AIWire carries the metadata: content type, SHA-256 digests, chunk manifests, route, priority, and transfer status. A receiver can schedule, verify, and account for a 2 GB artifact without ever pulling it through the message path, and a semantic-lane reset does not invalidate a completed digest-verified transfer.

The separation is a safety argument as much as a performance one. Under congestion, control messages get priority over bulk bytes. Blob descriptors are forbidden from mutating the session dictionary. Each lane fails independently.

Fail closed, by contract

Shared compression state is dangerous if the two sides ever disagree, so the AIWire v1 spec is aggressive about verification:

• The handshake compares static dictionary SHA-256 and byte size, template hashes and counts, and zlib parameters. Any mismatch fails closed or falls back to raw/zlib only if the application explicitly allowed it.
• Session dictionary growth is append-only, epoch-numbered, and proposed through diffs that carry previous and next state hashes, a fresh nonce, a diff identity hash, and an optional HMAC-SHA256 tag. A sender may not encode against new structure until the matching ACK is verified.
• Resume handshakes let a client reconnect against a cached dictionary state, but only if the receiver actually holds one of the offered state hashes.
• Any inflate error, hash mismatch, or ordering violation means stop, rehandshake, or fall back. The spec's phrasing: peers must not continue sending compact deltas against uncertain structure.

The metric is exchanges, not ratio

AURA's docs are explicit that compression ratio alone is the wrong scoreboard. The question is how many verified semantic exchanges fit through a link once bandwidth, p95 latency, and codec CPU are accounted for.

On a modeled 10 Mbps link with protocol-shaped request/response traffic (native C++ backend, 2026-07-04):

A live TCP replay of the committed public session corpus, with 64 concurrent logical agents and SHA-256 verification of every response, pushed further: AIWire averaged 45.6 bytes per exchange for a 24x bandwidth gain, and the combined AIToken + AIWire path hit 32.3 bytes per exchange, a 34x gain with 97.1% of bytes saved. At that point the modeled link was no longer the bottleneck; the runtime could not keep enough requests in flight to fill the headroom.

That last detail is the honest core of the project. Smaller frames only matter if your system has enough concurrent work to use the room they create. AURA ships the extrapolation tooling to reason about exactly that: given a bandwidth, a p95 latency, and a per-agent window, how many agents does it take to saturate the link.

Where it fits

AURA is for situations where you control both ends of the link and the traffic has repeated structure:

• Multi-agent request/response loops. Orchestrators, workers, and reviewers exchanging thousands of small task, status, and result messages.
• MCP and JSON-RPC tool traffic. Tool calls and tool results are the canonical case of stable structure with changing values.
• Local AI clusters and edge links. The repo's LAN benchmark runs a Mac against a Z6 workstation and Jetson Nano-class boards; a bandwidth-limited edge mesh is exactly where an 86 to 97% byte reduction converts into headroom for telemetry, media, and retries.
• Structured logs and traces. Repeated field names, session-stable shapes, high volume.
• Binary payload routing. Agents that need to schedule, verify, and track opaque artifacts by digest without moving the bytes through the message path.

What it is not

The README is unusually direct about limits, and it is worth repeating them. AURA is not a drop-in replacement for gzip, zstd, TLS, or a message broker. It does not define transport security, retries, or backpressure; those stay at the transport layer. The stateful stream means frames cannot be reordered or dropped inside a session, so lossy transports need their own recovery layer. And it is not production-ready: it is a prototyping and measurement toolkit with a working Python path, a native C++ backend, deterministic public fixtures, and reproducible benchmark harnesses.

That fixture corpus deserves a mention. The repo commits a synthetic public session corpus covering MCP, A2A, OpenAI Responses, traces, handoffs, and memory writes, wrapped in the full side-channel lifecycle: forced handshake, template update, authenticated dictionary diff, ACK, and resume. Anyone can replay the exact benchmark and check the numbers.

Trying it

from aura_compression import AIWireSessionEncoder, AIWireSessionDecoder

message = {
    "protocol": "mcp",
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {"name": "read_file", "arguments": {"uri": "repo://service/path.py"}},
}

with AIWireSessionEncoder(level=3) as encoder, AIWireSessionDecoder() as decoder:
    delta = encoder.compress_message(message)
    restored = decoder.decompress_message(delta)

assert restored == message

The repo includes transport examples for length-prefixed TCP, WebSocket, HTTP with Server-Sent Events, and a local broker, plus the full benchmark harness used for the numbers above.

Agent-to-agent traffic is growing faster than the links it runs on, and most of it is the same structure sent again and again. AURA's bet is that the fix belongs in a negotiated session protocol, not a per-frame codec. The three-lane model, the fail-closed handshake contract, and the exchanges-per-second scoreboard are what make it worth watching.

AURA is Apache 2.0 licensed. Code, spec, fixtures, and benchmark reports: github.com/H-XX-D/AURA.

Building agents, two infra problems cost me the most: runs dying on a 429 mid-task, and the agent bleeding thousands of tokens dumping git diff, test logs and build output into context. I built OmniRoute to fix both at the gateway layer. Disclosure: I'm the maintainer — this is dev-to-dev, not a pitch, and I'd like the critique.

It's a self-hosted, MIT, OpenAI-compatible endpoint in front of 237 providers. What's actually relevant if you build agents:

• Fallback combos. A model ladder (subscription → API key → cheap → free) the router walks automatically. A provider 500s or hits quota and it fails over to the next target in milliseconds, mid-request — the agent never sees the error. 17 routing strategies + three resilience layers (circuit breaker, per-key cooldown, per-model lockout) so one dead key never takes down a whole provider. There's also a fusion strategy: fan a hard step out to a panel of models in parallel and let a judge synthesize the answer.

• Compression pass. Every request goes through a transparent pipeline (RTK for command/tool output 60–90%, Microsoft's LLMLingua-2 for ML pruning, session-dedup, etc.), with a default-on inflation guard (if compressing would grow the prompt it sends the original verbatim) and code/URLs/JSON preserved byte-perfect. On tool-heavy agent sessions it averages ~89% input-token reduction. Full credit to the upstream projects is in the repo.

• Agent-native control plane. Built-in MCP server (95 tools) + A2A, so an agent can query providers, switch combos and read its own usage through the gateway instead of just consuming tokens.

• Free-tier aggregation. 90+ providers with free tiers (11 free forever), ~1.6B documented pool-deduped tokens/month — cheap iterations while developing. One-command setup for Claude Code / Codex / Cursor / Cline.

Local-first, zero telemetry, prompt-injection guard on every route.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute

Would especially like a critique of the fallback/routing design and the compression fidelity approach from people who've built this layer themselves.

Developers and AI users paste API keys, credentials, and internal code into AI tools every day. Most don't even realize it.

We built Bleep - a local app that scans everything you send to 1300+ AI services and blocks sensitive data before it leaves your machine.

Works with any AI tool: ChatGPT, Claude, Copilot, Cursor, AI agents, MCP servers - all of them. 3-5ms added latency. Zero impact on non-AI traffic.

How it works:

• 100% local - nothing ever leaves your machine
• Detects API keys, tokens, secrets, PII out of the box - plus custom regex and encrypted blocklists
• OCR catches secrets hidden in screenshots and PDFs uploaded to AI
• You set the policy: block, redact, warn, or log
• Windows , macOS & Linux desktop apps, CLI for servers

https://bleep-it.com

Looking for feedback regarding a web penetration toolkit that hooks directly into claude code harness.

https://github.com/leznato/redan

Fundamentally, you just open CC in the folder and it's all ready, the agent will take it from there.

/effort ultracode recommended

So far I've used it with Claude agents but should work with others too

Any Opinions on this stack using Antigravity CLI+ obsidian on OKF?

I’ve been trying to make sense of browser automation tools for AI/dev workflows. It feels like a bunch of different things are getting called the same thing: Playwright/Selenium, Stagehand-style natural-language actions, browser tools for coding agents, full browser agents, agentic browsers, and Browserbase-style cloud infra.

I wrote up a short taxonomy here: https://libretto.sh/blog/understanding-ai-browser-automation-tooling

Hope it’s helpful, and let me know if you have any questions!

ihttps://github.com/shanirsh/prismodev

i built , a local li for finding context waste in claude code, codex, and cursor workflows. it runs locally, needs no api keys, no login, and nothing leaves your machine.

ai coding agents can waste a lot of context on generated files, lockfiles, repeated reads, huge command output, stale sessions, command loops, and oversized claude.md / agents.md files.

you can try it with:

npx getprismo doctor

the main pieces are:

doctor scans your repo, flags missing .claudeignore / .cursorignore, exposed build/log artifacts, oversized instruction files, and generates compact .prismo context packs.

watch --agents monitors context pressure, repeated file reads, artifact leaks, tool-output floods, command loops, and multi-agent overlap.

shield -- npm test runs noisy commands without dumping full stdout/stderr into the agent context. the full output stays local and can be searched later.

receipt, timeline, and replay show what happened after a session: repeated reads, output floods, artifact leaks, likely influence, recurring patterns, and recovery prompts.

instructions audit checks claude.md / agents.md rules for useful guardrails, observable violations, partial compliance, duplicates, trim candidates, and influence-unknown rules. instructions ablate --dry-run creates a safe ablation plan without editing files.

firewall creates task-scoped allow/block context boundaries, and mcp exposes prismodev as local tools for compatible agents.

would love feedback on false positives, missing waste patterns, or whether this kind of local ai coding observability is useful.

Most multi-agent setups I've seen treat agents like isolated workers. Each one gets a task, runs it, returns a result. No awareness of each other. No way to coordinate. Just parallel execution with a shared clipboard.

I've been building a multi-agent framework in public for about 4 months. 13 agents, 8,400+ tests, 135 stars. Here's the thing I didn't expect to matter most - communication.

Each agent in my system is a domain specialist. The mail system only thinks about mail. The routing system only thinks about routing. They live in their own directories with their own identity files, their own memory, their own tests. A hook fires every session to load identity before anything else runs. No agent boots cold.

The problem was coordination. Agents can't write files outside their own directory - there's a hard block that rejects cross-branch writes. That's by design. But it means an agent that finds a bug in someone else's code can't just go fix it.

So I gave them email.

Here's what I expected: agents would share data. Pass results around. Maybe sync state.

Here's what actually happened: the first thing they did was file bug reports against each other.

One agent finds a test failure in another agent's domain. It sends an email: "Hey @routing, your path resolution fails when the branch name has a dot in it. Here's the traceback." The routing agent gets woken up, reads the mail, and fixes it. No human in the middle.

There's a difference between "send" and "dispatch" - send drops a letter in the mailbox. Dispatch drops the letter AND rings the doorbell. It spawns the agent and points it at its inbox.

drone @ai_mail send @routing "Bug report" "Path fails on dotted names..."
drone @ai_mail dispatch @routing "Fix needed" "Traceback attached..."

Send = mail. Dispatch = mail + wake.

The mail agent has 696 tests. Not because someone sat down and wrote 696 test cases. Because it kept breaking in production and every fix got a test. The routing system has 80+ sessions of experience doing nothing but routing. These agents aren't reliable because they have better models - they're reliable because they've been failing and fixing for months.

Agents dispatch each other freely. If the test runner finds a bug in another agent's code, it wakes that agent directly. The orchestrator doesn't need to approve. Only the orchestrators themselves are protected from being dispatched - you don't want a worker agent waking up the CEO for grunt work.

Security is enforced not conventional. Agents can't forge messages by writing directly to another agent's inbox file - they have to use the mail system. Same with the write blocks. Hard enforcement, not "please don't."

There's a monitoring layer so I'm not flying blind. Audio cues on every agent action - I hear what's happening without watching a terminal. Real-time dashboard shows everything. If an agent hits the same error 2-3 times, a watcher catches the pattern and dispatches the right specialist to investigate. I stay in the loop through visibility not approval gates.

The whole thing is open source. pip install aipass + two init commands and you're running. CLI-based, built on Claude Code. Linux focused rn.

https://github.com/AIOSAI/AIPass

Genuine question - has anyone else tried giving agents communication instead of just better reasoning? Everything I see is about making individual agents smarter. Nobody seems to be building the coordination layer.

Change https://github.com/owner/repo → https://cgc.codes/owner/repo

A standard GitHub URL can be instantly transformed into a CodeGraphContext (CGC) graph URL, unlocking architecture visualization, code navigation, dependency exploration, and AI-powered repository understanding, all directly in your browser.

Natively, It's an MCP server that indexes your code into a graph database to provide context to AI assistants.

Understanding and working on a large codebase is a big hassle for coding agents (like Google Gemini, Cursor, Microsoft Copilot, Claude etc.) and humans alike. Normal RAG systems often dump too much or irrelevant context, making it harder, not easier, to work with large repositories.

🔎 What it does Unlike traditional RAG, Graph RAG understands and serves the relationships in your codebase: 1. Builds code graphs & architecture maps for accurate context 2. Keeps documentation & references always in sync 3. Powers smarter AI-assisted navigation, completions, and debugging

⚡ Plug & Play with MCP CodeGraphContext runs as an MCP (Model Context Protocol) server that works seamlessly with: VS Code, Gemini CLI, Cursor and other MCP-compatible clients

📦 What’s available now are - - A Python package (with 150k+ downloads)→ https://pypi.org/project/codegraphcontext/ - Website + cookbook → https://cgc.codes/ - GitHub Repo (3500+ stars and 500+ forks) → https://github.com/CodeGraphContext/CodeGraphContext - Our Discord Server → https://discord.gg/dR4QY32uYQ

We have a community of 300+ developers and expanding!!

Developers and AI users paste API keys, credentials, and internal code into AI tools every day. Most don't even realize it.

We built Bleep - a local app that scans everything you send to 1300+ AI services and blocks sensitive data before it leaves your machine.

Works with any AI tool: ChatGPT, Claude, Copilot, Cursor, AI agents, MCP servers - all of them. 3-5ms added latency. Zero impact on non-AI traffic.

How it works:

• 100% local - nothing ever leaves your machine
• Detects API keys, tokens, secrets, PII out of the box - plus custom regex and encrypted blocklists
• OCR catches secrets hidden in screenshots and PDFs uploaded to AI
• You set the policy: block, redact, warn, or log
• Windows & Linux desktop apps, CLI for servers

https://bleep-it.com