Request paths

Almost every request to Flexday AI follows one of three paths. A builder's change goes through the Studio API to a durable job on the worker. An end user's request goes through the gateway to a query, a Flow, an Agent or a file. A Teams message goes through the gateway's webhook to an Agent turn on the worker. This page follows each one.

At a glance#

• Nothing slow happens inside a web request. Builds, runs and Agent turns are durable jobs, and the browser watches them over a reconnectable stream.
• End users only ever reach the gateway. They never touch the Studio API.
• Every path checks who is asking first. Studio checks the builder's sign-in and roles; the gateway checks the Identity attached to the endpoint; the Teams webhook checks Microsoft's signature.

A. A builder asks for a change#

1. Studio. The builder sends a message in the Builder, with any attachments.
2. Studio API. The API verifies the sign-in token, resolves the workspace and the person's roles, checks the Solution permission, stores the attachments in the Solution's managed File Store, and records the turn.
3. Durable job. The turn is queued as a background job and the API answers straight away. From the Studio home page, the builder is in the Builder within about a second.
4. Worker. A worker claims the job and runs the Builder's loop. Every tool call goes through the same services the Studio uses, so validation, audit and the Solution boundary all apply. Model calls are metered to the Solution.
5. Live progress. Each step is recorded and pushed to the browser over a stream that can be reconnected from where it left off. If the builder closes the tab, the turn carries on.

B. An end user opens a generated app#

1. App page. The browser loads the app from the workspace's apps address. The apps server injects the runtime SDK and a small, non-secret configuration.
2. Gateway. The app calls an endpoint on its own address. On a workspace address the gateway takes the workspace from the address, never guessing, and loads the Solution's endpoint catalogue.
3. Identity check. If the endpoint requires sign-in, the gateway verifies the caller's credential against the Identity and applies its rules. An app's sign-in completes on the gateway for every provider except Microsoft, so the browser never holds a client secret; a Microsoft sign-in completes in the browser and the app reports it to the gateway. Either way, at sign-in the gateway adds the person to the Identity's Members list and runs its On sign-in Flow, if it has one, so their first call carries their access tags.
4. Endpoint. The endpoint kind decides what runs: a saved query under a Fact Base role, a published Flow, an Agent session, or a file operation.
5. Response. Rows, a Flow result, an Agent reply (streamed) or a file as an attachment. Agent turns and Flow runs are themselves durable jobs on the worker.

C. A person messages a Bot in Teams#

1. Microsoft Teams. A person writes to the Bot.
2. Gateway webhook. Microsoft's Bot Framework posts the message to the Bot's webhook on the apps address. The gateway applies a rate floor, finds the live Bot from the token in the address, and verifies Microsoft's signature. A redelivered message is dropped.
3. Agent turn. The message becomes a turn in the person's conversation, queued as a durable job. Teams shows the typing indicator.
4. Worker. The worker runs the Agent: guardrails, the model, the granted tools and budgets.
5. Reply in Teams. The reply is delivered from inside the turn, with a Sources footnote when documents were cited.

What the three paths share#

Related#

• Runtime services
• Flex Gateway
• Identity and access