r/learnAIAgents

Builders-welcome post with the substance up front (disclosure: I'm the maintainer). OmniRoute is a free, MIT, self-hosted AI gateway — one OpenAI-compatible endpoint over 237 providers — built around two problems: runs dying on a provider 429, and tokens bleeding on tool/log output.

One endpoint, 237 providers — 90+ of them free. You point any tool or agent at a single OpenAI-compatible endpoint (localhost:20128/v1) and it can reach 237 LLM providers without you rewriting anything. 90+ have free tiers and 11 are free forever (no card), which aggregates to ~1.6B documented free tokens/month — and that's honest, pool-deduped math (we count each shared pool once instead of inflating it; the methodology is public in the repo). There's a one-command setup-* for 13+ coding tools (Claude Code, Codex, Cursor, Cline, Roo, Kilo, Gemini CLI…), so switching your existing setup over takes seconds.

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

Fusion — an ensemble mode for the hard steps. Beyond simple routing, there's a fusion strategy that fans a single prompt out to a panel of different models in parallel and then has a judge model synthesize one best answer (mixture-of-agents, built in). It's cost-aware, so easy turns stay on one fast model and it only fuses when the step is worth it.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

Agent-native — the agent can drive the router itself. There's a built-in MCP server (95 tools across 30 audited scopes, over stdio / SSE / streamable-HTTP), plus A2A (v0.3, JSON-RPC 2.0) support. That means an agent can query providers, switch combos, read its own remaining quota and manage memory through the gateway — not just consume tokens through it.

It's 100% local (zero telemetry, AES-256-GCM at rest), MIT-licensed, has a prompt-injection guard on every LLM route, opt-in memory, and runs on npm, Docker, desktop or your phone via Termux.

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 · Site: https://omniroute.online

Would value a critique of the routing/compression architecture from this crowd.

Most of the AI conversation in marketing today runs in one of two directions. There’s the outside-in direction — competitive intelligence, analyst coverage, social listening — where AI helps you understand the market. And there’s the forward direction — campaigns, ABM, lead nurturing — where AI helps you move people through a funnel.

What’s almost never discussed is the third direction: inside-out. What happens when you point an AI agent at your own company’s internal knowledge — specs, tickets, call transcripts, win/loss notes — and ask it to do the unglamorous but critical work of product marketing? Not “tell me about the market,” not “write me an ad,” but: generate the battle card, draft the release note, and tell me if what we’re saying externally still matches what’s true internally.

That third lane is what I wanted to explore. So I built PMM Second Brain — a working AI agent, backed by a real (if fictional) company’s internal wiki, that produces actual PMM deliverables and catches messaging drift before a customer does.

This post is the story of how it came together: the thinking behind it, the architecture, the build process, and a few things I learned along the way — including some genuinely humbling moments getting it to run on my own laptop.

https://yotam.substack.com/p/building-a-second-brain-for-product

I've been learning AI engineering by building instead of just watching tutorials.

To push myself beyond the basics, I started building an AI Code Review Agent. The goal wasn't to create a polished product—it was to force myself to understand how these systems actually work.

Some of the concepts I ended up learning along the way:

• Retrieval-Augmented Generation (RAG)
• Embeddings and vector search
• ReAct-based agent workflows
• LLM-powered code analysis
• GitHub integrations

One thing I learned quickly is that getting an LLM to answer questions isn't the hard part. Making retrieval reliable, giving the agent the right context, and designing good workflows takes much more iteration than I initially expected.

The project is open source and still a work in progress, with plenty of room for improvement as I continue building and learning.

Repository: https://github.com/RishabhhG/codereview-agent
Linkedin : https://www.linkedin.com/in/rishabh-guptaaa/

If anyone wants to try it out, use it, or contribute, I'd really appreciate the feedback. I'm also happy to discuss the architecture, implementation decisions, or hear suggestions for improving the agent.

I love helping people out and I recently launch a small community project for people who are building AI Agent. As someone who has found tons of good ideas over the years. I thought it only made sense to put all agent ideas together.

So I build Agent Idea Hub a place for people to find ideas on agents that are worth building (you can actually make money from it)

Would love for you all to join ! As the spot are limited and I won’t allow more than 50 members to keep the ideas solid.

This one covers the SSE streaming layer that carries our AI agent's lifecycle from server to browser.

We chose SSE over WebSockets for the agent stream. The conversation is unidirectional during execution — user sends request, agent streams response. No need for browser to push mid-stream. SSE gives us built-in reconnection, HTTP compatibility with every proxy/CDN, and ~50 lines of parser code.

The protocol defines 18+ typed event types across 6 categories:

- Agent lifecycle (status, chat_id, context_meta)

- Reasoning (thinking, thinking_chunk, plan, plan_update, thinking_clear)

- Tool (tool_call, tool_result, tool_retry)

- Artifact (artifact_start, artifact, artifact_rows)

- Content (delta)

- Completion (done, error, quota_exceeded, quota_update)

Each event type maps to a specific UI affordance. Frontend doesn't infer state from text deltas — the protocol tells it what's happening.

Three things worth highlighting:

1. Chunked payloads for >64KB. SSE has a practical ~64KB limit in many proxy/CDN configs. Our emitter auto-chunks oversized payloads into frames with chunk_index/total_chunks metadata. Frontend reconstructs transparently.

2. Streaming tables in 50-row batches. Instead of buffering a 10K-row table and chunking it, we emit rows in fixed batches. First 50 render in <200ms, rest append without blocking UI. Memory is bounded.

3. The Nginx gotcha. X-Accel-Buffering: no is the non-obvious header that makes SSE actually work behind Nginx. Without it, Nginx buffers the entire stream before forwarding. Browser sees nothing until agent finishes, then gets every event at once.

Retry strategy: 4xx errors (auth, validation, quota) are NOT retried — they require user action. Only network errors and 5xx trigger exponential backoff (1s, 2s, 4s, max 3 retries).

Full post with code, Mermaid diagrams, payload examples:

https://vivekmind.com/blog/sse-streaming-architecture-how-schema-weaver-s-data-explorer-streams-18-event-types-and-chunked-payloads-to-the-browser

Happy to answer questions on the protocol design, chunking strategy, or the Nginx gotcha.

If you've been building in the AI space lately, you know that transitioning from standard chat interfaces to truly autonomous, agent-based systems is the current frontier.

Microsoft just dropped a solid engineering blog on how they are fundamentally transforming their own software development lifecycle by leveraging an agentic platform. It covers some great architectural insights on moving beyond simple automation into complex, multi-agent reasoning for real-world development tasks.

Definitely worth a read if you're exploring agentic architectures or looking to scale autonomous dev tools.

Check out the full breakdown from Microsoft here