Data Flow

We have a server and its connectors. Now let's trace exactly what happens when you ask the AI to do something, from your message to the answer. Understanding this path is most of understanding the system. (For the underlying mechanic - how a model actually invokes a tool - see tool calling.)

The path of one request

1. Your AI signs in once and gets a pass (a token) it will show on every request after that.
2. You ask for something in plain language. The AI looks at the tools the server advertised and picks the one that fits, filling in any details it needs.
3. It sends that tool call to the server, with the pass attached.
4. The server checks the pass, finds the named tool, and runs it.
5. The tool does the real work: asking Azure to do something, calling GitHub, or reading the node's own notes.
6. The result travels back up to the AI, which turns it into your answer.

What each layer is doing

The pass is what proves a request is allowed; without it the server refuses before anything runs. The tool list is what lets the model choose correctly, so good names and descriptions matter. The handler is the only part that touches the outside world, and it does so with the node's own identity, not a stored password.

The two boundaries

There are two places the system draws a hard line. On the way in, every request must carry the pass. On the way out, the node's identity can only touch its own resource group, so even a misbehaving tool cannot reach the rest of your cloud.

Where state lives

Secrets live in the vault. Data lives in the resource group. Nothing important lives in the conversation itself, which means a dropped chat never loses anything. There is more depth on this in the architecture doc.