Hi HN,
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.
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.