Over the last few months I’ve been working on IntentusNet, a small, language-agnostic runtime for routing “intents” between agents and tools, with optional encryption and multiple transports.
Most multi-agent / tool-calling setups I’ve seen end up as a lot of ad-hoc glue:
- custom message formats between each agent
- hand-rolled routing and fallback logic
- HTTP in one place, WebSocket in another, maybe ZeroMQ somewhere else
- no consistent tracing or error model
- no clear place to add security (encryption, provenance, identity chain)
MCP is great for describing tools, but it doesn’t try to be a runtime or router. I wanted something that sits underneath or alongside MCP and other stacks, and just answers:
“Given an intent, which agent should handle it, through which transport, with what fallback, and how do we wrap it securely?”
What IntentusNet provides (today)
At the core it has a few small primitives:
- IntentEnvelope – structured message with context, metadata, routing options, and tags
- AgentRegistry – in-memory registry of agents and capabilities (which intents they handle, optional fallback chains)
- IntentRouter – picks an agent, executes it, and applies fallback if the primary fails
- Transports – pluggable transports, currently:
- in-process (direct router call)
- HTTP (POST with a TransportEnvelope)
- WebSocket (duplex, async)
- ZeroMQ (REQ/REP client plus simple server)
- Tracing – simple trace sink that records spans (agent, intent, latency, status, error)
- EMCL (Encrypted Model Context Layer) – optional envelope:
- a simple HMAC-based demo provider
- an AES-GCM provider (AES-256-GCM, base64, identity chain) for real encryption
There’s 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 “summarize.document.v1”, “translate.text.v1”, “store.note.v1”
- register them in the runtime
- use the IntentusClient to send an intent with a payload; the router picks the right agent and handles fallback if configured
There’s also an example of a small “assistant”-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’s missing
This is early-stage:
- Runtime is in Python; other SDKs (for example C#) are not ready yet
- Orchestrator / workflow layer (sequences, parallel steps, branching) is sketched out in RFCs but only partially implemented
- Docs and examples can definitely be improved
- No claims of production readiness yet: it’s more of a structured reference implementation or starting point
I’d really appreciate feedback on:
- the architecture (does the separation between protocol, router, transports, EMCL make sense?)
- whether this kind of intent router is actually useful under MCP or tool-based systems you’re building
- missing primitives you’d expect in a runtime like this (timeouts, backpressure, richer tracing, etc.)
- real-world workflows where a small, transport-agnostic, EMCL-capable router would help (or where it’s overkill)
If you’re working with MCP, multi-agent setups, or secure tool calling and have opinions on how this should work, I’d love to hear them—either here or via issues or PRs on GitHub.
0 comments
—
Show HN: IntentusNet-A Secure IntentRouter and Runtime for Multi-Agent Workflows · HackerTrans
Over the last few months I’ve been working on IntentusNet, a small, language-agnostic runtime for routing “intents” 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’ve seen end up as a lot of ad-hoc glue:
- custom message formats between each agent - hand-rolled routing and fallback logic - HTTP in one place, WebSocket in another, maybe ZeroMQ somewhere else - no consistent tracing or error model - no clear place to add security (encryption, provenance, identity chain)
MCP is great for describing tools, but it doesn’t try to be a runtime or router. I wanted something that sits underneath or alongside MCP and other stacks, and just answers:
“Given an intent, which agent should handle it, through which transport, with what fallback, and how do we wrap it securely?”
What IntentusNet provides (today)
At the core it has a few small primitives:
- IntentEnvelope – structured message with context, metadata, routing options, and tags - AgentRegistry – in-memory registry of agents and capabilities (which intents they handle, optional fallback chains) - IntentRouter – picks an agent, executes it, and applies fallback if the primary fails - Transports – pluggable transports, currently: - in-process (direct router call) - HTTP (POST with a TransportEnvelope) - WebSocket (duplex, async) - ZeroMQ (REQ/REP client plus simple server) - Tracing – simple trace sink that records spans (agent, intent, latency, status, error) - EMCL (Encrypted Model Context Layer) – optional envelope: - a simple HMAC-based demo provider - an AES-GCM provider (AES-256-GCM, base64, identity chain) for real encryption
There’s 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 “summarize.document.v1”, “translate.text.v1”, “store.note.v1” - register them in the runtime - use the IntentusClient to send an intent with a payload; the router picks the right agent and handles fallback if configured
There’s also an example of a small “assistant”-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’s missing
This is early-stage:
- Runtime is in Python; other SDKs (for example C#) are not ready yet - Orchestrator / workflow layer (sequences, parallel steps, branching) is sketched out in RFCs but only partially implemented - Docs and examples can definitely be improved - No claims of production readiness yet: it’s more of a structured reference implementation or starting point
I’d really appreciate feedback on:
- the architecture (does the separation between protocol, router, transports, EMCL make sense?) - whether this kind of intent router is actually useful under MCP or tool-based systems you’re building - missing primitives you’d expect in a runtime like this (timeouts, backpressure, richer tracing, etc.) - real-world workflows where a small, transport-agnostic, EMCL-capable router would help (or where it’s overkill)
If you’re working with MCP, multi-agent setups, or secure tool calling and have opinions on how this should work, I’d love to hear them—either here or via issues or PRs on GitHub.