| 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. |