Inverting Agent Model (App as Clients, Chat as Server and Reflection)
Hello HN. I’d like to start by saying that I am a developer who started this research project to challenge myself. I know standard protocols like MCP exist, but I wanted to explore a different path and have some fun creating a communication layer tailored specifically for desktop applications. The project is designed to handle communication between desktop apps in an agentic manner, so the focus is strictly on this IPC layer (forget about HTTP API calls). At the heart of RAIL (Remote Agent Invocation Layer) are two fundamental concepts. The names might sound scary, but remember this is a…
In plain words
RAIL (Remote Agent Invocation Layer) is a communication framework for desktop applications that enables inter-process communication in an agentic manner. It inverts traditional client-server architecture by positioning chat applications as servers and desktop apps as clients, allowing them to exchange data through memory injection and reflection mechanisms. Designed for developers building connected desktop applications, it offers an alternative to standard protocols by providing a lightweight IPC layer tailored specifically for agent-based interactions between local applications.
written from the facts on this page · September 2026
From the sources
In the maker’s words, at launch
Hello HN. I’d like to start by saying that I am a developer who started this research project to challenge myself. I know standard protocols like MCP exist, but I wanted to explore a different path and have some fun creating a communication layer tailored specifically for desktop applications. The project is designed to handle communication between desktop apps in an agentic manner, so the focus is strictly on this IPC layer (forget about HTTP API calls). At the heart of RAIL (Remote Agent Invocation Layer) are two fundamental concepts. The names might sound scary, but remember this is a research project: Memory Logic Injection + Reflection Paradigm shift: The Chat is the Server, and the Apps are the Clients. Why this approach? The idea was to avoid creating huge wrappers or API endpoints just to call internal methods. Instead, the agent application passes its own instance to the SDK (e.g., RailEngine.Ignite(this)). Here is the flow that I find fascinating: -The App passes its instance to the RailEngine library running inside its own process. -The Chat (Orchestrator) receives the manifest of available methods.The Model decides what to do and sends the command back via Named Pipe. -The Trigger: The RailEngine inside the App receives the command and uses Reflection on the held instance to directly perform the .Invoke(). Essentially, I am injecting the "Agent Logic" directly into the application memory space via the SDK, allowing the Chat to pull the trigger on local methods remotely. A note on the Repo: The GitHub repository has become large. The core focus is RailEngine and RailOrchestrator. You will find other connectors (C++, Python) that are frankly "trash code" or incomplete experiments. I forced RTTR in C++ to achieve reflection, but I'm not convinced by it. Please skip those; they aren't relevant to the architectural discussion. I’d love to focus the discussion on memory-managed languages (like C#/.NET) and ask you: -Architecture: Does this inverted architecture (Apps "dialing home" via IPC) make sense for local agents compared to the standard Server/API model? -Performance: Regarding the use of Reflection for every call—would it be worth implementing a mechanism to cache methods as Delegates at startup? Or is the optimization irrelevant considering the latency of the LLM itself? -Security: Since we are effectively bypassing the API layer, what would be a hypothetical security layer to prevent malicious use? (e.g., a capability manifest signed by the user?) I would love to hear architectural comparisons and critiques.
More ai this month
the category →
I trained a 125M-parameter transformer to autocomplete piano performances in real time (~108 notes/sec on an iPhone 15). The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device. The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work.
AI · 17d ago · simedw.com
Astute▲585Automate your B2B brand going viral, with new media creators
AI · 18d ago · company-app.joinastute.com
Hey HN, Henry from Cactus here! We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2. The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges…
AI · 27d ago · cactuscompute.com
