Request Flow

End-to-End Path

The current request lifecycle is centered on the orchestrator and request router.

Telegram update
  -> TelegramBridge
  -> OrchestratorAgent
  -> RequestRouter
  -> EffectiveContextResolver + IntentInterpreter
  -> Selected use case
  -> Specialized agent or service
  -> TelegramPresenter
  -> TelegramBridge response

Detailed Steps

1. src/jarvis/main.py starts the Telegram polling loop when configuration is present.
2. TelegramBridge reads inbound messages or callback interactions.
3. OrchestratorAgent receives the instruction and builds the runtime dependencies it needs.
4. RequestRouter checks deterministic routes first, such as slash commands, approval replies, repo activation, and episode history requests.
5. For free-form instructions, EffectiveContextResolver prepares the working context and IntentInterpreter classifies the intent.
6. The router returns a canonical RoutedRequest describing route, authority mode, action, and metadata.
7. The orchestrator dispatches to the matching use case, such as status, workspace query, repo activation, or proposed code change.
8. The selected use case calls into an agent or service layer to do the work.
9. TelegramPresenter converts the result into a transport-ready message and optional attachment.
10. TelegramBridge sends the final response back to the user.

Safety Controls

Two controls already shape the flow:

• authority mode gates whether the system may perform write operations
• pending change management creates an approval step before applying certain code results

These controls sit above tool execution so the orchestrator can block risky paths before a workspace or git action occurs.