Over the last few months I\u2019ve been working on IntentusNet, a small, language-agnostic runtime for routing \u201cintents\u201d between agents and tools, with optional encryption and multiple transports.
GitHub: https://github.com/Balchandar/intentusnet
What problem this tries to solve
Most multi-agent / tool-calling setups I\u2019ve seen end up as a lot of ad-hoc glue:
- custom message formats between each agent\n- hand-rolled routing and fallback logic\n- HTTP in one place, WebSocket in another, maybe ZeroMQ somewhere else\n- no consistent tracing or error model\n- no clear place to add security (encryption, provenance, identity chain)
MCP is great for describing tools, but it doesn\u2019t try to be a runtime or router. I wanted something that sits underneath or alongside MCP and other stacks, and just answers:
\u201cGiven an intent, which agent should handle it, through which transport, with what fallback, and how do we wrap it securely?\u201d
What IntentusNet provides (today)
At the core it has a few small primitives:
- IntentEnvelope \u2013 structured message with context, metadata, routing options, and tags\n- AgentRegistry \u2013 in-memory registry of agents and capabilities (which intents they handle, optional fallback chains)\n- IntentRouter \u2013 picks an agent, executes it, and applies fallback if the primary fails\n- Transports \u2013 pluggable transports, currently:\n - in-process (direct router call)\n - HTTP (POST with a TransportEnvelope)\n - WebSocket (duplex, async)\n - ZeroMQ (REQ/REP client plus simple server)\n- Tracing \u2013 simple trace sink that records spans (agent, intent, latency, status, error)\n- EMCL (Encrypted Model Context Layer) \u2013 optional envelope:\n - a simple HMAC-based demo provider\n - an AES-GCM provider (AES-256-GCM, base64, identity chain) for real encryption
There\u2019s also an MCP adapter that takes an MCP tool request ({ name, arguments }), wraps it into an IntentEnvelope, routes it through IntentusNet, and returns an MCP-style result. The idea is that MCP tools can be wired through the same router, with or without EMCL.
Example usage
A minimal flow looks like:
- define agents with capabilities like \u201csummarize.document.v1\u201d, \u201ctranslate.text.v1\u201d, \u201cstore.note.v1\u201d\n- register them in the runtime\n- use the IntentusClient to send an intent with a payload; the router picks the right agent and handles fallback if configured
There\u2019s also an example of a small \u201cassistant\u201d-style setup where an NLU-like agent parses a natural language request and emits downstream intents to specialized agents (calendar, maps, etc.), just to show multi-agent routing in practice.
Status / what\u2019s missing
This is early-stage:
- Runtime is in Python; other SDKs (for example C#) are not ready yet\n- Orchestrator / workflow layer (sequences, parallel steps, branching) is sketched out in RFCs but only partially implemented\n- Docs and examples can definitely be improved\n- No claims of production readiness yet: it\u2019s more of a structured reference implementation or starting point
I\u2019d really appreciate feedback on:
- the architecture (does the separation between protocol, router, transports, EMCL make sense?)\n- whether this kind of intent router is actually useful under MCP or tool-based systems you\u2019re building\n- missing primitives you\u2019d expect in a runtime like this (timeouts, backpressure, richer tracing, etc.)\n- real-world workflows where a small, transport-agnostic, EMCL-capable router would help (or where it\u2019s overkill)
If you\u2019re working with MCP, multi-agent setups, or secure tool calling and have opinions on how this should work, I\u2019d love to hear them\u2014either here or via issues or PRs on GitHub."},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["intent","router"],"value":"Show HN: IntentusNet-A Secure IntentRouter and Runtime for Multi-Agent Workflows"}},"_tags":["story","author_balachandarmani","story_46179252","show_hn"],"author":"balachandarmani","created_at":"2025-12-07T04:52:39Z","created_at_i":1765083159,"num_comments":0,"objectID":"46179252","points":1,"story_id":46179252,"story_text":"Hi HN,
Over the last few months I\u2019ve been working on IntentusNet, a small, language-agnostic runtime for routing \u201cintents\u201d between agents and tools, with optional encryption and multiple transports.
GitHub: https://github.com/Balchandar/intentusnet
What problem this tries to solve
Most multi-agent / tool-calling setups I\u2019ve seen end up as a lot of ad-hoc glue:
- custom message formats between each agent\n- hand-rolled routing and fallback logic\n- HTTP in one place, WebSocket in another, maybe ZeroMQ somewhere else\n- no consistent tracing or error model\n- no clear place to add security (encryption, provenance, identity chain)
MCP is great for describing tools, but it doesn\u2019t try to be a runtime or router. I wanted something that sits underneath or alongside MCP and other stacks, and just answers:
\u201cGiven an intent, which agent should handle it, through which transport, with what fallback, and how do we wrap it securely?\u201d
What IntentusNet provides (today)
At the core it has a few small primitives:
- IntentEnvelope \u2013 structured message with context, metadata, routing options, and tags\n- AgentRegistry \u2013 in-memory registry of agents and capabilities (which intents they handle, optional fallback chains)\n- IntentRouter \u2013 picks an agent, executes it, and applies fallback if the primary fails\n- Transports \u2013 pluggable transports, currently:\n - in-process (direct router call)\n - HTTP (POST with a TransportEnvelope)\n - WebSocket (duplex, async)\n - ZeroMQ (REQ/REP client plus simple server)\n- Tracing \u2013 simple trace sink that records spans (agent, intent, latency, status, error)\n- EMCL (Encrypted Model Context Layer) \u2013 optional envelope:\n - a simple HMAC-based demo provider\n - an AES-GCM provider (AES-256-GCM, base64, identity chain) for real encryption
There\u2019s also an MCP adapter that takes an MCP tool request ({ name, arguments }), wraps it into an IntentEnvelope, routes it through IntentusNet, and returns an MCP-style result. The idea is that MCP tools can be wired through the same router, with or without EMCL.
Example usage
A minimal flow looks like:
- define agents with capabilities like \u201csummarize.document.v1\u201d, \u201ctranslate.text.v1\u201d, \u201cstore.note.v1\u201d\n- register them in the runtime\n- use the IntentusClient to send an intent with a payload; the router picks the right agent and handles fallback if configured
There\u2019s also an example of a small \u201cassistant\u201d-style setup where an NLU-like agent parses a natural language request and emits downstream intents to specialized agents (calendar, maps, etc.), just to show multi-agent routing in practice.
Status / what\u2019s missing
This is early-stage:
- Runtime is in Python; other SDKs (for example C#) are not ready yet\n- Orchestrator / workflow layer (sequences, parallel steps, branching) is sketched out in RFCs but only partially implemented\n- Docs and examples can definitely be improved\n- No claims of production readiness yet: it\u2019s more of a structured reference implementation or starting point
I\u2019d really appreciate feedback on:
- the architecture (does the separation between protocol, router, transports, EMCL make sense?)\n- whether this kind of intent router is actually useful under MCP or tool-based systems you\u2019re building\n- missing primitives you\u2019d expect in a runtime like this (timeouts, backpressure, richer tracing, etc.)\n- real-world workflows where a small, transport-agnostic, EMCL-capable router would help (or where it\u2019s overkill)
If you\u2019re working with MCP, multi-agent setups, or secure tool calling and have opinions on how this should work, I\u2019d love to hear them\u2014either here or via issues or PRs on GitHub.","title":"Show HN: IntentusNet-A Secure IntentRouter and Runtime for Multi-Agent Workflows","updated_at":"2026-03-05T23:09:20Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"roseway4"},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["intent","router"],"value":"Semantic Similarity as an Intent Router for LLM Apps"},"url":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["intent","router"],"value":"https://blog.getzep.com/building-an-intent-router-with-langchain-and-zep/"}},"_tags":["story","author_roseway4","story_37217609"],"author":"roseway4","created_at":"2023-08-22T01:46:31Z","created_at_i":1692668791,"num_comments":0,"objectID":"37217609","points":1,"story_id":37217609,"title":"Semantic Similarity as an Intent Router for LLM Apps","updated_at":"2024-09-20T14:56:07Z","url":"https://blog.getzep.com/building-an-intent-router-with-langchain-and-zep/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"ahmedm24"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["intent","router"],"value":"Hey HN, I\u2019m the solo builder behind LogiCart.
I recently refactored my frontend to use a Generative UI pattern (inspired by Google's new A2UI framework) because I realized a static chat interface fails for complex shopping intents.
The Problem: A user buying a single item needs a completely different UX than a user planning a complex project. A standard "list of cards" doesn't work for both.
The Solution: I built an Intent-to-UI engine where the LLM decides the interface structure based on the query.
How the Logic Works:
Intent Classification: The LLM first classifies the prompt into one of three modes.
Dynamic Rendering: It returns a JSON schema that my custom React renderer maps to specific components:
Single Item Intent (e.g., "Best Gaming Monitor"): Triggers a Comparison View. It renders a "Best Match" card with detailed specs alongside 3 alternatives for quick comparison.
Bundle Intent (e.g., "Build an AMD Gaming PC"): Triggers a Grouped View. It clusters products by category (CPU, GPU, RAM) to ensure the build is complete.
DIY/Project Intent (e.g., "How to build a deck"): Triggers a Plan View. It renders a step-by-step timeline mixed with the required materials. The number of steps and product complexity dynamically adjusts based on the user's stated experience level.
The Stack:
Backend: Node.js / TypeScript
Search: pgvector (PostgreSQL) for semantic retrieval of Amazon/Retailer SKUs.
Frontend: React (with a custom renderer for the A2UI schemas).
Context: I pivoted to this "deep complexity" approach after Microsoft Copilot launched their generic shopping agent 24 hours after my initial beta. I realized I couldn't compete on generic search, so I\u2019m focusing on the complex/messy projects that require dynamic UI adaptation.
It\u2019s live in Beta. I\u2019d love feedback on the "Intent Router"\u2014try breaking it by asking for something ambiguous like "Coffee" vs "Coffee Station" to see if the UI adapts correctly.
Link: https://logicart.ai"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: LogiCart \u2013 Agentic shopping using Generative UI (A2UI pattern)"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://logicart.ai"}},"_tags":["story","author_ahmedm24","story_46616344","show_hn"],"author":"ahmedm24","children":[46616417],"created_at":"2026-01-14T14:20:26Z","created_at_i":1768400426,"num_comments":2,"objectID":"46616344","points":2,"story_id":46616344,"story_text":"Hey HN, I\u2019m the solo builder behind LogiCart.
I recently refactored my frontend to use a Generative UI pattern (inspired by Google's new A2UI framework) because I realized a static chat interface fails for complex shopping intents.
The Problem: A user buying a single item needs a completely different UX than a user planning a complex project. A standard "list of cards" doesn't work for both.
The Solution: I built an Intent-to-UI engine where the LLM decides the interface structure based on the query.
How the Logic Works:
Intent Classification: The LLM first classifies the prompt into one of three modes.
Dynamic Rendering: It returns a JSON schema that my custom React renderer maps to specific components:
Single Item Intent (e.g., "Best Gaming Monitor"): Triggers a Comparison View. It renders a "Best Match" card with detailed specs alongside 3 alternatives for quick comparison.
Bundle Intent (e.g., "Build an AMD Gaming PC"): Triggers a Grouped View. It clusters products by category (CPU, GPU, RAM) to ensure the build is complete.
DIY/Project Intent (e.g., "How to build a deck"): Triggers a Plan View. It renders a step-by-step timeline mixed with the required materials. The number of steps and product complexity dynamically adjusts based on the user's stated experience level.
The Stack:
Backend: Node.js / TypeScript
Search: pgvector (PostgreSQL) for semantic retrieval of Amazon/Retailer SKUs.
Frontend: React (with a custom renderer for the A2UI schemas).
Context: I pivoted to this "deep complexity" approach after Microsoft Copilot launched their generic shopping agent 24 hours after my initial beta. I realized I couldn't compete on generic search, so I\u2019m focusing on the complex/messy projects that require dynamic UI adaptation.
It\u2019s live in Beta. I\u2019d love feedback on the "Intent Router"\u2014try breaking it by asking for something ambiguous like "Coffee" vs "Coffee Station" to see if the UI adapts correctly.
Link: https://logicart.ai","title":"Show HN: LogiCart \u2013 Agentic shopping using Generative UI (A2UI pattern)","updated_at":"2026-03-05T23:23:47Z","url":"https://logicart.ai"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"reumbra"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["intent","router"],"value":"Forge DevKit scans your repo (stack, layers, conventions) and generates .claude/ artifacts that AI coding\n agents read automatically. Then you can uninstall Forge - the generated files work standalone.
The core problem: AI agents rationalize skipping work. "The type system covers this test" - sounds\n reasonable, wrong 50+ times. Forge detects these patterns and blocks them.\n\n Also ships an intent router: describe what you want ("add payments") and it resolves prerequisites\n automatically (specs -> tests -> code).\n\n Works with Claude Code, Cursor, any agent that reads project files.\n\n Pricing: EUR 29/79/149 (Starter/Pro/Complete). One-time, not subscription. 14-day refund. Generated\n artifacts work forever.\n\n Built with: Claude Code, Astro + Tailwind (landing), Node.js CLI, AWS Lambda + Supabase (API), Cloudflare\n Pages.\n\n Demo: https://forge.reumbra.com/docs/interactive-guide\n Landing: https://forge.reumbra.com The core problem: AI agents rationalize skipping work. "The type system covers this test" - sounds\n reasonable, wrong 50+ times. Forge detects these patterns and blocks them.\n\n Also ships an intent router: describe what you want ("add payments") and it resolves prerequisites\n automatically (specs -> tests -> code).\n\n Works with Claude Code, Cursor, any agent that reads project files.\n\n Pricing: EUR 29/79/149 (Starter/Pro/Complete). One-time, not subscription. 14-day refund. Generated\n artifacts work forever.\n\n Built with: Claude Code, Astro + Tailwind (landing), Node.js CLI, AWS Lambda + Supabase (API), Cloudflare\n Pages.\n\n Demo: https://forge.reumbra.com/docs/interactive-guide\n Landing: https://forge.reumbra.com