The Lifecycle Of A Request
Premise
To understand Daemo's architecture, we will follow a single user query from its origin in a .NET or Node.js application, through the engine's reasoning and execution process, and back to the user as a final answer.
Show revenue for my projects
Step #1: The Handshake via the Reverse Gateway
On startup, the Daemo.SDK establishes a secure, persistent connection to the Daemo Engine. It automatically identifies methods tagged with [DaemoFunction] and registers their signatures with the cloud.
This "Reverse Gateway" architecture allows your local code to be callable by the cloud engine without opening inbound firewall ports, setting up complex VPNs, or exposing public IPs. It works seamlessly behind NATs and corporate firewalls.
Diagram: Step #1 - The Handshake via the Reverse Gateway
Step #2: Two-Phase Reasoning Begins
The user query arrives at the Engine. Instead of immediately answering, Daemo begins a deterministic Two-Phase process. This architectural split separates Phase 1 (Reasoning & Data Retrieval) from Phase 2 (Presentation), ensuring that the AI never "hallucinates" data it hasn't actually fetched.
Diagram: Step #2 - Two-Phase Reasoning Begins
Step #3: The Plan Enters the Safety Airlock
The execution plan generated by the AI is not run directly on the host. Instead, it is injected into Daemo's "Safety Airlock"—an isolated, ephemeral execution environment.
This provides critical security guarantees:
- Hermetic Seal: The environment has no access to the host filesystem or arbitrary network endpoints.
- Resource Governance: Enforces strict memory and CPU quotas to prevent runaway processes.
- Capability Whitelisting: The code can only execute specific, pre-approved actions defined by your SDK.
Diagram: Step #3 - The Plan Enters the Safety Airlock
Step #4: Execution, Interception, and Routing
As the plan executes inside the Airlock, any attempt to invoke a business function (e.g., GetRevenue()) is intercepted by the Daemo Kernel.
The Kernel validates the request against your governance policies (such as Rate Limiting or Human-in-the-Loop checks) and resolves the correct routing path for the agent instance that owns the function.
Diagram: Step #4 - Execution, Interception, and Routing
Step #5: The Engine Executes Your C# Code
The Engine securely routes the execution command down the established tunnel to the specific Daemo.SDK instance running in your application.
The SDK invokes your native C# method in-process. This ensures that all your local business logic, logging, and database transactions execute exactly as if you called the method yourself locally. The result is then securely returned up the stream to the Engine.
Diagram: Step #5 - The Engine Executes Your C# Code
Step #6: The Final Answer is Assembled
The result from your function returns to the Airlock, completing the plan’s execution. The final, structured output (finalJSON) is now considered verified data.
This data is passed, along with the original user query, to the LLM a final time in "Analyst Mode". The LLM’s only job is to translate the strictly verified data into a natural language response for the user.
Diagram: Step #6 - The Final Answer is Assembled
The Final Response
And just like that, the loop is complete. The user's natural language query has been transformed into a verified, deterministic answer:
Show revenue for my projects
Here's the revenue breakdown for your projects:
| Project | Revenue | Status |
|---|---|---|
| Project Alpha | $125,400 | Active |
| Project Beta | $98,200 | Active |
| Project Gamma | $67,850 | Completed |
Your total revenue across all projects is $291,450. Project Alpha is your top performer this quarter.
The AI never invented these numbers—they came directly from your GetRevenue() function, executed safely inside the Daemo runtime. Every figure is traceable, every action is audited, and no hallucination is possible.